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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
Return-Path: <bram@bittorrent.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 98895B5D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Mar 2017 20:49:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f46.google.com (mail-it0-f46.google.com
[209.85.214.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 25619110
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Mar 2017 20:49:09 +0000 (UTC)
Received: by mail-it0-f46.google.com with SMTP id 190so30183021itm.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Mar 2017 13:49:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bittorrent-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=IDrkOjJV3gjfBUDQkWOMa4jkOKEV4CpW18MiJMFq5hc=;
b=IIOcvDEJKowfd+vnuKdJs5ca40der6vBNZVoRX/UGiGaD4KuKKReb6Lkc05tYPiUNT
fAmeQ+9kW+E0VhnNqQeppkOAF/ZYzEoUHHG+cuWGZWy+fUs7X/JCEvGu48Ungb9ypFcM
69/cNf6tXALDGpQL2rsveIBh1eze2tX33nN/TAeJ4oMLk8jBW0faQM11S8YVb3gFKXtU
9L5YWI2KS/C4f7/GNFd3nSlYKFJR+aPk0QUkU/HGWrGX5arnPsV1C2Ia4eZfx1HA4LJK
lK5CsyXRDh7TLDIXWal37NcYW3XZ2P/8tMqfyWr4HVvOoQvap7zj4k9YTBPFEDzCcRPy
yr+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=IDrkOjJV3gjfBUDQkWOMa4jkOKEV4CpW18MiJMFq5hc=;
b=g62dnIKWbJw8kDZSLSYykP1/bzIwQHjUSMu5bla8lvHJlbyzXGvclmUvZDzHRIx7a0
L73fnUxnjcHAxgwQRVAVoDqp/cZlGDYq5Ri0NDBC5EmCp5sIlzw9KhnxqKzH0HuZr0Uk
ehYx3vmlHu3IityGCJu3blaclN61b6/9kp3O28yC0amjzVdscQMn9+2NtwdWGoJvZ2y6
cwF5LpcP+7aePFViYTMzWDTKD2w+xdjQIEqXTFVnfoKN9MMeQvDWulhKpsynwKCJlRfk
J9SVzfcpQNSuVK4LoNT0c+ccIUqNNsMpTJ03ujYpfY68ThBk2/yO7nWWiBZ4tRbotocc
/sUw==
X-Gm-Message-State: AFeK/H32yhp9CkDmYD/Y7gL1u0+HYKmHVQ3kst3lSagHKS/lJrccNRck3HwniWmZagsMh0HqIVdpqUAdsd0GgLLg
X-Received: by 10.36.86.83 with SMTP id o80mr10272950itb.65.1490215748540;
Wed, 22 Mar 2017 13:49:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.254.132 with HTTP; Wed, 22 Mar 2017 13:49:08 -0700 (PDT)
In-Reply-To: <201703220847.31303.luke@dashjr.org>
References: <201703220847.31303.luke@dashjr.org>
From: Bram Cohen <bram@bittorrent.com>
Date: Wed, 22 Mar 2017 13:49:08 -0700
Message-ID: <CA+KqGkqD0z1O6+pCNaB-vCu_YW2-eO9nmrwcnQ--574t95hghg@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1140464454af5a054b57e42c
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM 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] Fraud proofs for block size/weight
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: Wed, 22 Mar 2017 20:49:09 -0000
--001a1140464454af5a054b57e42c
Content-Type: text/plain; charset=UTF-8
Some questions:
Does this require information to be added to blocks, or can it work today
on the existing format?
Does this count number of transactions or their total length? The block
limit is in bytes rather than number of transactions, but transaction
number can be a reasonable proxy if you allow for some false negatives but
want a basic sanity check.
Does this allow for proofs of length in the positive direction,
demonstrating that a block is good, or does it only serve to show that
blocks are bad? Ideally we'd like an extension to SPV protocol so light
clients require proofs of blocks not being too big, given the credible
threat of there being an extremely large-scale attack on the network of
that form.
On Wed, Mar 22, 2017 at 1:47 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Despite the generalised case of fraud proofs being likely impossible, there
> have recently been regular active proposals of miners attacking with simply
> oversized blocks in an attempt to force a hardfork. This specific attack
> can
> be proven, and reliably so, since the proof cannot be broken without also
> breaking their attempted hardfork at the same time.
>
> While ideally all users ought to use their own full node for validation
> (even
> when using a light client for their wallet), many bitcoin holders still do
> not. As such, they are likely to need protection from these attacks, to
> ensure
> they remain on the Bitcoin blockchain.
>
> I've written up a draft BIP for fraud proofs and how light clients can
> detect
> blockchains that are simply invalid due to excess size and/or weight:
>
> https://github.com/luke-jr/bips/blob/bip-sizefp/bip-sizefp.mediawiki
>
> I believe this draft is probably ready for implementation already, but if
> anyone has any idea on how it might first be improved, please feel free to
> make suggestions.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a1140464454af5a054b57e42c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Some questions:<div><br></div><div>Does this require infor=
mation to be added to blocks, or can it work today on the existing format?<=
/div><div><br></div><div>Does this count number of transactions or their to=
tal length? The block limit is in bytes rather than number of transactions,=
but transaction number can be a reasonable proxy if you allow for some fal=
se negatives but want a basic sanity check.</div><div><br></div><div>Does t=
his allow for proofs of length in the positive direction, demonstrating tha=
t a block is good, or does it only serve to show that blocks are bad? Ideal=
ly we'd like an extension to SPV protocol so light clients require proo=
fs of blocks not being too big, given the credible threat of there being an=
extremely large-scale attack on the network of that form.</div><div><br></=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed,=
Mar 22, 2017 at 1:47 AM, Luke Dashjr via bitcoin-dev <span dir=3D"ltr"><=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">Despite the generalised case of fraud proofs being like=
ly impossible, there<br>
have recently been regular active proposals of miners attacking with simply=
<br>
oversized blocks in an attempt to force a hardfork. This specific attack ca=
n<br>
be proven, and reliably so, since the proof cannot be broken without also<b=
r>
breaking their attempted hardfork at the same time.<br>
<br>
While ideally all users ought to use their own full node for validation (ev=
en<br>
when using a light client for their wallet), many bitcoin holders still do<=
br>
not. As such, they are likely to need protection from these attacks, to ens=
ure<br>
they remain on the Bitcoin blockchain.<br>
<br>
I've written up a draft BIP for fraud proofs and how light clients can =
detect<br>
blockchains that are simply invalid due to excess size and/or weight:<br>
<br>
=C2=A0 =C2=A0 <a href=3D"https://github.com/luke-jr/bips/blob/bip-sizefp/bi=
p-sizefp.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com=
/luke-jr/<wbr>bips/blob/bip-sizefp/bip-<wbr>sizefp.mediawiki</a><br>
<br>
I believe this draft is probably ready for implementation already, but if<b=
r>
anyone has any idea on how it might first be improved, please feel free to<=
br>
make suggestions.<br>
<br>
Luke<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br></div>
--001a1140464454af5a054b57e42c--
|
