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
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
|
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 354311BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 19:06:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com
[209.85.217.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 24E951AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 19:06:00 +0000 (UTC)
Received: by mail-ua0-f179.google.com with SMTP id b34so2212260uab.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 01 Oct 2017 12:06:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-io.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=udfWgMikJ3sebgGUNJycpjYlrVxydQTQ38Kfpy9WNeM=;
b=1SfxneSdvzPyd9lAS9o+OE3GZjA3ZAzSjU3eQVpaVoqAzP69kgaYfsxOHFdt3LU8Wg
0QGEI6MO5/j5rPvVzmnt8h6CxPG9ST/KXJwnLxuRw3bbx7ujLIC1sM+M+kS834tOQYxd
5H//59gR1HpovyPQMx0UPlo7BU11GWf0JPNf0trWS0Z1VaYuDdam7s65Nb8appaSAt81
jl85nXkUdudtfaZvpACsZWLn9f6t/PZMjLS/jaSvwWq7/SksmFQZPvNv0pHf+9Cw1nw4
vp9va3s84Ao6yDdp27IRKFBpv61UESMclcSZs6HqaVVhpi16hiksAswCx6kuyQDOniSA
E7NA==
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:cc;
bh=udfWgMikJ3sebgGUNJycpjYlrVxydQTQ38Kfpy9WNeM=;
b=d2mtyBe1m62CKVS5yx2hhV+65VzoM64nDptmmxAp1JR5MAjG4z6oVFugaRtQYiwPag
4p/E68WahNYXZDRiyrNJAeBEUo89BezjBR1t/1CH6D5kYrmF5pLlLOQeJjYjpuAxXHS4
2AdNCiZ67xdJnlHpGEfJ3RkxgfhcQTSr4EaojhdYPiWosg1oYBebCLg7IMsZCME22I2e
ILiuwqUnbNdTkNlYnushjwvjKgE4odrh+XSDIYLMQ3M4NQA71o0wijIHRQe2KkdeECWt
gfPCP/hKZGXsQKQ/iebEeHJvwPviAy1PfRkmmH9p6gfFsliTipT/7NCQS2oiaGKt/nXN
PNnQ==
X-Gm-Message-State: AHPjjUhswdSd/XSURR1BqSF9azQmeG3Us5egZeEdZjecLhn/6xHHdOdE
6Wc+AMcb+lxAmaBJiFdJSExGkAeDYMU1MW38RlQdlg==
X-Google-Smtp-Source: AOwi7QCa5JreJDsVUCbiBIo+KzLBShAL1WsV0nAJOzbtkEDS5tBT/ZyIvxDIcPp+p+INhdcVXIDzIUbPeBj5ePJvtMI=
X-Received: by 10.159.37.201 with SMTP id 67mr7742333uaf.59.1506884759128;
Sun, 01 Oct 2017 12:05:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.41.161 with HTTP; Sun, 1 Oct 2017 12:05:38 -0700 (PDT)
In-Reply-To: <D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org>
References: <201710010113.30518.luke@dashjr.org>
<5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org>
<201710010247.42180.luke@dashjr.org>
<D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sun, 1 Oct 2017 15:05:38 -0400
Message-ID: <CAMZUoK=1fZUeKkA6V2pFwqj-Fd-YnZD4sffP9yc0Y7vv8-XvhQ@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113c4f3cc92a39055a80f209"
X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
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: Sun, 01 Oct 2017 19:06:01 -0000
--001a113c4f3cc92a39055a80f209
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Given the proposed fixed signature size, It seems better to me that we
create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH.
Mark, you seem to be arguing that in general we still want weight
malleability even with witness depth fixed, but I don't understand in what
scenario we would want that.
It strikes me that is most scenarios all parties signing an input would do
so after an execution path through the script has been agreed upon by all
parties, in which case the witness weight can be fixed.
In rare cases where the smart contract requires that some parties sign in
advance of the decision about the execution path (for example, I'm thinking
about delegation here, but I want to keep my remarks general), we wouldn't
want to fix the witness depth either.
A SIGHASH_WITNESS_WEIGHT would prevent all possible malleability that would
modify the transaction's fee/weight priority (at least for that one input),
and greatly reduce the overall attack surface of witness malleability
issues.
On Sun, Oct 1, 2017 at 1:04 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Clean stack should be eliminated for other possible future uses, the most
> obvious of which is recursive tail-call for general computation capabilit=
y.
> I=E2=80=99m not arguing for that at this time, just arguing that we shoul=
dn=E2=80=99t
> prematurely cut off an easy implementation of such should we want to. Cle=
an
> stack must still exist as policy for future soft-fork safety, but being a
> consensus requirement was only to avoid witness malleability, which
> committing to the size of the witness also accomplishes.
>
> Committing to the number of witness elements is fully sufficient, and
> using the number of elements avoids problems of not knowing the actual si=
ze
> in bytes at the time of signing, e.g. because the witness contains a merk=
le
> proof generated by another party from an unbalanced tree, and unbalanced
> trees are expected to be common (so that elements can be placed higher in
> the tree in accordance with their higher expected probability of usage).
> Other future extensions might also have variable-length proofs.
>
> > On Sep 30, 2017, at 7:47 PM, Luke Dashjr <luke@dashjr.org> wrote:
> >
> > Should it perhaps commit to the length of the serialised witness data
> instead
> > or additionally? Now that signatures are no longer variable-length,
> that'd be
> > possible...
> >
> > As far as tail-call needs are concerned, CLEANSTACK wouldn't have been
> checked
> > until AFTER the tail-call in the first draft. But I suppose eliminating
> it for
> > other possible future purposes is still useful.
> >
> > Luke
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113c4f3cc92a39055a80f209
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Given the proposed fixed signature size, It seems bet=
ter to me that we create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHAS=
H_WITNESS_DEPTH.<br></div><div><br></div><div>Mark, you seem to be arguing =
that in general we still want weight malleability even with witness depth f=
ixed, but I don't understand in what scenario we would want that.</div>=
<div><br></div><div>It strikes me that is most scenarios all parties signin=
g an input would do so after an execution path through the script has been =
agreed upon by all parties, in which case the witness weight can be fixed.<=
/div><div>In rare cases where the smart contract requires that some parties=
sign in advance of the decision about the execution path (for example, I&#=
39;m thinking about delegation here, but I want to keep my remarks general)=
, we wouldn't want to fix the witness depth either.</div><div><br></div=
><div>A SIGHASH_WITNESS_WEIGHT would prevent all possible malleability that=
would modify the transaction's fee/weight priority (at least for that =
one input), and greatly reduce the overall attack surface of witness mallea=
bility issues.<br></div><div><div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Sun, Oct 1, 2017 at 1:04 AM, Mark Friedenbach via bitco=
in-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Clean st=
ack should be eliminated for other possible future uses, the most obvious o=
f which is recursive tail-call for general computation capability. I=E2=80=
=99m not arguing for that at this time, just arguing that we shouldn=E2=80=
=99t prematurely cut off an easy implementation of such should we want to. =
Clean stack must still exist as policy for future soft-fork safety, but bei=
ng a consensus requirement was only to avoid witness malleability, which co=
mmitting to the size of the witness also accomplishes.<br>
<br>
Committing to the number of witness elements is fully sufficient, and using=
the number of elements avoids problems of not knowing the actual size in b=
ytes at the time of signing, e.g. because the witness contains a merkle pro=
of generated by another party from an unbalanced tree, and unbalanced trees=
are expected to be common (so that elements can be placed higher in the tr=
ee in accordance with their higher expected probability of usage). Other fu=
ture extensions might also have variable-length proofs.<br>
<span class=3D"gmail-im gmail-HOEnZb"><br>
> On Sep 30, 2017, at 7:47 PM, Luke Dashjr <<a href=3D"mailto:luke@da=
shjr.org">luke@dashjr.org</a>> wrote:<br>
><br>
> Should it perhaps commit to the length of the serialised witness data =
instead<br>
> or additionally? Now that signatures are no longer variable-length, th=
at'd be<br>
> possible...<br>
><br>
> As far as tail-call needs are concerned, CLEANSTACK wouldn't have =
been checked<br>
> until AFTER the tail-call in the first draft. But I suppose eliminatin=
g it for<br>
> other possible future purposes is still useful.<br>
><br>
> Luke<br>
<br>
</span><div class=3D"gmail-HOEnZb"><div class=3D"gmail-h5">________________=
______________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div></div></div></div>
--001a113c4f3cc92a39055a80f209--
|
