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
|
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 22A5B516
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Mar 2017 05:17:03 +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 B7D1C110
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Mar 2017 05:17:02 +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 35F4F38ABF13;
Sat, 25 Mar 2017 05:16:27 +0000 (UTC)
X-Hashcash: 1:25:170325:bitcoin-dev@lists.linuxfoundation.org::WLT/Ay0rMw9RO=i4:H1eR
X-Hashcash: 1:25:170325:jtimon@jtimon.cc::Oiq5OA/nSaPuws0j:shiR
X-Hashcash: 1:25:170325:lf-lists@mattcorallo.com::4xg2lk2iPD96DTiX:bB49R
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Jorge =?iso-8859-1?q?Tim=F3n?= <jtimon@jtimon.cc>
Date: Sat, 25 Mar 2017 05:16:25 +0000
User-Agent: KMail/1.13.7 (Linux/4.4.45-gentoo; KDE/4.14.28; x86_64; ; )
References: <201703220847.31303.luke@dashjr.org>
<30FB8B13-135D-4905-B1B4-76D79341CA02@mattcorallo.com>
<CABm2gDpgTtiftByQhD_TtzgD5Tv==io2+TGiTCnMt9onquVBmw@mail.gmail.com>
In-Reply-To: <CABm2gDpgTtiftByQhD_TtzgD5Tv==io2+TGiTCnMt9onquVBmw@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-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201703250516.26362.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 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
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: Sat, 25 Mar 2017 05:17:03 -0000
On Thursday, March 23, 2017 6:27:39 PM Jorge Tim=F3n via bitcoin-dev wrote:
> 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.
Creation of proofs isn't part of the spec itself.
I've moved it out of the Specification section (but it's still below it).
> 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.
>=20
> 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.
Added a definitions section above.
> 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,"?
Right, fixed.
> Why do you need to have at least one full tx size?
>=20
> In Rationale you have:
> "
> Why must a full tx size proof be included?
>=20
> This is necessary to establish that the claimed block transaction
> count is correct.
> "
>=20
> 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?
The only way to establish the number of transactions at all, is to show tha=
t a=20
leaf is a parsable transaction. Which this doesn't actually show, so it's=20
broken. :( Need to think on this. Any ideas? :/
Luke
|
