Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WYJZj-0002vh-55 for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 18:19:47 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.181 as permitted sender) client-ip=209.85.160.181; envelope-from=prabahy@gmail.com; helo=mail-yk0-f181.google.com; Received: from mail-yk0-f181.google.com ([209.85.160.181]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WYJZT-0007Yk-5E for bitcoin-development@lists.sourceforge.net; Thu, 10 Apr 2014 18:19:47 +0000 Received: by mail-yk0-f181.google.com with SMTP id 131so3841144ykp.26 for ; Thu, 10 Apr 2014 11:19:25 -0700 (PDT) X-Received: by 10.236.126.43 with SMTP id a31mr3957971yhi.154.1397153965645; Thu, 10 Apr 2014 11:19:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.156.85 with HTTP; Thu, 10 Apr 2014 11:19:05 -0700 (PDT) In-Reply-To: References: From: Paul Rabahy Date: Thu, 10 Apr 2014 14:19:05 -0400 Message-ID: To: Pieter Wuille Content-Type: multipart/alternative; boundary=20cf3005de66d1a36d04f6b44147 X-Spam-Score: -0.6 (/) 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 (prabahy[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 AC_DIV_BONANZA RAW: Too many divs in a row... spammy template -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.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline X-Headers-End: 1WYJZT-0007Yk-5E Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Chain pruning X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 18:19:47 -0000 --20cf3005de66d1a36d04f6b44147 Content-Type: text/plain; charset=ISO-8859-1 You say UTXO commitments is "a strict reduction in security". If UTXO commitments were rolled in as a soft fork, I do not see any new attacks that could happen to a person trusting the committed UTXO + any remaining blocks to catch up to the head. I would imagine the soft fork to proceed similar to the following. 1. Miners begin including UTXO commitments. 2. Miners begin rejecting blocks with invalid UTXO commitments. 3. Miners begin rejecting blocks with no UTXO commitments. To start up a fresh client it would follow the following. 1. Sync headers. 2. Pick a committed UTXO that is deep enough to not get orphaned. 3. Sync blocks from commitment to head. I would argue that a client following this methodology is strictly more secure than SPV, and I don't see any attacks that make it less secure than a full client. It is obviously still susceptible to a 51% attack, but so is the traditional block chain. I also do not see any sybil attacks that are strengthened by this change because it is not modifying the networking code. I guess if the soft fork happened, then miners began to not include the UTXO commitment anymore, it would lower the overall network hash rate, but this would be self-harming to the miners so they have an incentive to not do it. Please let me know if I have missed something. On Thu, Apr 10, 2014 at 12:59 PM, Pieter Wuille wrote: > > As this is a suggestion that I think I've seen come up once a month > for the past 3 years, let's try to answer it thoroughly. > > The actual "state" of the blockchain is the UTXO set (stored in > chainstate/ by the reference client). It's the set of all unspent > transaction outputs at the currently active point in the block chain. > It is all you need for validating future blocks. > > The problem is, you can't just give someone the UTXO set and expect > them to trust it, as there is no way to prove that it was the result > of processing the actual blocks. > > As Bitcoin's full node uses a "zero trust" model, where (apart from > one detail: the order of otherwise valid transactions) it never > assumes any data received from the outside it valid, it HAS to see the > previous blocks in order to establish the validity of the current UTXO > set. This is what initial block syncing does. Nothing but the actual > blocks can provide this data, and it is why the actual blocks need to > be available. It does not require everyone to have all blocks, though > - they just need to have seen them during processing. > > A related, but not identical evolution is merkle UTXO commitments. > This means that we shape the UTXO set as a merkle tree, compute its > root after every block, and require that the block commits to this > root hash (by putting it in the coinbase, for example). This means a > full node can copy the chain state from someone else, and check that > its hash matches what the block chain commits to. It's important to > note that this is a strict reduction in security: we're now trusting > that the longest chain (with most proof of work) commits to a valid > UTXO set (at some point in the past). > > In essence, combining both ideas means you get "superblocks" (the UTXO > set is essentially the summary of the result of all past blocks), in a > way that is less-than-currently-but-perhaps-still-acceptably-validated. > > -- > Pieter > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --20cf3005de66d1a36d04f6b44147 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You say = UTXO commitments is "a strict reduction in security". If UTXO com= mitments were rolled in as a soft fork, I do not see any new attacks that c= ould happen to a person trusting the committed UTXO + any remaining blocks = to catch up to the head.

I would imagine the soft fork to proceed similar to the following= .
1. Miners begin including UTXO commitments.
2. Miners b= egin rejecting blocks with invalid UTXO commitments.
3. Miners beg= in rejecting blocks with no UTXO commitments.

To start up a fresh client it would follow the following.
1. Sync headers.
2. Pick a committed UTXO that is deep enough to= not get orphaned.
3. Sync blocks from commitment to head.

I would argue that a client following this methodology is strictl= y more secure than SPV, and I don't see any attacks that make it less s= ecure than a full client. It is obviously still susceptible to a 51% attack= , but so is the traditional block chain. I also do not see any sybil attack= s that are strengthened by this change because it is not modifying the netw= orking code.

I guess if the soft fork happened, then miners began to not = include the UTXO commitment anymore, it would lower the overall network has= h rate, but this would be self-harming to the miners so they have an incent= ive to not do it.

Please let me know if I have missed something.


On Thu, Apr = 10, 2014 at 12:59 PM, Pieter Wuille <pieter.wuille@gmail.com>= wrote:

As this is a suggestion that I think I've seen come up once a mon= th
for the past 3 years, let's try to answer it thoroughly.

The actual "state" of the blockchain is the UTXO set (stored in chainstate/ by the reference client). It's the set of all unspent
transaction outputs at the currently active point in the block chain.
It is all you need for validating future blocks.

The problem is, you can't just give someone the UTXO set and expect
them to trust it, as there is no way to prove that it was the result
of processing the actual blocks.

As Bitcoin's full node uses a "zero trust" model, where (apar= t from
one detail: the order of otherwise valid transactions) it never
assumes any data received from the outside it valid, it HAS to see the
previous blocks in order to establish the validity of the current UTXO
set. This is what initial block syncing does. Nothing but the actual
blocks can provide this data, and it is why the actual blocks need to
be available. It does not require everyone to have all blocks, though
- they just need to have seen them during processing.

A related, but not identical evolution is merkle UTXO commitments.
This means that we shape the UTXO set as a merkle tree, compute its
root after every block, and require that the block commits to this
root hash (by putting it in the coinbase, for example). This means a
full node can copy the chain state from someone else, and check that
its hash matches what the block chain commits to. It's important to
note that this is a strict reduction in security: we're now trusting that the longest chain (with most proof of work) commits to a valid
UTXO set (at some point in the past).

In essence, combining both ideas means you get "superblocks" (the= UTXO
set is essentially the summary of the result of all past blocks), in a
way that is less-than-currently-but-perhaps-still-acceptably-validated.

--
Pieter

---------------------------------------------------------------------------= ---
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.= sf.net/sfu/13600_Cloudbees
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--20cf3005de66d1a36d04f6b44147--