[Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite nodes

Alberto Torres kungfoobar at gmail.com
Sun Jun 17 22:46:47 UTC 2012


I did describe a very similar thing back in January (also illustrated,
and, if I'm not mistaken, more simple and efficient to recalculate),
and I wanted to do a prototype, but I have been very busy with other
projects since then.


I just saw Gavin left a comment in the talk page, I'm sorry I haven't
seen it earlier.

I think armory is the perfect client to implement such an idea. I sort
of waited it to be able to run in my laptop with 2 GB of RAM before
being sucked into other projects. I even lost track of its

I hope this gets developed. I will be able to help after summer if
this is still not done.


P.S: Sorry Peter, I've sent you the message privately by mistake.
Also, I don't quite understand your concern of "unbalancing" the tree.

2012/6/17 Peter Todd <pete at petertodd.org>:
> On Sun, Jun 17, 2012 at 02:39:28PM -0400, Alan Reiner wrote:
>> All,
>> With the flurry of discussion about blockchain compression, I
>> thought it was time to put forward my final, most-advanced idea,
>> into a single, well-thought-out, *illustrated*, forum post.
>> Please check it out: https://bitcointalk.org/index.php?topic=88208.0
>> This is a huge undertaking, but it has some pretty huge benefits.
>> And it's actually feasible because it can be implemented without
>> disrupting the main network.  I'm sure there's lots of issues with
>> it, but I'm putting it out there to see how it might be improved and
>> actually executed.
>> ----
>> *Summary:
>> */Use a special tree data structure to organize all unspent-TxOuts
>> on the network, and use the root of this tree to communicate its
>> "signature" between nodes.  The leaves of this tree actually
>> correspond to addresses/scripts, and the data at the leaf is
>> actually a root of the unspent-TxOut list for that address/script.
>> To maintain security of the tree signatures, it will be included in
>> the header of an alternate blockchain, which will be secured by
>> merged mining.
>> This provides the same compression as the simpler unspent-TxOut
>> merkle tree, but also gives nodes a way to download just the
>> unspent-TxOut list for each address in their wallet, and verify that
>> list directly against the blockheaders.  Therefore, even lightweight
>> nodes can get full address information, from any untrusted peer, and
>> with only a tiny amount of downloaded data (a few kB). /*
> How are you going to prevent people from delibrately unbalancing the
> tree with addresses with chosen hashes?
> One idea that comes to mind, which unfortunately would make for a
> pseudo-network rule, is to simply say that any *new* address whose hash
> happens to be deeper in the tree than, say, 10*log(n), indicating it was
> probably chosen to be unbalanced, gets discarded. The "new address" part
> of the rule would be required, or else you could use the rule to get
> other people's addresses discarded.
> Having said that, such a rule just means that anyone playing games will
> find they can't spend *their* money, and only with pruning clients.
> Unrelated people will not be effected. The coins can also always be
> spent with a non-pruning client to an acceptable address, which can
> later re-spend on a pruning client.
> It also comes to mind is that with the popularity of firstbits it may be
> a good idea to use a comparison function that works last bit first...
> It's merkles all the way down...
> --
> 'peter'[:-1]@petertodd.org
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

More information about the bitcoin-dev mailing list