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
|
Return-Path: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9B42C71
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 30 Jul 2016 23:18:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com
[209.85.216.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 23ADEE9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 30 Jul 2016 23:18:43 +0000 (UTC)
Received: by mail-qt0-f182.google.com with SMTP id u25so86558762qtb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 30 Jul 2016 16:18:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=from:to:subject:message-id:date:user-agent:mime-version
:content-transfer-encoding;
bh=Uqi7paiJLo9fTDVtk6JXDyVRYwIUlXRZoi5Cn6CEXQc=;
b=Y8ANRVB2GsAiMz0vKuPrAT9tOiEl3fHeWmCbgXXyrFduJtCpyzgb9bQwX4RmMHXBYM
6oRLF2lqbp35ucbT5wiMspcmCTXL+NXGzZGieRqf9awf9aURlVI73xciLJDpAtt1Wbag
23RC1XHjnNtT9CKVFtuCtO+8GpoVIdqxDeh+QEkgTP1CJT2DgxpebZEBoaUo5r+qPhYn
zASPdoEV3hoQf680Kpk/hGUgw19jsaL6M6wlpIL8jq7uEB+aqZDBFq08f7o9o9P8dbdU
VjVSynWUXMaCTb1hPMbJZshckOc3GXaBMnOYOVZ3/AA242DI+9arNdyAiD9uivQjfahO
6ufQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:from:to:subject:message-id:date:user-agent
:mime-version:content-transfer-encoding;
bh=Uqi7paiJLo9fTDVtk6JXDyVRYwIUlXRZoi5Cn6CEXQc=;
b=Mnym2IGfVEGiQBE4eW2XnrPW1doXRTLG2dH2QvSFWNnx9jY4UaDL9GSmu6uYzKfvm9
Xdr19U/uLPokGnIAmBQq830jjc46Cbyz0xMU1BGWSDaJrJ5yqAotB3VhdZJRoUf2Uitu
OCmKCbVH1uRsZ42ByPX+zeQA8xxAvgr41zUhyw6qChpLmkARUfRbAJ8xNpoq0/P3OxPk
91vHoyo9CPiUrvdwyEV1hmUH2bqGClwidCcoVxAu2Y9Vpnmggj1Dux8UCZnFhh5HJFsJ
vO3DNDohvtXQ0U5VsrChLzxs84gNT2B9Xg5L+3BHkOQCC+Q/DPT9S17r2w4x7Yg1YsJc
BZ7w==
X-Gm-Message-State: AEkooutyJmIsQX1FVvEEDfaHhaETy0Tl55sZa+yl1mAw/3q1F0r07gG8F418D3uAZ8g4OA==
X-Received: by 10.200.45.108 with SMTP id o41mr76995964qta.100.1469920721960;
Sat, 30 Jul 2016 16:18:41 -0700 (PDT)
Received: from [192.168.1.100] (ool-4575fa8d.dyn.optonline.net.
[69.117.250.141]) by smtp.googlemail.com with ESMTPSA id
s66sm5759599qkh.20.2016.07.30.16.18.40
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 30 Jul 2016 16:18:41 -0700 (PDT)
From: Paul Sztorc <truthcoin@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <1f12e7bd-72d0-3cd9-735c-10689cff29f3@gmail.com>
Date: Sat, 30 Jul 2016 19:18:36 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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
X-Mailman-Approved-At: Sun, 31 Jul 2016 01:27:11 +0000
Subject: [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: Sat, 30 Jul 2016 23:18:43 -0000
Dear list,
As we know, it would be desirable for Alice, running an SPV client, to ti=
p (say $5) anyone who can prove to her that a given block has invalid con=
tent.
If no one takes these tips, then this is weak evidence that the entire bl=
ock is valid. Alice gets validation, full nodes can get paid...this idea =
goes back to Satoshi's whitepaper.
In my view, "alerts" are relatively straightforward: a new OP CODE (detai=
ls below) st. the txn only succeeds if it references invalid block conten=
t on a "pretender block".
However, my background reading seems to reveal that "fraud proofs" (as th=
ey are now called) require some kind of tremendous engineering overhaul. =
Can anyone point me to these large problem(s)?
Regards,
Paul Sztorc
------------------------------------
Fraud Proof, Simple (?)
1. "OP FraudProof", which:
1. Contains arguments [a] block number (from Alice), [b] block header, a=
nd [c] merkle path from header to an invalid transaction*.
2. Checks to see if the provided header _is_ in the position which Alice=
requested.
2. Checks to see if the header _is_ valid (ie, has sufficient work).
3. Checks to see if the merkle path _does_ lead from the header to "some=
thing invalid"*.
2. This OP Code can then be used in a transaction of the form:
Inputs:
1 from Alice
0.2 from X**
Output:
1.2 to Alice, timelocked
(or)
1.2 to X, OP FraudProof .
3. Alice could sign this txn and circulate it, waiting for "X" to add the=
second signature.=20
"Eric", for example, might sign. As soon as Alice get's Eric's signature,=
she [1] assumes the block *is* invalid, and [2] stops offering to buy Fr=
audProofs on it.
If Eric does not deliver the fraud proof, Alice gets her money back + 0.2=
BTC from Eric (for wasting her time). Alice can't lose -- she either buy=
s a fraud proof for 1, or she gets a free 0.2.
Eric can't lose either. Either he doesn't sign (and nothing happens), or =
he places himself in a position to trade a FraudProof for 1 BTC.
- FraudProof can use "OP Equal" to request fraud for a certain block.
- This can all happen through the lightning network.
* "invalid transaction" is defined either [1] as a script which fails, or=
[2] a double-spend (headers/paths to 2 txns spending the same input). Th=
is definition does not catch bad coinbase transactions, but this doesn't =
concern me. Those outputs aren't spendable for 100 blocks, and anyway, SP=
V clients could be programmed to never accept them (it would be annoying,=
but possible).
** For simplicity, I assume that "FraudProof sellers" will pre-identify t=
hemselves (and their unspent outputs, etc, by making them "watching only"=
or whatever).
---
Now, I wouldn't describe this as a "weekend project", but I wouldn't desc=
ribe it as an "engineering overhaul" either. Just a new OP Code, and code=
to create / scan for these "Alert Transactions". So, if the idea is 5+ y=
ears old, what's the hold up?
I've also heard that segwit will help, but don't understand why.
|
