Message-ID: <55FC6951.9010704@gmail.com>
Date: Fri, 18 Sep 2015 12:43:13 -0700
From: Patrick Strateman <patrick.strateman@gmail.com>
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
Subject: Re: [bitcoin-dev] Hash of UTXO set as consensus-critical
Precedence: list

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