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
|
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 3B9D1723
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 31 Jul 2016 05:18:39 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (unknown [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id D0E4613A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 31 Jul 2016 05:18:38 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id A47BD38A17C5;
Sun, 31 Jul 2016 05:18:21 +0000 (UTC)
X-Hashcash: 1:25:160731:bitcoin-dev@lists.linuxfoundation.org::ZgGHAY/8+HsbIFtr:ayX=P
X-Hashcash: 1:25:160731:truthcoin@gmail.com::0t7sCQLULXevhZpp:abJmo
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Paul Sztorc <truthcoin@gmail.com>
Date: Sun, 31 Jul 2016 05:18:18 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.20; x86_64; ; )
References: <1f12e7bd-72d0-3cd9-735c-10689cff29f3@gmail.com>
In-Reply-To: <1f12e7bd-72d0-3cd9-735c-10689cff29f3@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-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201607310518.20489.luke@dashjr.org>
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC
autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?
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: Sun, 31 Jul 2016 05:18:39 -0000
On Saturday, July 30, 2016 11:18:36 PM Paul Sztorc via bitcoin-dev wrote:
> In my view, "alerts" are relatively straightforward: a new OP CODE (details
> below) st. the txn only succeeds if it references invalid block content on
> a "pretender block".
>
> However, my background reading seems to reveal that "fraud proofs" (as they
> are now called) require some kind of tremendous engineering overhaul. Can
> anyone point me to these large problem(s)?
Essentially this comes down to attackers being able to construct a block for
which invalidity cannot be proven. While you could always show a proof for an
invalid transaction within a well-formed block, you cannot show a proof that a
block is not well-formed. For example, the merkle tree that ought to represent
a set of transactions may be corrupted in such a manner that the transaction
paying Alice can have a SPV proof made, but the links in the merkle path have
no known data (transactions) behind them. This could even be a perfectly valid
block, but with some of the transactions withheld until it is stale - full
nodes and miners cannot accept it without knowing the entire block's
transactions. The only solution to this I am aware of, is for Alice to be told
"hey, block XYZHASH is incomplete and cannot be checked", and then Alice
demands the full block from the attacker. But of course this makes it trivial
to DoS Alice by giving her bogus incomplete-block claims and forcing her to
use the same bandwidth as a full node - which is a major problem if she lacks
the bandwidth to run a full node (presumably her reason for using SPV in the
first place).
Luke
|
