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
|
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 70587941
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 20:33:38 +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 18AD14BE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 20:33:38 +0000 (UTC)
Received: by mail-oi0-f53.google.com with SMTP id b1so123335oih.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 13:33:37 -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=uJ/5aQsKrb6MZaRtD1IlKZ5bi/EC8NUnryIdJUfJw3Q=;
b=ZOBOz7Kn3SYRlKHHto9mhSY6rgQ3lLFUNp5uygVNrHtYBedQgLgsFzU/fjtVfCKo6s
6fOqqjpEUjGcg3UI9LixvBBTnSZEfVjo7tf0g3jNf06K7fReuNrX2HuObxiZ3UaJEdjg
dYgSBUrlzZMCo+/OJEv2BlkMCkUnwTL7XIj64AB6nj/F5g93Y1+UT06afNszslHyYayf
dokT52gLup+H1Vl0vmhzQYDhHocszjPXSU3+lKKMPRxox9vCIMyuSuAyyYZfw6xkO385
1/oW3dsO4Fy6G6AQRDV8s1Kmk45ptAF/W73LuUy/xbro5GZU7C9gYGrK3DUWNEpP6eo+
WsuA==
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=uJ/5aQsKrb6MZaRtD1IlKZ5bi/EC8NUnryIdJUfJw3Q=;
b=dZokeTroc/5UFvHQjuErT93aC0NGdCGyrTlETfTdSsFqWfMz1ssfqBVVBKBYB64Y72
CQICyhGLcZCQM9ogfRr2V4VT15zuL1//5qihJf84zBoZLHI6EoXDbFQ2cYgNoose81Hu
SqY0CSr7mupC4yXbGsqCaQmAPdCK2Sa3LH39Kyoid3xElnI7oyfcCRclgaNvcc8+lWcL
/LMyP59PphiCbfI9C5maiHrkSKlOcGVX5SoBsFuDucvLQ1Y27jHDboQX0mnmqm3XkERM
qLw0/jbeHU+LTqfxkCw7CSnxwLZvrrLde5Rnp/CJYl61fRAk8n1+za3azugoUKTpAV6o
ueyA==
X-Gm-Message-State: AHPjjUgX7ktVcb0quVJVxuJSAbLw5uDwuk/h0iZOadgJpC9litL6m3RR
TWQ0t4hSqCQGWmOTeppeShmjFGBX0umZKwGGJgo=
X-Google-Smtp-Source: AOwi7QAR5CEdZDqDwPHgZE8pUkmg7FB1yVYuHiidNC81ctt+Ssmjs9Ja1BMIQgm7lToEnH1N5pLFjI6vjK1kfhnMWYY=
X-Received: by 10.202.178.133 with SMTP id b127mr441100oif.319.1506112417370;
Fri, 22 Sep 2017 13:33:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.85.72 with HTTP; Fri, 22 Sep 2017 13:32:56 -0700 (PDT)
In-Reply-To: <CAA2B000-6C54-4AD7-B931-43C99D615A61@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>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Fri, 22 Sep 2017 17:32:56 -0300
Message-ID: <CAKzdR-phAarTY16BOnC95BPN0qMNEE_XZ9H-XmFeeaBc2V1U5w@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113b5e32a1198f0559cd1f8e"
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 20:41:03 +0000
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 20:33:38 -0000
--001a113b5e32a1198f0559cd1f8e
Content-Type: text/plain; charset="UTF-8"
>
> 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 stack
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 followed 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.
> Arguably for a future script version upgrade one of these other
> approaches should be taken to allow for shorter tail-call scripts.
>
> Mark
>
> * Well, almost any. You could end the script with DEPTH EQUAL and that
> is a compact way of ensuring the stack is clean (assuming the script
> finished with just "true" on the stack). Nobody does this however
> and burning two witness bytes of every redeem script going forward
> as a protective measure seems like an unnecessary ask.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113b5e32a1198f0559cd1f8e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br>
There are other solutions to this problem that could have been taken<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<br>
taken. </blockquote><div><br></div><div>The lack of signed=C2=A0maximum seg=
wit stack size was one of the objections to segwit I presented last year. T=
his together with the unlimited segwit stack size.</div><div><br></div><div=
>However, committing to the maximum stack size (in bytes) for an input is t=
ricky. The only place where this could be packed is in=C2=A0sequence_no, wi=
th a soft-fork. E.g. when transaction version is 2 and and only when lock_t=
ime is zero.</div><div><span style=3D"background-color:rgb(249,249,249);col=
or:rgb(0,0,0);font-family:sans-serif;font-size:14px"><br></span></div>For t=
ransactions with locktime >0, we could soft-fork so transactions add a l=
ast zero-satoshi output whose scriptPub contains OP_RETURN and followed by =
N VarInts, containing the maximum stack size of each input. <br>Normally, f=
or a 400 byte, 2-input transaction, this will add 11 bytes, or a 2.5% overh=
ead.<div><br></div><div><br></div><div><span style=3D"background-color:rgb(=
249,249,249);color:rgb(0,0,0);font-family:sans-serif;font-size:14px"><br></=
span></div><div><br></div><div><br></div><div><br></div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">Arguably for a future scrip=
t version upgrade one of these other<br>
approaches should be taken to allow for shorter tail-call scripts.<br>
<br>
Mark<br>
<br>
* Well, almost any. You could end the script with DEPTH EQUAL and that<br>
=C2=A0 is a compact way of ensuring the stack is clean (assuming the script=
<br>
=C2=A0 finished with just "true" on the stack). Nobody does this =
however<br>
=C2=A0 and burning two witness bytes of every redeem script going forward<b=
r>
=C2=A0 as a protective measure seems like an unnecessary ask.<br>
<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>
--001a113b5e32a1198f0559cd1f8e--
|
