1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
Return-Path: <patrick.strateman@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D6DA21251
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 19:43:18 +0000 (UTC)
Received: by iofh134 with SMTP id h134so67463861iof.0
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>
(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 <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
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
|
