From: Alan Reiner <etotheipi@gmail•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node
Date: Tue, 19 Jun 2012 14:12:19 -0400 [thread overview]
Message-ID: <4FE0C103.3070304@gmail.com> (raw)
In-Reply-To: <CAAS2fgRFFtdsuaS+ZoFLYcnUxLBufA8aMV=_sHca5ZOi-3viTw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]
On 06/19/2012 01:59 PM, Gregory Maxwell wrote:
> On Tue, Jun 19, 2012 at 1:33 PM, Alan Reiner<etotheipi@gmail•com> wrote:
>> One app developer updates their
>> RB tree code which updated the RB-tree optimizations/rebalancing, and
>> now a significant portion of the network can't agree on the correct
>> root. Not only would that be disruptive, it would be a disaster to
>> track down.
> This is why good comprehensive tests and a well specified algorithim
> are important. The tree update algorithm would be normative in that
> scheme. Worrying that implementers might get it wrong would be like
> worrying that they'd get SHA256 wrong.
The point is not that they get it *wrong*, it's that the implement it
*differently*. Given a set of 100 TxOuts, there's a seemingly-infinite
number of ways to construct a binary tree. Put them in in a different
order, and you get a different tree. *They're all correct and legal* in
terms of satisfying expectations of insert, delete and query runtime --
but they will produce different root hashes. And the differences in
underlying structure are completely transparent to the calling code.
I'm extremely uncomfortable with the idea the you can have all the nodes
in the tree, but have to replay X years of blockchain history just to
get the same tree configuration as someone else. However, a trie
configuration is history-independent -- given an unspent-TxOut list,
there's only one way to construct that tree. That's an important
property to me.
I can't tell if you're joking about Judy structures: I've never heard of
them. But I'll look into it anyway...
[-- Attachment #2: Type: text/html, Size: 2224 bytes --]
next prev parent reply other threads:[~2012-06-19 18:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-19 16:46 Andrew Miller
2012-06-19 17:33 ` Alan Reiner
2012-06-19 17:59 ` Gregory Maxwell
2012-06-19 18:12 ` Alan Reiner [this message]
2012-06-19 18:18 ` Mark Friedenbach
2012-06-19 18:30 ` Alan Reiner
2012-06-21 21:42 ` Mike Koss
2012-06-21 22:02 ` Gregory Maxwell
2012-06-19 18:29 Andrew Miller
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=4FE0C103.3070304@gmail.com \
--to=etotheipi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/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