From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D6DA21251 for ; Fri, 18 Sep 2015 19:43:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 624732AF for ; Fri, 18 Sep 2015 19:43:18 +0000 (UTC) Received: by iofh134 with SMTP id h134so67463861iof.0 for ; Fri, 18 Sep 2015 12:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/+WnfUZqIVv6Snu2RkVyDyRfm/AXeH/WqpDW4XiabrA=; b=R/DByot20BBAQHk9yVWLJrwSvmGaPeniXzkyHTngGkBECzgpDJxxDS0JDIivw5bQbL AJ6bsEp9cbf2CjANN2ma099YlCybhti9F5X6X7or7VPGIr8/olqcXFGWqAIMlj7a09t1 YFa9/lrsJ87l44ZYXWKsO/zqYoGTbl3fZnTEjVMX8XB7X5Hg9bujrwcPY0jnF40DIr4c qvUKL3voqGN1p/zgoZ6R0JykjMacTjFvqdMOcZM4kfye+KJ6I/HzEmenkU1hZ8jMwUzc ZHP2pSV9X7Yz6RjrUfde+h16kjqCRttYilKI1mvzuFeDlq7mB2rpdM8SsCcR3MPcFQH4 fKNA== X-Received: by 10.107.14.4 with SMTP id 4mr17170567ioo.169.1442605397651; Fri, 18 Sep 2015 12:43:17 -0700 (PDT) Received: from [172.19.131.148] ([12.130.116.194]) by smtp.googlemail.com with ESMTPSA id n68sm2674637ion.26.2015.09.18.12.43.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2015 12:43:17 -0700 (PDT) Message-ID: <55FC6951.9010704@gmail.com> Date: Fri, 18 Sep 2015 12:43:13 -0700 From: Patrick Strateman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: bitcoin-dev@lists.linuxfoundation.org References: <5D55F6EC-801B-4607-882F-B76CF57298B1@gmail.com> In-Reply-To: <5D55F6EC-801B-4607-882F-B76CF57298B1@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Hash of UTXO set as consensus-critical X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 19:43:18 -0000 Full nodes using UTXO set commitments is a change to the bitcoin security model. Currently an attacker with >50% of the network hashrate can rewrite histo= ry. If full nodes rely on UTXO set commitments such an attacker could create an infinite number of bitcoins (as in many times more than the current 21 million bitcoin limit). Before we consider mechanisms for UTXO set commitments, we should seriously discuss whether the security model reduction is reasonable. On 09/18/2015 12:05 PM, Rune Kj=C3=A6r Svendsen via bitcoin-dev wrote: > Currently, when a new node wants to join the network, it needs to retri= eve the entire blockchain history, starting from January 2009 and up unti= l now, in order to derive a UTXO set that it can verify new blocks/transa= ctions against. With a blockchain size of 40GB and a UTXO size of around = 1GB, the extra bandwidth required is significant, and will keep increasin= g indefinitely. If a newly mined block were to include the UTXO set hash = of the chain up until the previous block =E2=80=94 the hash of the UTXO s= et on top of which this block builds =E2=80=94 then new nodes, who want t= o know whether a transaction is valid, would be able to acquire the UTXO = set in a trustless manner, by only verifying proof-of-work headers, and k= nowing that a block with an invalid UTXO set hash would be rejected. > > I=E2=80=99m not talking about calculating a complicated tree structure = from the UTXO set, which would put further burden on already burdened Bit= coin Core nodes. We simply include the hash of the current UTXO set in a = newly created block, such that the transactions in the new block build *o= n top* of the UTXO set whose hash is specified. This actually alleviates = Bitcoin Core nodes, as it will now become possible for nodes without the = entire blockchain to answer SPV queries (by retrieving the UTXO set trust= lessly and using this to answer queries). It also saves bandwidth for Bit= core Core nodes, who only need to send roughly 1GB of data, in order to s= ynchronise a node, rather than 40GB+. I will continue to run a full Bitco= in Core node, saving the entire blockchain history, but it shouldn=E2=80=99= t be a requirement to hold the entire transaction history in order to sta= rt verifying new transactions. > > As far as I can see, this also forces miners to actually maintain an UT= XO set, rather than just build on top of the chain with the most proof-of= -work. Producing a UTXO set and verifying a block against a chain is the = same thing, so by including the hash of the UTXO set we force miners to v= erify the block that they want to build on top of. > > Am I missing something obvious, because as far as I can see, this solve= s the problem of quadratic time complexity for initial sync: http://www.y= outube.com/watch?v=3DTgjrS-BPWDQ&t=3D2h02m12s > > The only added step to verifying a block is to hash the UTXO set. So it= does require additional computation, but most modern CPUs have a SHA256 = throughput of around 500 MB/s, which means it takes only two seconds to h= ash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s)= =2E A small sacrifice for the added ease of initial syncing, in my opinio= n. > > /Rune > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev