Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: =?utf-8?Q?Rune_Kj=C3=A6r_Svendsen?= <runesvend@gmail.com>
In-Reply-To: <55FC6951.9010704@gmail.com>
Date: Fri, 18 Sep 2015 22:17:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A16FDC0B-877F-47F1-A631-77F46251BB07@gmail.com>
References: <5D55F6EC-801B-4607-882F-B76CF57298B1@gmail.com>
	<55FC6951.9010704@gmail.com>
To: Patrick Strateman <patrick.strateman@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Hash of UTXO set as consensus-critical
Precedence: list

There are a couple of points I=E2=80=99d like to address.

Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not =
function if the majority of mining power is dishonest. There is no way =
around that. It=E2=80=99s how proof-of-work functions. And if we lose =
proof-of-work, we lose Bitcoin.

Secondly, I=E2=80=99m not suggesting that UTXO set hashes *replace* =
block hashes, or even that it should be in the block header (probably in =
the coinbase somewhere). I suggest it as an *addition* to the existing =
consensus rules. Full nodes can still verify the chain with the added =
step of hashing the UTXO set for every block. Of course, this can easily =
be deferred to after proof-of-work has been verified already, such that =
no work is wasted. Unless a 51% attack is in effect. But I argue that =
this is a moot point, since Bitcoin is useless anyway under such =
circumstances.

Lastly, I=E2=80=99m not suggesting miners discard the blockchain =
history. A miner has an incentive to be absolutely sure that the chain =
he=E2=80=99s building on is the right one. If he=E2=80=99s wrong, he =
loses money/income. There=E2=80=99s simply no reason for a professional =
miner *not* to do the full initial sync, which only needs to be done =
once. Non-miners, who just want to check the balance of their wallet, =
however, really don=E2=80=99t need to retrieve information about Hal =
Finney sending bitcoins to Satoshi in 2010. In any case, this practice =
isn=E2=80=99t sustainable.

In the end, it isn=E2=80=99t possible to control whether a miner =
verifies the entire blockchain anyway (anyone can send the UTXO set over =
the wire). Not letting the proof-of-work cover the UTXO hash doesn=E2=80=99=
t solve this problem, it only makes it impossible to know whether a =
given UTXO set is the one that the majority is mining on without =
retrieving the entire blockchain, and doing the verification yourself. =
People can choose to skip that regardless of what we do.

Furthermore, all nodes have the option of deciding which level of =
security they want. We=E2=80=99re not lessening security of the =
protocol, we=E2=80=99re strengthening the security of something that=E2=80=
=99s already possible to do (build on top of an unverified blockchain), =
but we=E2=80=99d rather want that people not do.

/Rune


> On 18 Sep 2015, at 21:43, Patrick Strateman via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> Full nodes using UTXO set commitments is a change to the bitcoin
> security model.
>=20
> Currently an attacker with >50% of the network hashrate can rewrite =
history.
>=20
> 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).
>=20
> Before we consider mechanisms for UTXO set commitments, we should
> seriously discuss whether the security model reduction is reasonable.
>=20
> 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 =
retrieve the entire blockchain history, starting from January 2009 and =
up until now, in order to derive a UTXO set that it can verify new =
blocks/transactions against. With a blockchain size of 40GB and a UTXO =
size of around 1GB, the extra bandwidth required is significant, and =
will keep increasing 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 set on top of which this block builds =E2=80=94 =
then new nodes, who want to 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 knowing that a block with an invalid UTXO set =
hash would be rejected.
>>=20
>> I=E2=80=99m not talking about calculating a complicated tree =
structure from the UTXO set, which would put further burden on already =
burdened Bitcoin 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 *on 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 trustlessly and using this to answer queries). =
It also saves bandwidth for Bitcore Core nodes, who only need to send =
roughly 1GB of data, in order to synchronise a node, rather than 40GB+. =
I will continue to run a full Bitcoin Core node, saving the entire =
blockchain history, but it shouldn=E2=80=99t be a requirement to hold =
the entire transaction history in order to start verifying new =
transactions.
>>=20
>> As far as I can see, this also forces miners to actually maintain an =
UTXO 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 verify the block that they want to build on top of.
>>=20
>> Am I missing something obvious, because as far as I can see, this =
solves the problem of quadratic time complexity for initial sync: =
http://www.youtube.com/watch?v=3DTgjrS-BPWDQ&t=3D2h02m12s
>>=20
>> 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 hash the UTXO set. And this can be improved further (GPUs can =
do 2-3 GB/s). A small sacrifice for the added ease of initial syncing, =
in my opinion.
>>=20
>> /Rune
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev