Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.210.47 as permitted sender)
	client-ip=209.85.210.47; envelope-from=kungfoobar@gmail.com;
	helo=mail-pz0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <20120617190511.GA26047@savin>
References: <4FDE2460.5080301@gmail.com> <20120617190511.GA26047@savin>
From: Alberto Torres <kungfoobar@gmail.com>
Date: Mon, 18 Jun 2012 00:46:47 +0200
Message-ID: <CAE98tO2PcxKdz670ptHB=3Pc9JvV_+Wjdt1117M4SA2hANKH+w@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] Ultimate Blockchain Compression w/
 trust-free lite nodes
Precedence: list

Hi,

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.

https://en.bitcoin.it/wiki/User:DiThi/MTUT

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
development.

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

DiThi

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@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=3D88208.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. =A0I'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. =A0The 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. =A0Therefore, 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>