📅 Original date posted:2018-06-07
📝 Original message: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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180607/4fc61b12/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 20:12:56
in reply to nevent1q…txx6
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 20:12:56Event JSON
{
"id": "807ea10aefe0fd28f5f09d042cbf4f9e9d7f4ab89f9cdc15192466c1b11100ce",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686161576,
"kind": 1,
"tags": [
[
"e",
"7a6928115f0482ae6ba69f7494f1e58497a12608fbde58f7bb3fa58e19c8ae03",
"",
"root"
],
[
"e",
"27216ef9a8a44a39648c4ab2b04d57cf56e194204a48d8b3d47b37da757ff465",
"",
"reply"
],
[
"p",
"fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9"
]
],
"content": "📅 Original date posted:2018-06-07\n📝 Original message:On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote:\n\u003e Are you proposing a soft fork to include the number of transactions in a\n\u003e block in the block headers to compensate for the broken Merkle format? That\n\u003e sounds like a good idea.\n\u003e \n\u003e On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e \u003e It's well known that the Bitcoin merkle tree algorithm fails to distinguish\n\u003e \u003e between inner nodes and 64 byte transactions, as both txs and inner nodes\n\u003e \u003e are\n\u003e \u003e hashed the same way. This potentially poses a problem for tx inclusion\n\u003e \u003e proofs,\n\u003e \u003e as a miner could (with ~60 bits of brute forcing) create a transaction that\n\u003e \u003e committed to a transaction that was not in fact in the blockchain.\n\u003e \u003e\n\u003e \u003e Since odd-numbered inner/leaf nodes are concatenated with themselves and\n\u003e \u003e hashed\n\u003e \u003e twice, the depth of all leaves (txs) in the tree is fixed.\n\u003e \u003e\n\u003e \u003e It occured to me that if the depth of the merkle tree is known, this\n\u003e \u003e vulnerability can be trivially avoided by simply comparing the length of\n\u003e \u003e the\n\u003e \u003e merkle path to that known depth. For pruned nodes, if the depth is saved\n\u003e \u003e prior\n\u003e \u003e to pruning the block contents itself, this would allow for completely safe\n\u003e \u003e verification of tx inclusion proofs, without a soft-fork; storing this\n ^^^^^^^^^^^^^^^^^^^\n\nRe-read my post: I specifically said you do not need a soft-fork to implement\nthis. In fact, I think you can argue that this is an accidental feature, not a\nbug, as it further encourages the use of safe full verifiaction rather than\nunsafe lite clients.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 488 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180607/4fc61b12/attachment.sig\u003e",
"sig": "7b26addc73c6eb2a5eed0b389b3d2cb828cb4877b4f3dc15ae0c31fc685c742becb32e569cdc68444dee9f149d9562aa908e538472b0647a7a1697a30402c179"
}