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
|
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 31957B66
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 21:32:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com
[209.85.218.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9E4E8421
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 21:32:41 +0000 (UTC)
Received: by mail-oi0-f53.google.com with SMTP id 199so299189oii.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 14:32:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=TMQ9vKaSWj34ynuVTLZvqZLoU5R1MtMhXFEhGzgIbNE=;
b=UxUbsYYDVaQUYBKlGbEktm3YVvTG7CfYfznkbG2IO4loCvvOq6jDavWXs3F/Ylk5HP
nZ8ZfJrLaRN8AAVqPDqnaJxg80Pe05OVqprxjblv+0e1oZqVJBRa9TmxQDlkAvgRWvZO
qTV75bytQ2u66ayFMWgulkXYhXJ47+n87RsfRXqf/mi1NyqeiG+1rOA9xCurzC6Cf9dx
VaYYOOgwlf1n2gZ8PKyvYtJ09uEhU/rawc89By/AoK1F/NJ6zfyeuWL7zDjAq2bWa+b8
4obZJ5AL6JT7ZRRhEwVlkshkQLYAwGLtcCVMVwaT/gDd3rxVH26Pmhnjd+1DyDiuU7a/
B1mA==
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=TMQ9vKaSWj34ynuVTLZvqZLoU5R1MtMhXFEhGzgIbNE=;
b=mcold9ysGGUIhIjc2LHSTCTY1+ftYb0XQ+t4A7acPsn0gBdsPLQfxDCFdvNt8HN3WT
ulSHywTSSsZys3CSHUdSfFXD/H8QNnVugI8wgnfONqYKa2vm/mp0ajU6PR12Xwm1clRV
VbWCItfPmpvLuHV7tNvXszgv5eFZxHXbDylA02hypiyu3KWKd7bxKf1D0pCJ+XVn4ks7
YE1BI5vUe+U9qJu8D3+1Kqmxgeid7aEcU/4kLeJflN5hfSM8c+07hrm6YeY+Ls0KDO5b
n13KY1vIPCx1MCWUwaJ2lNwkyxCMKStuUW/5GPZA3nb05cchbsMW7ad6uHaIVwkilISe
aEOA==
X-Gm-Message-State: AHPjjUgg1R+qKWnbQTZv8ewyN4tu9IOgW2KO76o8E7i0XQ6GFh4zphNf
S270rMDY20GQ6aETi9HnMSsJKio6VzNj2phJz1U=
X-Google-Smtp-Source: AOwi7QC+JsdxuK3FgxsU0k5J7bM55vTGkIE3fGqOv1oW8InzQdsQB1EvjorEyGaeOQTPS0TSv8NlNRQ9j5kiREWa5JU=
X-Received: by 10.202.178.133 with SMTP id b127mr622500oif.319.1506115961005;
Fri, 22 Sep 2017 14:32:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.85.72 with HTTP; Fri, 22 Sep 2017 14:32:00 -0700 (PDT)
In-Reply-To: <3385CE20-C1BA-40DD-8FC3-8F53F3350717@friedenbach.org>
References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org>
<C623794E-F061-4C7A-B05D-378798ED2BF7@friedenbach.org>
<201709190309.08669.luke@dashjr.org>
<CAA2B000-6C54-4AD7-B931-43C99D615A61@friedenbach.org>
<CAKzdR-phAarTY16BOnC95BPN0qMNEE_XZ9H-XmFeeaBc2V1U5w@mail.gmail.com>
<3385CE20-C1BA-40DD-8FC3-8F53F3350717@friedenbach.org>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Fri, 22 Sep 2017 18:32:00 -0300
Message-ID: <CAKzdR-pnvystx5H+P+OCXm73aVmWdyesCymerSgx=pCuXx+YGA@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary="001a113b5e32d8b4f50559cdf24c"
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FROM,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
X-Mailman-Approved-At: Fri, 22 Sep 2017 21:37:15 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] cleanstack alt stack & softfork improvements
(Was: Merkle branch verification & tail-call semantics for generalized
MAST)
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: Fri, 22 Sep 2017 21:32:42 -0000
--001a113b5e32d8b4f50559cdf24c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
But generally before one signs a transaction one does not know the
signature size (which may be variable). One can only estimate the maximum
size.
On Fri, Sep 22, 2017 at 6:11 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:
>
> On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner <
> sergio.d.lerner@gmail.com> wrote:
>
>
>>
>> There are other solutions to this problem that could have been taken
>> instead, such as committing to the number of items or maximum size of
>> the stack as part of the sighash data, but cleanstack was the approach
>> taken.
>
>
> The lack of signed maximum segwit stack size was one of the objections to
> segwit I presented last year. This together with the unlimited segwit sta=
ck
> size.
>
> However, committing to the maximum stack size (in bytes) for an input is
> tricky. The only place where this could be packed is in sequence_no, with=
a
> soft-fork. E.g. when transaction version is 2 and and only when lock_time
> is zero.
>
> For transactions with locktime >0, we could soft-fork so transactions add
> a last zero-satoshi output whose scriptPub contains OP_RETURN and followe=
d
> by N VarInts, containing the maximum stack size of each input.
> Normally, for a 400 byte, 2-input transaction, this will add 11 bytes, or
> a 2.5% overhead.
>
>
> There=E2=80=99s no need to put it in the transaction itself. You put it i=
n the
> witness and it is either committed to as part of the witness (in which ca=
se
> it has to hold for all possible spend paths), or at spend time by includi=
ng
> it in the data signed by CHECKSIG.
>
>
--001a113b5e32d8b4f50559cdf24c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">But generally before one signs a transaction one does not =
know the signature size (which may be variable). One can only estimate the =
maximum size.=C2=A0</div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Fri, Sep 22, 2017 at 6:11 PM, Mark Friedenbach <span dir=3D"ltr"=
><<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@frieden=
bach.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div sty=
le=3D"word-wrap:break-word"><span class=3D""><br><div><blockquote type=3D"c=
ite"><div>On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner <<a href=3D"=
mailto:sergio.d.lerner@gmail.com" target=3D"_blank">sergio.d.lerner@gmail.c=
om</a>> wrote:</div><br class=3D"m_-7489060530183796950Apple-interchange=
-newline"><div><blockquote class=3D"gmail_quote" style=3D"font-family:Helve=
tica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:=
normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex"><br class=3D"m_-7489060530183796950Apple-interchange-newli=
ne"><br>There are other solutions to this problem that could have been take=
n<br>instead, such as committing to the number of items or maximum size of<=
br>the stack as part of the sighash data, but cleanstack was the approach<b=
r>taken.<span class=3D"m_-7489060530183796950Apple-converted-space">=C2=A0<=
/span></blockquote><div style=3D"font-family:Helvetica;font-size:12px;font-=
style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:nor=
mal;text-align:start;text-indent:0px;text-transform:none;white-space:normal=
;word-spacing:0px"><br></div><div style=3D"font-family:Helvetica;font-size:=
12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-s=
pacing:normal;text-align:start;text-indent:0px;text-transform:none;white-sp=
ace:normal;word-spacing:0px">The lack of signed=C2=A0maximum segwit stack s=
ize was one of the objections to segwit I presented last year. This togethe=
r with the unlimited segwit stack size.</div><div style=3D"font-family:Helv=
etica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight=
:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transfo=
rm:none;white-space:normal;word-spacing:0px"><br></div><div style=3D"font-f=
amily:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;f=
ont-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;te=
xt-transform:none;white-space:normal;word-spacing:0px">However, committing =
to the maximum stack size (in bytes) for an input is tricky. The only place=
where this could be packed is in=C2=A0sequence_no, with a soft-fork. E.g. =
when transaction version is 2 and and only when lock_time is zero.</div><di=
v style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-vari=
ant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;t=
ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><sp=
an style=3D"background-color:rgb(249,249,249);font-family:sans-serif;font-s=
ize:14px"><br></span></div><span style=3D"font-family:Helvetica;font-size:1=
2px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-sp=
acing:normal;text-align:start;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px;float:none;display:inline!important">For transac=
tions with locktime >0, we could soft-fork so transactions add a last ze=
ro-satoshi output whose scriptPub contains OP_RETURN and followed by N VarI=
nts, containing the maximum stack size of each input.<span class=3D"m_-7489=
060530183796950Apple-converted-space">=C2=A0</span></span><br style=3D"font=
-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal=
;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;=
text-transform:none;white-space:normal;word-spacing:0px"><span style=3D"fon=
t-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:norma=
l;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px;float:none;display=
:inline!important">Normally, for a 400 byte, 2-input transaction, this will=
add 11 bytes, or a 2.5% overhead.</span></div></blockquote><br></div></spa=
n><div>There=E2=80=99s no need to put it in the transaction itself. You put=
it in the witness and it is either committed to as part of the witness (in=
which case it has to hold for all possible spend paths), or at spend time =
by including it in the data signed by CHECKSIG.</div><br></div></blockquote=
></div><br></div>
--001a113b5e32d8b4f50559cdf24c--
|
