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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 946438EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2017 19:45:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id E389714D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Jan 2017 19:45:00 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 1544E38A0087;
Sat, 28 Jan 2017 19:43:51 +0000 (UTC)
X-Hashcash: 1:25:170128:natanael.l@gmail.com::L0DQGrovLa4AHXS=:cYl8w
X-Hashcash: 1:25:170128:bitcoin-dev@lists.linuxfoundation.org::P5bOZxpTJVSQDFD+:E35T
X-Hashcash: 1:25:170128:andrew.johnson83@gmail.com::XzSn2jSIbhL5tLaP:bk+m=
From: Luke Dashjr <luke@dashjr.org>
To: Natanael <natanael.l@gmail.com>
Date: Sat, 28 Jan 2017 19:43:48 +0000
User-Agent: KMail/1.13.7 (Linux/4.4.39-gentoo; KDE/4.14.24; x86_64; ; )
References: <201701270107.01092.luke@dashjr.org>
<201701280403.05558.luke@dashjr.org>
<CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>
In-Reply-To: <CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201701281943.49975.luke@dashjr.org>
X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
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 <bitcoin-dev@lists.linuxfoundation.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 19:45:01 -0000
On Saturday, January 28, 2017 10:36:16 AM Natanael wrote:
> Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
> > Satoshi envisioned a system where full nodes could publish proofs of
> > invalid blocks that would be automatically verified by SPV nodes and used
> > to ensure even they maintained the equivalent of full node security so
> > long as they were not isolated. But as a matter of fact, this vision has
> > proven impossible, and there is to date no viable theory on how it might
> > be fixed. As a result, the only way for nodes to have full-node-security
> > is to actually be a true full node, and therefore the plan of only having
> > full nodes in datacenters is simply not realistic without transforming
> > Bitcoin into a centralised system.
>
> Beside Zero-knowledge proofs, which is capable of proving much so more than
> just validity, there are multi types of fraud proofs that only rely on the
> format of the blocks. Such as publishing the block header + the two
> colliding transactions included in it (in the case of double spending), or
> if the syntax or logic is broken then you just publish that single
> transaction.
Why would someone malicious follow the format sufficiently to make those
proofs possible?
> There aren't all that many cases where fraud proofs are unreasonably large
> 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!)
ZK proofs do to a large extent simplify the situation, but still fail in one
case (and one case is all an attacker needs, since he can choose how he
attacks). Specifically, the attacker can create a block which is 100% well-
formed and valid (or not - nobody will really ever know), and simply withhold
a single transaction in it, such that nobody ever has the complete block's
data. Full nodes will of course not accept such a block until they have the
complete data to validate, but they similarly cannot prove it is invalid
without the complete data, and any non-full nodes cannot prove there is data
missing without fetching and (to an extent) checking the entire block
themselves.
Luke
|
