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
188
189
190
191
192
193
194
195
196
197
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7088F10C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Dec 2018 16:21:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com
[209.85.166.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B4FC912E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Dec 2018 16:21:23 +0000 (UTC)
Received: by mail-io1-f41.google.com with SMTP id f14so2049510iol.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Dec 2018 08:21:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=+LCfMyjUtr3HE2MXp00KdNhBbsQUc/GoF2AwX/IrFYY=;
b=CbzdIQUUOCfSmIU1dDOPMuUp7S8+KPCz+higxIoagIFTJU6SL14N/hqEUOJUlx40MC
knf8SwYxKc/kQHUgXr3VTgVTeDjkR6czV3EWXXBi2ppYembGdS7b9cq5lZbH6wg5TvKI
6B/Mhd62IPI7hGekhjYKnwORGEZtE867umAkc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=+LCfMyjUtr3HE2MXp00KdNhBbsQUc/GoF2AwX/IrFYY=;
b=qM25JNehVqWYySI3BYzc4ZM7ue5c8qUg0XjAbV5x98/hMlFk1V79XGqq4dG6vQQKz9
cENqmJJRRZboFen5TX7aPBgBJFFFYcaciM0jvm+LvAM6fJWmUaptC4wHdPEq9U/QBx9O
Ymz61x1zbfYE3pAYyohrgM+iyr/J8I1QuaYXcSx108d7cY0KHY6mXGcItSptuX4dWZFk
dEX8AgXFO2qFLYF3KFFA8LhWTaThhuJA5G6Z/87bGQv9BVft2SUUUlf/003yxS9wq7SG
fm74J4mUU7/DPe+bjQgRpk7ZlyIdXJLLU6X0RzNh1GVkMz23UhJinWdVzfFF3dFq01VO
Krrg==
X-Gm-Message-State: AA+aEWYy8RrBfoi/JYsX8dmJSymjNsPeSuFgpohWtaewMDjcgqbdmPka
iP+wZP/HQJK3Hw00W7NEsNPlE0+ucG0P8z5GplzB94mTXLk=
X-Google-Smtp-Source: AFSGD/WmNgMs/vzXE2XaVv65j2bB7xXRZ7mOSb0NOKR6VYNfCpghej5rQF+9wFYDWkWuG7c7Zda0xOyQMZidfombTH8=
X-Received: by 2002:a6b:4001:: with SMTP id k1mr22473956ioa.34.1544718082747;
Thu, 13 Dec 2018 08:21:22 -0800 (PST)
MIME-Version: 1.0
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
<CAPg+sBiu0BjZEtz-t7m3M+TnAEDG_k1GKtxwkOKh6qrSezUO7g@mail.gmail.com>
<CAMZUoKkJdU0P_dVRvHn5zY6xUHYUptdK221ioQMp3FXZAerp3Q@mail.gmail.com>
<702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk>
<CAMZUoKkYcXt7O39zdpz494f9Jm195mBtWyrH3siX4PBEAf8OKQ@mail.gmail.com>
<20181213000553.cikilodf65an225g@erisian.com.au>
In-Reply-To: <20181213000553.cikilodf65an225g@erisian.com.au>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Thu, 13 Dec 2018 11:21:10 -0500
Message-ID: <CAMZUoKkPCNaPyiSanDH8cAZuybywZsNE0ErYJTctcYc+VAWQxg@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="0000000000009a064b057ce9b417"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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: Thu, 13 Dec 2018 22:09:29 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
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, 13 Dec 2018 16:21:24 -0000
--0000000000009a064b057ce9b417
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, Dec 12, 2018 at 7:06 PM Anthony Towns <aj@erisian.com.au> wrote:
> On Tue, Dec 11, 2018 at 05:50:24PM -0500, Russell O'Connor via bitcoin-de=
v
> wrote:
> > On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau <jl2012@xbt.hk> wrote:
> > The current proposal is that a 64-byte signature will be used for t=
he
> > default =E2=80=9Csigning all=E2=80=9D sighash, and 65-byte for othe=
r sighash types.
> The
> > space saved will allow a few more txs in a block, so I think it
> worths
> > doing. However, this also makes witness weight estimation more
> difficult in
> > multisig cases.
>
> This seems strange to me -- why wouldn't you just assume every signature
> is 65 witness bytes, and just be grateful for the prioritisation benefit
> if someone chooses a shorter signature? Your error margin is just 0.25
> vbytes per signature.
>
The issue is that the proposal is to sign the actual weight, rather than
sign an upper bound on the weight.
The problem with signing an upper bound, is that you need to specify that
upper bound someplace in the transaction, and we are out of sneaky places
to stash that data.
Signing the actual weight is easy because the total weight is implicit, but
now you need to know the total weight before signing.
> > I tend to think in opposite terms. Is there a proof that any script can
> be
> > transformed into an equivalent one that avoids witness weight
> malleability?
>
> An alternative generalisation: is there a proof that all valid witnesses
> will have a weight within some small range?
>
> > Moreover, even if witness weight malleability is entirely avoidable, it
> always
> > seems to come at a cost. Taking as an example libwally's proposed "
> > csv_2of3_then_2" Script, it begins with "OP_DEPTH OP_1SUB OP_1SUB"
>
> (DEPTH 2 NUMNOTEQUAL seems like it would have been more obvious...)
>
> I think the 1SUB idea was derived from the csv_2of2_then_1 Script where
DEPTH 1SUB is shorter than DEPTH 1 NUMNOTEQUAL.
> Cheers,
> aj
>
>
--0000000000009a064b057ce9b417
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Dec 12=
, 2018 at 7:06 PM Anthony Towns <<a href=3D"mailto:aj@erisian.com.au">aj=
@erisian.com.au</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On T=
ue, Dec 11, 2018 at 05:50:24PM -0500, Russell O'Connor via bitcoin-dev =
wrote:<br>
> On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau <<a href=3D"mailto:jl201=
2@xbt.hk" target=3D"_blank">jl2012@xbt.hk</a>> wrote:<br>
>=C2=A0 =C2=A0 =C2=A0The current proposal is that a 64-byte signature wi=
ll be used for the<br>
>=C2=A0 =C2=A0 =C2=A0default =E2=80=9Csigning all=E2=80=9D sighash, and =
65-byte for other sighash types. The<br>
>=C2=A0 =C2=A0 =C2=A0space saved will allow a few more txs in a block, s=
o I think it worths<br>
>=C2=A0 =C2=A0 =C2=A0doing. However, this also makes witness weight esti=
mation more difficult in<br>
>=C2=A0 =C2=A0 =C2=A0multisig cases.<br>
<br>
This seems strange to me -- why wouldn't you just assume every signatur=
e<br>
is 65 witness bytes, and just be grateful for the prioritisation benefit<br=
>
if someone chooses a shorter signature? Your error margin is just 0.25<br>
vbytes per signature.<br></blockquote><div><br></div><div>The issue is that=
the proposal is to sign the actual weight, rather than sign an upper bound=
on the weight.</div><div>The problem with signing an upper bound, is that =
you need to specify that upper bound someplace in the transaction, and we a=
re out of sneaky places to stash that data.</div><div>Signing the actual we=
ight is easy because the total weight is implicit, but now you need to know=
the total weight before signing.<br></div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
> I tend to think in opposite terms. Is there a proof that any script ca=
n be<br>
> transformed into an equivalent one that avoids witness weight malleabi=
lity?<br>
<br>
An alternative generalisation: is there a proof that all valid witnesses<br=
>
will have a weight within some small range?<br>
<br>
> Moreover, even if witness weight malleability is entirely avoidable, i=
t always<br>
> seems to come at a cost.=C2=A0 Taking as an example libwally's pro=
posed "<br>
> csv_2of3_then_2" Script, it begins with "OP_DEPTH OP_1SUB OP=
_1SUB"<br>
<br>
(DEPTH 2 NUMNOTEQUAL seems like it would have been more obvious...)<br>
<br></blockquote><div>I think the 1SUB idea was derived from the <span clas=
s=3D"gmail-pl-en">csv_2of2_then_1 Script where DEPTH 1SUB is shorter than D=
EPTH 1 NUMNOTEQUAL.<br></span></div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
Cheers,<br>
aj<br>
<br>
</blockquote></div></div>
--0000000000009a064b057ce9b417--
|
