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
|
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 5CD7E17C7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2015 15:45:54 +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 87CFE8B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2015 15:45:53 +0000 (UTC)
Received: by wicfx3 with SMTP id fx3so62658223wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2015 08:45:52 -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=bT4cnXJFB+Exlb5kkcVzbT5r5zXSrMCpNZWHUpC+kFQ=;
b=dve6k//CTmivV8af1LeyLEsIftMiyV1+rUdrNlzAVcF5Ix4SlIxyUwB37XEgsb+/M9
UZ0WwZhX3dJp89+Rvn+ID75qktof0JJuX+d7DsQINizIkC2ZDNDjcgzpi7IdEqau4M6A
b4dfjjdopfC6YZARRAD8LGqZW5UYSxioLGDRTDCt3xau/fEu7xHFokgp41Bl2WJHWJeQ
Ts2ZHcpg4FeIfBZkAK5Wt06vvIXDT8nGSu7SFPcjOUyN+eF5UkqQKPNMJJZN+5uYSMAk
YOEwjyImvjlSAq3xb7526h/Q9FiuWu4q1lFC4+o9+wnbcNN7EQMTZjZC6yKlbtTaDeFY
qnFA==
X-Received: by 10.194.171.129 with SMTP id au1mr14969034wjc.115.1442677552253;
Sat, 19 Sep 2015 08:45:52 -0700 (PDT)
Received: from [192.168.1.33] ([212.60.121.11])
by smtp.gmail.com with ESMTPSA id
gl4sm14542319wjb.29.2015.09.19.08.45.51
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 19 Sep 2015 08:45:51 -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: <55FCC8B5.9070906@openbitcoinprivacyproject.org>
Date: Sat, 19 Sep 2015 17:45:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4424FA4D-C84F-43DD-BA7F-BAC2D570A373@gmail.com>
References: <5D55F6EC-801B-4607-882F-B76CF57298B1@gmail.com>
<55FC6951.9010704@gmail.com>
<A16FDC0B-877F-47F1-A631-77F46251BB07@gmail.com>
<55FCC8B5.9070906@openbitcoinprivacyproject.org>
To: Justus Ranvier <justus@openbitcoinprivacyproject.org>
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,
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: Sat, 19 Sep 2015 15:45:54 -0000
We need to distinguish between two different things here:
1) A 51% attack, where the majority of mining power is *malicious* =
(hence =E2=80=9Cattack=E2=80=9D)
and
2) A fork that exists because of a disagreement in the network, with =
total mining power split in two camps, each camp mining peacefully on =
their own chain
These are two very different scenarios.
Some claim that including the UTXO set hash in the block creates a =
vulnerability where miners can include the wrong UTXO hash, and mine on =
that, but this is only possible if a 51% attack is in effect. And if a =
51% attack is in effect, it=E2=80=99s a moot point, because Bitcoin is =
useless anyway, because that 51% malicious mining power could just as =
well be used for mining empty blocks on top of the official chain. Or =
blocks containing randomly generated transactions, without confirming =
any legitimate transactions. This is why we say that a majority of =
honest miners is a hard requirement for Bitcoin. A majority of dishonest =
miners can only be circumvented through centralisation, and then we =
don=E2=80=99t have Bitcoin any longer.
Scenario 2 is unproblematic regardless of whether we include the UTXO =
hash in the block (and make it consensus-critical) or not, since the =
majority mining power on either chain isn=E2=80=99t malicious.
It is correct that if you=E2=80=99re a full node, and a 51% attack is in =
effect, you are able to verify that miners are honest (ie. you know =
whether a 51% attack is in effect or not). But this doesn=E2=80=99t =
change the fact that the Bitcoin network is unreliable, at best, when a =
majority of mining power is used for malicious purposes.
/Rune
> On 19 Sep 2015, at 04:30, Justus Ranvier via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> On 18/09/15 15:17, Rune Kj=C3=A6r Svendsen via bitcoin-dev wrote:
>> 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.
>=20
>=20
> None of those statements are true.
>=20
> If a majority of Bitcoin miners are mining invalid blocks, then they
> aren't Bitcoin miners any more and are no longer relevant to the =
Bitcoin
> consensus.
>=20
> There does exist a problem that light clients aren't always able to =
tell
> the difference between chains that are valid and chains that are not
> valid, but it's is possible to create simple proofs that would do so:
>=20
> https://gist.github.com/justusranvier/451616fa4697b5f25f60
>=20
>=20
> If those changes would be implemented, then any node that knew a chain
> was invalid could produce a compact proof that anyone else in the
> network could verify, regardless of how much proof of work was used to
> create the invalid chain.
>=20
> Committed UTXO sets would need safe to rely upon if a similar set of
> proofs that a particular set was invalid existed.
>=20
> --=20
> Justus Ranvier
> Open Bitcoin Privacy Project
> http://www.openbitcoinprivacyproject.org/
> justus@openbitcoinprivacyproject.org
> E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
> <0xEAD9E623.asc>_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
