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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 720682C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2017 21:54:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149080.authsmtp.com (outmail149080.authsmtp.com
[62.13.149.80])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id A915C79
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2017 21:54:11 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v0SLs7RU087250;
Sat, 28 Jan 2017 21:54:07 GMT
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v0SLs5Wg007935
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sat, 28 Jan 2017 21:54:06 GMT
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id B4D37408A4;
Sat, 28 Jan 2017 21:54:04 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id AED2E200DA; Sat, 28 Jan 2017 16:54:00 -0500 (EST)
Date: Sat, 28 Jan 2017 16:54:00 -0500
From: Peter Todd <pete@petertodd.org>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20170128215400.GA1246@fedora-23-dvm>
References: <201701270107.01092.luke@dashjr.org>
<201701280403.05558.luke@dashjr.org>
<CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>
<201701281943.49975.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI"
Content-Disposition: inline
In-Reply-To: <201701281943.49975.luke@dashjr.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 4a6d61d5-e5a4-11e6-829f-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdAoUElQaAgsB AmEbWVVeVVl7WWU7 bghPaBtcak9QXgdq
T0pMXVMcUgULfV8E YUkeUh57dAAIeX12 bUAsWiFdCEJ7IUNg
F0sFEXAHZDJmdWgd WRZFdwNVdQJNdxoR b1V5GhFYa3VsNCMk
FAgyOXU9MCtqYBhV WAwAZVIbW0oFGSQ/ AgoPGTwzEEFNbQQL NHQA
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] Three hardfork-related BIPs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 28 Jan 2017 21:54:12 -0000
--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 28, 2017 at 07:43:48PM +0000, Luke Dashjr via bitcoin-dev wrote:
> On Saturday, January 28, 2017 10:36:16 AM Natanael wrote:
> > There aren't all that many cases where fraud proofs are unreasonably l=
arge
> > for a networked system like in Bitcoin. If Zero-knowledge proofs can be
> > applied securely, then I can't think of any exceptions at all for when =
the
> > proofs would be unmanageable. (Remember that full Zero-knowledge proofs=
can
> > be chained together!)
>=20
> ZK proofs do to a large extent simplify the situation, but still fail in =
one=20
> case (and one case is all an attacker needs, since he can choose how he=
=20
> attacks). Specifically, the attacker can create a block which is 100% wel=
l-
> formed and valid (or not - nobody will really ever know), and simply with=
hold=20
> a single transaction in it, such that nobody ever has the complete block'=
s=20
> data. Full nodes will of course not accept such a block until they have t=
he=20
> complete data to validate, but they similarly cannot prove it is invalid=
=20
> without the complete data, and any non-full nodes cannot prove there is d=
ata=20
> missing without fetching and (to an extent) checking the entire block=20
> themselves.
So, in that particular type of case, the ZK proof may show that the block
itself is valid and follows all the rules; there'd be no need to get the bl=
ock
data to know that.
The issue here is other miners being able to mine. Exactly what happens here
depends on the exact construction of the ZK proofs, but at best the missing
data will mean that part of the UTXO state can no longer be updated by other
miners, and thus they can't mine all transactions; at worst they'd be
completely preventing from mining at all.
This is why part of the economic pressure that users exert on miners is
subverted by SPV/lite-clients: users that can transact without sufficient
blockchain data to allow others to mine aren't exerting pressure on miners =
to
allow other miners to mine - particularly new entrants to mining. In that
respect, ZK proofs are in fact quite harmful to the security of the system =
if
applied naively.
Equally, I'll point out that if ZK proofs can be made sufficiently powerful=
to
do all the above, genuinely scalable sharded systems like my own Treechains=
are
far easier to implement, changing the discussion entirely. Currently it is =
far
=66rom proven that ZK proofs can in fact accomplish this; I hear that Zcash=
will
soon have to upgrade their ZK-SNARK scheme due to advances in cryptographic
analysis that may result in a full system break in the near future. We real=
ly
don't want to be depending on that technology for Bitcoin's security until
events like that become much less common.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--+HP7ph2BbKc20aGI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJYjRLxAAoJECSBQD2l8JH7jHQIALdFVGvABjtQFCiCu0CPqHL9
2ADJvnUs4mX52HbOJ+pOksG9fzUHNp8XbSkBLuGw3MEzcOO22B/ne+2RyBPVPFZp
7t/ahx+UroYOiAkHZiL722z81482EdP+OqKnmjBUMzUciIj61kNMk3sPfcnHvHZn
VOWUkVV99rcqilN5xT71zG78KYrCSc2uhaHhsjIMV9d6MSoBR/vtReFm6UsGXazy
BsHii6vu1ysF9M+HjTcRHEMhanHqgncYiSEuehvINcLlLiiYZNE44+i3uzFxhi/w
yNkU9mlT16Blx/5OkL6dVUmkCtRuGHtrhjmYGbzrGF984SMGthHT6Z8KBM2cptc=
=GwDu
-----END PGP SIGNATURE-----
--+HP7ph2BbKc20aGI--
|
