Brilliant Umber Eagle
High
There is no enough validation on the tx when it be verified by the Babylon SPV client.
The block header including the txs hash, all the txs are constructed to a merkle tree, the light client will verify the tx is included in the block or not by SPV(Simplified Payment Verification) method, if the tx and its corresponding merkle proof match with the merkle root, the tx can be considered as valid.
But the merkle leaf node(tx) can be forged by malicious btc miner. Any 64 bytes tx can be composed by two 32 bytes txs hash. For example, there is a tx T and its hash H(T) = 32 bytes, H(T) = H(T1 + T2). The second 32 bytes T2 are less constrained compared with the first 32 bytes so it can be controlled by the tx creator to collide with an invalid tx named F, such that T = T1 + H(F).
According to this research 3.2: Putting this all together, we have 81 bits of constraint, meaning that an attacker who can do 81 bits of work (followed by another 40 bits of work, to construct the funding transaction whose coins will be spent by this one) is able to fool an SPV client in this way. (Note that this is much less than the 128-bits of work that we would expect to be required to fool an SPV client, by finding 2 transactions with the same hash.)
and the current btc hashrate we can know it's economically infeasible for a single miner to produce such a coinbase tx.
The coinbase tx has 100 bytes limitation, so it satisfies the 64 bytes tx requirement. The malicious miner can produce a valid 64-bytes coinbase tx that can be accepted by the btc network, but the second 32 bytes collide with the invalid tx. After it sync to the Babylon light client, the verify function can be passed by providing the invalid tx F and the corresponding merkle proof path(H(T) = H(T1 + T2) = H(T1 + H(F)) and the other intermediate nodes are the same).
This verify function are used by the CreateBTCDelegation/AddBTCDelegationInclusionProof/BTCUndelegate actions, the invalid tx can be confirmed by the Babylon node to cause unexpected behavior.
NA.
NA.
- A malicious miner produce an valid 64-byte coinbase tx that would be accepted by the network.
- The miner prepare an invalid tx whose hash collide with the second 32 bytes of the coinbase tx.
- The invalid tx can be verified and confirmed by the Babylon node through the necessary merkle proof and index.
Note this tx index shouldn't be 0 as its hash collide with the second 32 bytes of the coinbase tx instead of coinbase tx itself so the previous reject coinbase tx fix is not applied to this.
Invalid tx can be recogised as valid by the Babylon node, which may cause unexpected behavior. It breaks one of the core invariant assumptions and belong to Babylon node recognising staking registration with invalid staking protocol transactions as valid so the impact should be high.
NA
Length check of coinbase proof and all other txs merkle proof. The coinbase tx and normal tx must be the same level of the merkle tree, so their merkle proof length should be the same.
https://medium.com/immunefi/threshold-transaction-malleability-bugfix-review-cf0d2aa5437e