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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5C86C98C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 18:27:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com
[209.85.213.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A85A72E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 18:27:40 +0000 (UTC)
Received: by mail-vk0-f43.google.com with SMTP id r69so41809068vke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Mar 2017 11:27:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=U6U6Bxz0reG1p6pi+V9VQn3i/v4EHIiRYhBFrpuM+44=;
b=KDgSQc3nf6PHBXIfNJFGEe94wW6dEkrh2X41LYmBchNeWik6ZiOmD4JZztJ1bR+dkf
3LO1+fMWlNwPEsX9To/kLOi0xyF+3FzQW2I1saMf4v8FtiSQyj/0sOFIfc357eMtJXLv
BoEx2WLZWNSnSZ0G5/k8BSTnEgT+LDkRM4Sjcj2WwTybn2THi6E9efWb7LC2YCWYbpoy
frPr0XlQP3Rp5gfbacFn6E1MAlLwuVhPNgYgiUisrrgsSJMlF4OZjNVK2q4qbgFwdXB3
+bHNMUoTQ2HtewfuNovdLLO7SFsoivTaLBjnaI/QSh8jkTI2gIEklJf4KcYBj1IN8Cbw
pdxw==
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=U6U6Bxz0reG1p6pi+V9VQn3i/v4EHIiRYhBFrpuM+44=;
b=ktne/4haw3d9wTNtDxS0QZGQgHu9ksrKb/IVIltGcc5o5EEN8z5U4XVWhA22obEWs4
iX5hR+MbcZRpcol8KJfFqC+olYcbMiPSys5b3CJAJ9RRPV7+qgFuB34Dc7T4tbveWSBA
AYnFNu7WnLqsB2HdKthSTnC4F3zgnOSaFyXTwviJl0as48mtJCeINEJtNzEApowOticb
+blcRIEg7b84bdtboE/JvKF3FACAYjr7Q7S26WqQ9bSKnkzd/V7mEktxMb1RXuyWoDqK
s2Wmwz1vqvTBNoWDBEc+atfB6aLqPXNLD0Hmf/sLCRGB1VnTEl87+EM27sG6CoBkiFx7
biPw==
X-Gm-Message-State: AFeK/H3DxthrxqWXnocMOvyeM16k9H41TPwT0Whk68WtjVaqcJ1uRC/i967a8FiAE1XmxZwmcMercbxod9HSwA==
X-Received: by 10.31.234.3 with SMTP id i3mr1897835vkh.36.1490293659648; Thu,
23 Mar 2017 11:27:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.151.136 with HTTP; Thu, 23 Mar 2017 11:27:39 -0700 (PDT)
In-Reply-To: <30FB8B13-135D-4905-B1B4-76D79341CA02@mattcorallo.com>
References: <201703220847.31303.luke@dashjr.org>
<CA+KqGkqD0z1O6+pCNaB-vCu_YW2-eO9nmrwcnQ--574t95hghg@mail.gmail.com>
<30FB8B13-135D-4905-B1B4-76D79341CA02@mattcorallo.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Thu, 23 Mar 2017 19:27:39 +0100
Message-ID: <CABm2gDpgTtiftByQhD_TtzgD5Tv==io2+TGiTCnMt9onquVBmw@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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: Thu, 23 Mar 2017 18:27:41 -0000
Great stuff, although the ordering of the sections seems a little bit confusing.
I think it would be clearer to put the "Creation of proofs" section
before "Proof verification", maybe even before "Proof format" if a
high level defintion of "full tx size proof" is provided before.
Also, in "For the full-size proof, each transaction should be assumed
to be at a minimum the stripped-size rather than the fixed 60 bytes."
it seems you are referring to a "full-size block proof" as opposed to
a "full size tx proof", perhaps a better term could be "full-weight
block proof" if what you are referring to is the proof of the weight
instead of only the pre-segwit size.
Perhaps some short definitions for "stripped-size proof", "full tx
size proof", "full-size proof" and maybe also "size component" at the
beginning would be enough.
In "Network protocol", "It should not recheck blocks known to be
valid, " does "known to be valid" include the blocks that the peer
told us where valid (with their hash and 0 in the enumerated varint)?
Those could be invalid too if the peer was lying, no?
Do you mean "It should not recheck blocks known to be invalid,"?
Why do you need to have at least one full tx size?
In Rationale you have:
"
Why must a full tx size proof be included?
This is necessary to establish that the claimed block transaction
count is correct.
"
Why do you need to establish that? If you can establish that the
number of transactions is at least N and that N * 60 bytes is greater
than the size/weight limit, isn't it that enough?
On Wed, Mar 22, 2017 at 10:51 PM, Matt Corallo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> It works today and can be used to prove exact size: the key observation is
> that all you need to show the length and hash of a transaction is the final
> SHA256 midstate and chunk (max 64 bytes). It also uses the observation that
> a valid transaction must be at least 60 bytes long for compression (though
> much of that compression possibility goes away if you're proving something
> other than "too large").
>
>
> On March 22, 2017 1:49:08 PM PDT, Bram Cohen via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> 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
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
