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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A2372258
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 16:23:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s37.web-hosting.com (s37.web-hosting.com [198.54.114.154])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 012371EA
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Jun 2016 16:23:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xbt.hk;
s=default; h=Mime-Version:To:Message-Id:Date:Subject:Content-Type:From;
bh=Kp8jn7FJ7VggEl2P0bWe+SBv5es3xBWpxywgrCJ6qWQ=;
b=RNZMwAt4OlkWuc19+7NEB7OhoR
9/ID43z1thskQtGefwkE/7H8xUye5DjMe+Ur7pKboNLFglU9RlX41cUC/+SqpBJ9E7Iqewtl/C9mh
YGTvBt2AJQDseOAa0ELSB0RJYB/yPuSEll15YSVGb8s8SGHls2HogL226n/n5HZnf/0jTjAR6bH84
wK3Rxi6H6emIIKiR9zkYxd8bogv6ptQGCVd3Wil5F1TBIPWkn7Vy2r0KkEQSl4FfAta6Gt8zaGBgg
+k89txuEdr2CBcDKXnAtMG91n2cgTGHr8e4zp/liI3o7Dy/GBDAcOt+KXeslnpxGa6R7dxoIYBb5M
WF33kC0w==;
Received: from 119246245241.ctinets.com ([119.246.245.241]:62693
helo=[10.8.8.2])
by server37.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.86_1) (envelope-from <jl2012@xbt.hk>) id 1bHvnk-0039AP-MS
for bitcoin-dev@lists.linuxfoundation.org;
Tue, 28 Jun 2016 12:23:52 -0400
From: Johnson Lau <jl2012@xbt.hk>
X-Pgp-Agent: GPGMail 2.6b2
Content-Type: multipart/signed;
boundary="Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893";
protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Wed, 29 Jun 2016 00:22:45 +0800
Message-Id: <8AE6D76F-7808-4897-9F44-A83790545EE4@xbt.hk>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server37.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server37.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Authenticated-Sender: server37.web-hosting.com: jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
T_DKIM_INVALID 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] Code Review: The Consensus Critical Parts of
Segwit by Peter Todd
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: Tue, 28 Jun 2016 16:23:54 -0000
--Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Thanks for Peter Todd=E2=80=99s detailed report:
https://petertodd.org/2016/segwit-consensus-critical-code-review
I have the following response.
>Since the reserve value is only a single, 32-byte value, we=E2=80=99re =
setting ourselves up for the same problem again7.
Please note that unlimited space has been reserved after the witness =
commitment:
block.vtx[0].vout[o].scriptPubKey.size() >=3D 38
Which means anything after 38 bytes has no consensus meaning. Any new =
consensus critical commitments/metadata could be put there. Anyway, =
there is no efficient way to add a new commitment with softfork.
> the fact that we do this has a rather odd result: a transaction =
spending a witness output with an unknown version is valid even if the =
transaction doesn=E2=80=99t have any witnesses!
I don=E2=80=99t see any reason to have such check. We simply leave =
unknown witness program as any-one-can-spend without looking at the =
witness, as described in BIP141.
> Bizzarely segwit has an additonal pay-to-witness-pubkey-hashP2WPKH =
that lets you use a 160-bit (20 byte) commitment=E2=80=A6=E2=80=A6
Since ~90% of current transactions are P2PKH, we expect many people will =
keep using this type of transaction in the future. P2WPKH gives the same =
level of security as P2PKH, and smaller scriptPubKey.
>give users the option instead to choose to accept the less secure =
160-bit commitment if their use-case doesn=E2=80=99t need the full =
256-bit security level
This is actually discussed on the mailing list. P2WSH with multi-sig is =
subject to birthday attack, and therefore 256-bit is used to provide =
128-bit security. P2WPKH is used as single sig and therefore 160-bit is =
enough.
>Secondly, if you are going to give a 160-bit commitment option, you =
don=E2=80=99t need the extra level of indirection in the P2SH case: just =
make the segwit redeemScript be: <version> <serialized witness script>
Something wrong here? In P2WPKH, the witness is <sig> <pubkey>
>The only downside is the serialized witness script is constrained to =
520 bytes max
520 is the original limit. BIP141 tries to mimic the existing behaviour =
as much as possible. Anyway, normally nothing in the current scripts =
should use a push with more than 75 bytes
>we haven=E2=80=99t explicitly ensured that signatures for the new =
signature hash can=E2=80=99t be reused for the old signature hash
How could that be? That=E2=80=99d be a hash collision.
--Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQGcBAEBCgAGBQJXcqSVAAoJEO6eVSA0viTS998L/jOkRYqUfR7WmSuoj3y3JQ+o
+uLlAegQQVA1gLBloXh8c2PdGF9frn/FCAaiJec/rbXh2/9Pvwpq9QW2TLjGFAjT
5Ht+lTVZGdZHg9fU0jCZs53BRBO8v0v8xnUVpXovXxLiga8OHu5RxhtsGTGZLaq6
N1oNVbO9Z2yCihW+Tc8qTtHn1mjLZ0zc6IIRNbR9aCrH84euXu058HcvAHKcixGK
wCZFVS3U+K2EeHSzHyNWaG2pK9egCswAUBcnq6WPUOcknlO7Y1jT8DSI5Xr76h+W
baJ7XKlQ2FV6hdeP6S2XiRk3amJ+SG0HX3a/ZJYa4rNeaoC9yzIa7soXvWdC+D2P
+Q3XjLKWkc8X06OwownqUDg9Yst4jNQYeDplzySKtf6pWPNHyjKKvxThtw64s3Ve
Gv6bpJKRhUrolo4yIlMO1kdxGgOIkNtKQN4/0NdxWhzf9vyFI3ybqIbPGkVx7n7N
B2ndc1zWjZ+5xGNu7wRbWbRMEK9dCUaXgov7+bGcnQ==
=etKP
-----END PGP SIGNATURE-----
--Apple-Mail=_A8F00CFC-7625-4E29-9143-A1BBEF26C893--
|
