Hi Peter, We reported this as CVE-2017-12842, although it may have been known by developers before us. There are hundreds of SPV wallets out there, without even considering other more sensitive systems relying on SPV proofs. As I said we, at RSK, discovered this problem in 2017. For RSK it's very important this is fixed because our SPV bridge uses SPV proofs. I urge all people participating in this mailing list and the rest of the Bitcoin community to work on this issue for the security and clean-design of Bitcoin. My suggestion is to use in the version bits 4 bits indicating the tree depth (-1), as a soft-fork, so 00=1 depth, 0F = 16 depth (maximum 64K transactions). Very clean. The other option is to ban transaction with size lower or equal to 64. Best regards, Sergio. On Sat, Jun 9, 2018 at 5:31 AM Bram Cohen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > So are you saying that if fully validating nodes wish to prune they can > maintain the ability to validate old transactions by cacheing the number of > transactions in each previous block? > > On Thu, Jun 7, 2018 at 3:20 PM, Peter Todd wrote: > >> On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote: >> > Are you proposing a soft fork to include the number of transactions in a >> > block in the block headers to compensate for the broken Merkle format? >> That >> > sounds like a good idea. >> > >> > On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev < >> > bitcoin-dev@lists.linuxfoundation.org> wrote: >> > >> > > It's well known that the Bitcoin merkle tree algorithm fails to >> distinguish >> > > between inner nodes and 64 byte transactions, as both txs and inner >> nodes >> > > are >> > > hashed the same way. This potentially poses a problem for tx inclusion >> > > proofs, >> > > as a miner could (with ~60 bits of brute forcing) create a >> transaction that >> > > committed to a transaction that was not in fact in the blockchain. >> > > >> > > Since odd-numbered inner/leaf nodes are concatenated with themselves >> and >> > > hashed >> > > twice, the depth of all leaves (txs) in the tree is fixed. >> > > >> > > It occured to me that if the depth of the merkle tree is known, this >> > > vulnerability can be trivially avoided by simply comparing the length >> of >> > > the >> > > merkle path to that known depth. For pruned nodes, if the depth is >> saved >> > > prior >> > > to pruning the block contents itself, this would allow for completely >> safe >> > > verification of tx inclusion proofs, without a soft-fork; storing this >> ^^^^^^^^^^^^^^^^^^^ >> >> Re-read my post: I specifically said you do not need a soft-fork to >> implement >> this. In fact, I think you can argue that this is an accidental feature, >> not a >> bug, as it further encourages the use of safe full verifiaction rather >> than >> unsafe lite clients. >> >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >