path: root/bd/be6e10110965bc7b9d41740e9215eb7b929fec

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1SgOiz-0003Lh-Nu
	for bitcoin-development@lists.sourceforge.net;
	Sun, 17 Jun 2012 23:17:41 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.46 as permitted sender)
	client-ip=209.85.216.46; envelope-from=etotheipi@gmail.com;
	helo=mail-qa0-f46.google.com; 
Received: from mail-qa0-f46.google.com ([209.85.216.46])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.76) id 1SgOiy-0002nt-NX
	for bitcoin-development@lists.sourceforge.net;
	Sun, 17 Jun 2012 23:17:41 +0000
Received: by qadb17 with SMTP id b17so829948qad.12
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 17 Jun 2012 16:17:35 -0700 (PDT)
Received: by 10.224.106.136 with SMTP id x8mr24097308qao.12.1339975055235;
	Sun, 17 Jun 2012 16:17:35 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
	[76.111.96.126])
	by mx.google.com with ESMTPS id gd2sm37617702qab.18.2012.06.17.16.17.34
	(version=SSLv3 cipher=OTHER); Sun, 17 Jun 2012 16:17:34 -0700 (PDT)
Message-ID: <4FDE6583.9020509@gmail.com>
Date: Sun, 17 Jun 2012 19:17:23 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <4FDE2460.5080301@gmail.com> <20120617190511.GA26047@savin>
	<CAE98tO2PcxKdz670ptHB=3Pc9JvV_+Wjdt1117M4SA2hANKH+w@mail.gmail.com>
In-Reply-To: <CAE98tO2PcxKdz670ptHB=3Pc9JvV_+Wjdt1117M4SA2hANKH+w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.1 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(etotheipi[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SgOiy-0002nt-NX
Subject: Re: [Bitcoin-development] Ultimate Blockchain Compression w/
 trust-free lite nodes
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 17 Jun 2012 23:17:41 -0000

Hi Alberto,

Your thread was part of the inspiration for the idea that I proposed.  
But as I read it more, I see that I originally misunderstood it 
(mistaking it for a simpler unspent-TxOut tree idea).  Even after 
reading it, I'm not entirely clear how your proposal would work, but I 
see that you proposed something very similar.  I just want to clarify 
that there are two, major orthogonal pieces to both proposals:

(1) The method for creating unspent-TxOut-tree roots/fingerprints for 
verification
(2) Using an alternate blockchain to maintain and distribute those 
fingerprints

There are multiple ways to do both of those.  You proposed a different 
tree structure (which I haven't entirely figured out, yet), and putting 
those "fingerprints" in the main chain header.

In my proposal, (2) is to avoid inducing a blockchain fork, or even 
changing the protocol at all.  By using a separate blockchain, it can be 
done non-disruptively, and could even be thrown out and re-worked if we 
were to find an issue with it later.  The availability of merged mining 
makes it possible to get [almost] the same security as changing the 
protocol, but without the disruption of hard-forking.  (I expect that if 
there's not too much computational overhead and the software is already 
written, most miners would sign on)

I'll read into your page a little more.  I don't want to take credit 
away from you, since you clearly had a comparable idea developed long 
before me :)

-Alan


On 06/17/2012 06:46 PM, Alberto Torres wrote:
> 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=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@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> ------------------------------------------------------------------------------
> 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