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
|
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 6BDBED56
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Dec 2018 16:34:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f53.google.com (mail-io1-f53.google.com
[209.85.166.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8B1D82E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Dec 2018 16:34:30 +0000 (UTC)
Received: by mail-io1-f53.google.com with SMTP id f14so2090460iol.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Dec 2018 08:34:30 -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=tsnZ3d9kAd9dM3gJtrdRN1JJeoPn98Tb1Ae7pLhDA24=;
b=EM/e6Nd3F4tWZs9mei6B/XKpd9eQ6tYhgSUXxRpaIneSDyxpNTr4IPRdFNZjEJa5L0
LdiA9U0YWJuolR0bFcaD3LvOZLxAmt8yzh7RRfE/VnRQ0ZoZKCxiXZy+TS6PmLUj84PA
tC1Ga1pchN3TeXTmFdm7siY6WbQXNltKWbpGQ=
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=tsnZ3d9kAd9dM3gJtrdRN1JJeoPn98Tb1Ae7pLhDA24=;
b=O8LuybI8mMRUPEygAUL+d1jnaikDfaLqPl21e389yDwJCC77gvqfrg67xhHx4Qjqr/
ThhriJZFQgfvtdAXNBRQ5HfhOhlRxFhIdkqEbi8PizhbrLwT4Q4hPcaXYeFjMmyY5ANC
Rci7J2SzUyIcLFbnmJu1iwPj1IHik8aV29SjC98pnZuinJPsLn3Yx+l1kNj4lqF4Uolr
i/DUY732yYSD70oEyCCoG2xcEeet1OkOwxqlNrSgSF6GA+GqtW3wf5oekWRl6pRCWq+h
pitE+MbAwwSgiBsZYLGf2msSoLA03DRvx/L8sXFLo5ge2LHWtWUNMzujeeUg2fDs+p91
DVsw==
X-Gm-Message-State: AA+aEWZ1RF/5ER6dcA7UOjmblwR4haXP4k5Fd7OKkLQJNnVlw74s+N8p
t7L2vq9nXbeQgcw5yPb7yd4YsscwlmatMJfmz7dDJg==
X-Google-Smtp-Source: AFSGD/WSPHF2Bm3YFnHLFCxnIOKmBBO1jPE4qagFdgAzkY7xCjeT9SoFCChwYJzdl4mbwMsNXnGAcbS8m9YMW5ICAps=
X-Received: by 2002:a5d:9257:: with SMTP id e23mr23373483iol.112.1544718869800;
Thu, 13 Dec 2018 08:34:29 -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>
<CAAS2fgRma+Pw-rHJSOKRVBqoxqJ3AxHO9d696fWoa-sb17JEOQ@mail.gmail.com>
In-Reply-To: <CAAS2fgRma+Pw-rHJSOKRVBqoxqJ3AxHO9d696fWoa-sb17JEOQ@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Thu, 13 Dec 2018 11:34:17 -0500
Message-ID: <CAMZUoKnFCHA+6F1trmH6UYXTXfdwEA08z3q=b0trvdZqjH67qw@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008349ca057ce9e334"
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:34:31 -0000
--0000000000008349ca057ce9e334
Content-Type: text/plain; charset="UTF-8"
On Wed, Dec 12, 2018 at 12:26 PM Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Wed, Dec 12, 2018 at 5:15 PM Russell O'Connor via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 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? But I admit there is a trade off: If we don't allow for
> signature covers weight, and we do need it, it will be too late to add. On
> the other hand if we add signature covers weight, but it turns out that no
> Script ever needs to use it, then we've added that software complexity for
> no gain. However, I think the software complexity is relatively low,
> making it worthwhile.
> >
> > 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"
>
> I'm largely in agreement with you-- but my difficulty in arguing for
> signing the weight is that it seemed to me that it was only easy to
> sign an upper bound because some witnesses are variable size... and
> signing an upper bound means more signalling overhead... offsetting
> the space gains for demalleating.
>
In multi-party protocols, the last person to sign knows what the total
weight is going to be (now that we have fixed sized signatures) and at
least they have the ability to sign it. They are probably motivated to
sign the weight as long as they are interested in the success of the
transaction. I suppose there could be asynchronous protocols where there
isn't a last person to sign, but that seems a bit weird. Greg, you are
probably more familiar with examples of multi-party protocols than I am.
OTOH maybe the last person to sign isn't interested in the success of the
transaction and wants to cause grief by bloating the transaction and
signing the bloated weight. I guess in such protocols, you'll have to keep
the anti-malleablity Script Code.
I totally get the idea that signing weight has a lot of issues in many
scenarios. But I still feel than on the whole it is better to make the
option available than to be forced to rely on anti-malleability Script Code
or non-consensus relay policy.
--0000000000008349ca057ce9e334
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed=
, Dec 12, 2018 at 12:26 PM Gregory Maxwell <<a href=3D"mailto:gmaxwell@g=
mail.com">gmaxwell@gmail.com</a>> wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">On Wed, Dec 12, 2018 at 5:15 PM Russell O'Connor via bitcoin-d=
ev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> I tend to think in opposite terms. Is there a proof that any script ca=
n be transformed into an equivalent one that avoids witness weight malleabi=
lity?=C2=A0 =C2=A0But I admit there is a trade off:=C2=A0 If we don't a=
llow for signature covers weight, and we do need it, it will be too late to=
add.=C2=A0 On the other hand if we add signature covers weight, but it tur=
ns out that no Script ever needs to use it, then we've added that softw=
are complexity for no gain.=C2=A0 However, I think the software complexity =
is relatively low, making it worthwhile.<br>
><br>
> Moreover, even if witness weight malleability is entirely avoidable, i=
t always seems to come at a cost.=C2=A0 Taking as an example libwally's=
proposed "csv_2of3_then_2"<br>
<br>
I'm largely in agreement with you-- but my difficulty in arguing for<br=
>
signing the weight is that it seemed to me that it was only easy to<br>
sign an upper bound because some witnesses are variable size... and<br>
signing an upper bound means more signalling overhead... offsetting<br>
the space gains for demalleating.<br></blockquote><div><br></div><div>In mu=
lti-party protocols, the last person to sign knows what the total weight is=
going to be (now that we have fixed sized signatures) and at least they ha=
ve the ability to sign it.=C2=A0 They are probably motivated to sign the we=
ight as long as they are interested in the success of the transaction.=C2=
=A0 I suppose there could be asynchronous protocols where there isn't a=
last person to sign, but that seems a bit weird.=C2=A0 Greg, you are proba=
bly more familiar with examples of multi-party protocols than I am.<br></di=
v><div><br></div><div>OTOH maybe the last person to sign isn't interest=
ed in the success of the transaction and wants to cause grief by bloating t=
he transaction and signing the bloated weight.=C2=A0 I guess in such protoc=
ols, you'll have to keep the anti-malleablity Script Code.</div><div><b=
r></div><div>I totally get the idea that signing weight has a lot of issues=
in many scenarios.=C2=A0 But I still feel than on the whole it is better t=
o make the option available than to be forced to rely on anti-malleability =
Script Code or non-consensus relay policy.<br></div></div></div>
--0000000000008349ca057ce9e334--
|
