📅 Original date posted:2018-06-09
📝 Original message: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 <pete at petertodd.org> 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 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180608/8320bbb2/attachment.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 18:12:57
in reply to nevent1q…4p8e
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 18:12:57Event JSON
{
"id": "f6fdb444ef88c64dbd60868439e7625da9c4c7481998b66e189025557791c26e",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686161577,
"kind": 1,
"tags": [
[
"e",
"7a6928115f0482ae6ba69f7494f1e58497a12608fbde58f7bb3fa58e19c8ae03",
"",
"root"
],
[
"e",
"807ea10aefe0fd28f5f09d042cbf4f9e9d7f4ab89f9cdc15192466c1b11100ce",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2018-06-09\n📝 Original message:So are you saying that if fully validating nodes wish to prune they can\nmaintain the ability to validate old transactions by cacheing the number of\ntransactions in each previous block?\n\nOn Thu, Jun 7, 2018 at 3:20 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen wrote:\n\u003e \u003e Are you proposing a soft fork to include the number of transactions in a\n\u003e \u003e block in the block headers to compensate for the broken Merkle format?\n\u003e That\n\u003e \u003e sounds like a good idea.\n\u003e \u003e\n\u003e \u003e On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev \u003c\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e It's well known that the Bitcoin merkle tree algorithm fails to\n\u003e distinguish\n\u003e \u003e \u003e between inner nodes and 64 byte transactions, as both txs and inner\n\u003e nodes\n\u003e \u003e \u003e are\n\u003e \u003e \u003e hashed the same way. This potentially poses a problem for tx inclusion\n\u003e \u003e \u003e proofs,\n\u003e \u003e \u003e as a miner could (with ~60 bits of brute forcing) create a transaction\n\u003e that\n\u003e \u003e \u003e committed to a transaction that was not in fact in the blockchain.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Since odd-numbered inner/leaf nodes are concatenated with themselves\n\u003e and\n\u003e \u003e \u003e hashed\n\u003e \u003e \u003e twice, the depth of all leaves (txs) in the tree is fixed.\n\u003e \u003e \u003e\n\u003e \u003e \u003e It occured to me that if the depth of the merkle tree is known, this\n\u003e \u003e \u003e vulnerability can be trivially avoided by simply comparing the length\n\u003e of\n\u003e \u003e \u003e the\n\u003e \u003e \u003e merkle path to that known depth. For pruned nodes, if the depth is\n\u003e saved\n\u003e \u003e \u003e prior\n\u003e \u003e \u003e to pruning the block contents itself, this would allow for completely\n\u003e safe\n\u003e \u003e \u003e verification of tx inclusion proofs, without a soft-fork; storing this\n\u003e ^^^^^^^^^^^^^^^^^^^\n\u003e\n\u003e Re-read my post: I specifically said you do not need a soft-fork to\n\u003e implement\n\u003e this. In fact, I think you can argue that this is an accidental feature,\n\u003e not a\n\u003e bug, as it further encourages the use of safe full verifiaction rather than\n\u003e unsafe lite clients.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180608/8320bbb2/attachment.html\u003e",
"sig": "b7e54d92c54a1fae331f182f68abf3848d90206810722d799097c79f0f557c3f9888c1e747473f0bf4d81d45fca410f696665e61808f144d65003b2cb31aa520"
}