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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E069BB6D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 22:09:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com
[209.85.161.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 945B942D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 22:09:08 +0000 (UTC)
Received: by mail-yw0-f182.google.com with SMTP id w22so1633604ywa.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 22 Sep 2017 15:09:08 -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=1ZgFkPV+PURn3+NwotisvoqnCGE4N1CkxfblNdQ7VIM=;
b=fjECzd73QPjgCv1+soRlnMGuSWsthfa9NnwoUe73FpTKg7onkJy5jUKTT6HtAUmsMn
2H79Ta+G7G4k2D6M9TJpyXiECAVi3O+lnubDrlnD0Oae8uYydIzc7YpJAfwkL6FVTXcH
wJsmNGYORKvzQnJ//To/J29rOgdBvNZUJIjpl/xJ4cp85MMHT/60UD7tv9EfoLkiMY4G
1kohDnU8mt8egbjJKfJwN634SutQEJqfv/HOWY9f4NcsUNWuSEhVOtfzc5yuCRwY6vbn
7X/dN1eumcXVoell/HMdlTYHp1wYi3l7Vdm25HeFirn+uXO2kDZQRglI7hBqCPfzvsBt
OXHA==
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=1ZgFkPV+PURn3+NwotisvoqnCGE4N1CkxfblNdQ7VIM=;
b=fgno8oNv8FFo4g0LW/hhagyMzEdlZT2vMXdBfMi2SWhUM+3c9TxQzJ0rbHPYGGnQYv
Kjkrrmzz/1Z5Z4No6KvlVHcCkfJuglYsdthB36kSWFEKRGFMO98UzYJIxNmelCD5+B8b
HEYW33jYJ59vwggi9f6GTJ2FEmzEWOLQT/nC7bKS1hrIJ3iKZUKC6h/GpChPhtL86g5g
VS9Og/jrh7CjQTETd5k0HXufdCGhzdxvYk3byFh3LYKTUEAgadD3KReTuX7pCI1N7LBC
cnHB4xvfEY4cvQUU9mvZTH2M8mciB7na6O+5kHK3OKdCxpvN7h5Z26cbxjewINcH2OX2
VglA==
X-Gm-Message-State: AHPjjUjOPfXfx4lLPxWAt8EYhxMCHWcjgjlasKz7Gahxfibh2q2csxK0
1rPFJ5i7GV9TGKET6Wkp+xjTqC/8WMJ7zZpJLpg=
X-Google-Smtp-Source: AOwi7QApBjDnO3YOBIHohUR9lrgTfApygzfcxp/1HC7XMtHTxOZCq0/jeYIPEa+nbhPFXhU71n6+j3AWZouT+dVWB7Q=
X-Received: by 10.129.162.82 with SMTP id z79mr382063ywg.98.1506118147629;
Fri, 22 Sep 2017 15:09:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.80.80 with HTTP; Fri, 22 Sep 2017 15:09:07 -0700 (PDT)
In-Reply-To: <CAKzdR-r6u4J+_T5X516A=-tLWZ8zFFFsRokReiJndDE_S64OqQ@mail.gmail.com>
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>
<CAKzdR-r6u4J+_T5X516A=-tLWZ8zFFFsRokReiJndDE_S64OqQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Fri, 22 Sep 2017 15:09:07 -0700
Message-ID: <CAPg+sBi+WnzpJkcG6XACdpqqz9ZA3rHX8+H9b5eExUdgXaeiWQ@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c1282142deb0f0559ce7525"
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
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 22:09:09 -0000
--94eb2c1282142deb0f0559ce7525
Content-Type: text/plain; charset="UTF-8"
On Fri, Sep 22, 2017 at 2:54 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.
>
Or (my preference);
- Get rid of DER encoding alltogether and switch to fixed size signatures.
Cheers,
--
Pieter
--94eb2c1282142deb0f0559ce7525
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Sep 22, 2017 at 2:54 PM, Sergio Demian Lerner via =
bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>=
></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">If the variable size incre=
ase is only a few bytes, then three possibilities arise:<div><br></div><div=
>- one should allow signatures to be zero padded (to reach the maximum size=
) and abandon strict DER encoding</div><div><br></div><div>- one should all=
ow 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 ele=
ments 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 s=
ize.</div></div></div></blockquote><div><br></div><div>Or (my preference);<=
/div><div><br></div><div>- Get rid of DER encoding alltogether and switch t=
o fixed size signatures.</div><div><br></div><div>Cheers,</div><div><br></d=
iv><div>-- <br></div><div>Pieter</div><div><br></div></div></div></div>
--94eb2c1282142deb0f0559ce7525--
|
