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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Return-Path: <runesvend@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id ABFFC16B2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 20:17:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D3B77227
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 20:17:44 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so77912885wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Sep 2015 13:17:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=content-type:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=ZbAL2f7yrhPEZenPkXsNxBVQwbybxJ2KwEQGzQk8hWk=;
b=G5rKrUXJfnW0ubt2U2ieyfNRS9J1IAiRlhw9Nsw/dxvU2uyZH5Of1W7+E/Dj8LsjAS
adVsf+xE4v6i3l0Y2+OKHD5bYBN8R7dSk8G5iswuwpIQu6Ayu03ovoAbx9Hz+VUua62f
LWXSA3ZSK8bP57He4Diy3crAzf25uUqyTof+MZ10UOHXUpUUafxB8rJ8WnSpBjWS+JjG
Dy/oe9Ni22W6BUnnN6e1ee9i59+1oFIZPOdoESPTQgZI0aYQw9fkX8XxRK2UIsYmvEQ3
5cezbNky8M7yaD4zl71TGABVQoPS1hY1A01axE1LE0FQMGmjAD1wZwjkN8bhuW3h5S6i
ziGw==
X-Received: by 10.194.175.104 with SMTP id bz8mr9454419wjc.42.1442607463476;
Fri, 18 Sep 2015 13:17:43 -0700 (PDT)
Received: from [192.168.1.33] ([212.60.121.11])
by smtp.gmail.com with ESMTPSA id
p10sm10558358wjx.7.2015.09.18.13.17.42
(version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Fri, 18 Sep 2015 13:17:42 -0700 (PDT)
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>
X-Mailer: Apple Mail (2.2104)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, MIME_QP_LONG_LINE,
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
Cc: bitcoin-dev@lists.linuxfoundation.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 20:17:45 -0000
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
|
