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
|
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 928B487A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 21:55:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com
[209.85.218.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C334E41D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 21:55:20 +0000 (UTC)
Received: by mail-oi0-f47.google.com with SMTP id 199so360102oii.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 14:55:20 -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=6SnXPYPB/b503Fj4NQNjYMKMnyZ58fvrPZ8Tot8Y6jI=;
b=E1nljPdwIN0CTRjbSnhWcjYdEpV4qfsQ0lDm9AzplgdXai9VeAMheRQjJHAROy9Mgk
i13jokoKAbxPoaSe1wUfPwh44qTDjtV6GN2rJDmCo1NKY5olJ/Mz2wY9krNrNVKggdR/
i5ouN8Jdj9w65EnVSEUv+UNTaKSQOjG9tLBcXWNxe8raPSBfdOdj5MDpNe7rAwXcy923
fp+R01yS+xIZ/GMVOye+Nu96QG5Ec77x0xKfK6mTQ3ElG9e6e4/xbT9hR9oXQI+RO6Z7
Ga0NTKsIMThdwtQiBc2eIaIkbIncEI7PFHB0VvUGieUqshzcmtnYq2P4EfwHgL5SLx7m
oSQg==
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=6SnXPYPB/b503Fj4NQNjYMKMnyZ58fvrPZ8Tot8Y6jI=;
b=Nrwt5XT7BurrOuNnxeaEQc+FsYQg2aiJq0kvC+zb+SEDG9JrtDvQA4/sGA/6vMUkoO
AQ3iomgMUyrWL5eNmRQqXgf/zaNwDn8AtjNjCjzz68OZQ29s2l1jhp+OpKtY346mouEe
3ZyqW574ztey21dhu9S+01WKi8haVR3VhtgF3KHpZv/9tt8irREoB0rJgE5OsAUCabtA
W861nKbk8+ZDBNM8f5BnASoQYVTaIElqF3EEbFK0fSk7N4D9f4qFM2x5lNX4bUzDmwaS
LpnWIEhb0Akr+F6/8f1+CVoZ61IyCvt9XDlEJNX2HOTJU+EnBIT2vqf4oiotsUH51g97
ckZQ==
X-Gm-Message-State: AHPjjUi/X6hJg2WkakXbMZn+9z4BBNQZhlcFwyc0ZkKfPhSK50HRAg8s
x725Id+9X1jGGWG7wBUjasSNGp8Ex3elRVZb3RQ=
X-Google-Smtp-Source: AOwi7QD33naa3V6vJuwqI2kPHiSRD79cDUd9k5iOlCcsD5lTp8ifh7Bu1X6Y6W0Oo6Jsn27QzyHJHRnL8jpxFQY0inA=
X-Received: by 10.202.232.140 with SMTP id f134mr692983oih.204.1506117320025;
Fri, 22 Sep 2017 14:55:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.85.72 with HTTP; Fri, 22 Sep 2017 14:54:39 -0700 (PDT)
In-Reply-To: <9FD4AF03-28A5-4B8A-9C12-CBCB1BC2E22C@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>
<CAKzdR-pnvystx5H+P+OCXm73aVmWdyesCymerSgx=pCuXx+YGA@mail.gmail.com>
<9FD4AF03-28A5-4B8A-9C12-CBCB1BC2E22C@friedenbach.org>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Fri, 22 Sep 2017 18:54:39 -0300
Message-ID: <CAKzdR-r6u4J+_T5X516A=-tLWZ8zFFFsRokReiJndDE_S64OqQ@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary="001a114085f4d9f50e0559ce43d3"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM 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 22:07:02 +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:55:21 -0000
--001a114085f4d9f50e0559ce43d3
Content-Type: text/plain; charset="UTF-8"
If the variable size increase is only a few bytes, then three possibilities
arise:
- one should allow signatures to be zero padded (to reach the maximum size)
and abandon strict DER encoding
- one should allow spare witness stack elements (to pad the size to match
the maximum size) and remove the cleanstack rule. But this is tricky
because empty stack elements must be counted as 1 byte.
- signers must loop the generation of signatures until the signature
generated is of its maximum size.
On Fri, Sep 22, 2017 at 6:39 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:
> You generally know the witness size to within a few bytes right before
> signing. Why would you not? You know the size of ECDSA signatures. You can
> be told the size of a hash preimage by the other party. It takes some
> contriving to come up with a scheme where one party has variable-length
> signatures of their chosing
>
> > On Sep 22, 2017, at 2:32 PM, Sergio Demian Lerner <
> sergio.d.lerner@gmail.com> wrote:
> >
> > 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.
>
>
--001a114085f4d9f50e0559ce43d3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If the variable size increase is only a few bytes, then th=
ree possibilities arise:<div><br></div><div>- one should allow signatures t=
o be zero padded (to reach the maximum size) and abandon strict DER encodin=
g</div><div><br></div><div>- one should allow spare witness stack elements =
(to pad the size to match the maximum size) and remove the cleanstack rule.=
But this is tricky because empty stack elements must be counted as 1 byte.=
<div><br></div><div>- signers must loop the generation of signatures until =
the signature generated is of its maximum size.</div><div><br><div><br></di=
v><div><br></div></div></div></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Fri, Sep 22, 2017 at 6:39 PM, Mark Friedenbach <span d=
ir=3D"ltr"><<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">ma=
rk@friedenbach.org</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
You generally know the witness size to within a few bytes right before sign=
ing. Why would you not? You know the size of ECDSA signatures. You can be t=
old the size of a hash preimage by the other party. It takes some contrivin=
g to come up with a scheme where one party has variable-length signatures o=
f their chosing<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
> On Sep 22, 2017, at 2:32 PM, Sergio Demian Lerner <<a href=3D"mailt=
o:sergio.d.lerner@gmail.com">sergio.d.lerner@gmail.com</a>> wrote:<br>
><br>
> But generally before one signs a transaction one does not know the sig=
nature size (which may be variable). One can only estimate the maximum size=
.<br>
<br>
</div></div></blockquote></div><br></div>
--001a114085f4d9f50e0559ce43d3--
|
