From: Bram Cohen <bram@chia•net>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork
Date: Fri, 8 Jun 2018 20:29:30 -0700 [thread overview]
Message-ID: <CAHUJnBCj8wnjP1=jobfpg7jkfjkX9iSBLeeAOyQCpobh6-AhUA@mail.gmail.com> (raw)
In-Reply-To: <20180607222028.zbva4vrv64dzrmxy@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]
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@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@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
>
[-- Attachment #2: Type: text/html, Size: 2866 bytes --]
next prev parent reply other threads:[~2018-06-09 3:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-07 17:13 Peter Todd
2018-06-07 21:15 ` Bram Cohen
2018-06-07 22:20 ` Peter Todd
2018-06-09 3:29 ` Bram Cohen [this message]
2018-06-09 11:03 ` Sergio Demian Lerner
2018-06-09 12:21 ` Sergio Demian Lerner
2018-06-09 12:24 ` Sergio Demian Lerner
2018-06-09 12:45 ` Peter Todd
2018-06-09 12:51 ` Sergio Demian Lerner
2018-06-09 13:02 ` Peter Todd
2018-06-09 12:50 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHUJnBCj8wnjP1=jobfpg7jkfjkX9iSBLeeAOyQCpobh6-AhUA@mail.gmail.com' \
--to=bram@chia$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox