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
|
Return-Path: <mail@felixweis.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 33D0996F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 11:22:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com
[209.85.215.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C376CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Oct 2017 11:22:42 +0000 (UTC)
Received: by mail-lf0-f49.google.com with SMTP id 23so3324975lfs.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 01 Oct 2017 04:22:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=felixweis.com; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=K1+QkwqR8yc3xgewVM7sYsZ7zdkY5kS/7nLiPyuimrw=;
b=jR1hBorbK6lBhF/uKDD2f29eYKTGJgfMw2383Q7Xul86179JIYNOggvrMTrY8UgYnX
5up4bmM9tTbylPaWfc2DLmKeNme1RI8LIzfcq7BNzHa934LimhBZqsO4AFvAFNfwP/Ob
GgaAZsXW8NNnvx3hRtvyZU8Y5y2ZzjwTwwOKoCpW1x38MvVJcyBETDPDvrqVt52ONkQD
yavOATBYfVna+nHXfm5Ej/5h9nQarvd6biBvSWGdt16d6U3G3qyen3ETXnOvmZJw5inV
3oQ8/qyGNqvIxMIKNZ770Q2i3r1AKzntKSSSmfwxDItiDbrSrgOQTKK3gl8leh1Ua3HT
jNtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=K1+QkwqR8yc3xgewVM7sYsZ7zdkY5kS/7nLiPyuimrw=;
b=KmND+5yXZ4vbCvJi5HcXFWBDUyOk64Hr8yfiwfLM/r3HQ0PgGY02wkOD+ufvK2GHJA
PSRTDoU7Pe5ZfY3VucpRyiLPimE8nigBGdbM4devYOJG0cMS9ZDK8Zqew2ub6Tki18ZD
lX6Zh4gKFny1D9wlegRytofMYF9PIs6borZARd2Q50auy7z92qf3gzxtzr3CVNTqSu2r
kYYobyf7MnGj6GdOQtXWm1TPg1Cdjxar3Fis0hIDYA4oQZ7sZB5IRH59u+bLuyqD1t7G
WSDV1HILf2dew/EUB0DRlMgUT9sPH9p7PwbDhnh7o9eZGDlXkyUzTHbKc/kXcKAM5CEf
cyQw==
X-Gm-Message-State: AMCzsaVErxleYzCGMBDqsml0g+OEa0pv9VNAQvZ6vnAfK0cUTefzhUkN
dk3hDlEknpsuo2UyEBdnlxho5eXFCBg42OjXavWNGA==
X-Google-Smtp-Source: AOwi7QAPId0YG/AAjEaVkRiCf9g5Y9+DP0FQ6Jj4HJqLXkuQgO9NbQgAVHeLrg3xmistXmX8XzqUGmyKvzdU+eWjet4=
X-Received: by 10.25.115.89 with SMTP id o86mr2865167lfc.164.1506856961058;
Sun, 01 Oct 2017 04:22:41 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org>
From: Felix Weis <mail@felixweis.com>
Date: Sun, 01 Oct 2017 11:22:30 +0000
Message-ID: <CAMnWzuULmHsiC8CSHZRHS7nJAgHBVMCUfSR-0Si31YSQFeGfbQ@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary="001a113c3cdae44ad1055a7a791b"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,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] 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 11:22:44 -0000
--001a113c3cdae44ad1055a7a791b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Just a simple suggestion since the signature format is changed. Can this be
designed so that possible future hard forks can simply change 1 constant in
the code and turn on cross chain replay protection?
On Sun, Oct 1, 2017 at 1:05 PM 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
>
--001a113c3cdae44ad1055a7a791b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Just a simple suggestion since the signature format is cha=
nged. Can this be designed so that possible future hard forks can simply ch=
ange 1 constant in the code and turn on=C2=A0cross chain=C2=A0replay protec=
tion?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, Oct 1, 2=
017 at 1:05 PM Mark Friedenbach via bitcoin-dev <<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>=
> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Clean stack should be e=
liminated for other possible future uses, the most obvious of which is recu=
rsive 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 being a consensus re=
quirement was only to avoid witness malleability, which committing to the s=
ize 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>
<br>
> On Sep 30, 2017, at 7:47 PM, Luke Dashjr <<a href=3D"mailto:luke@da=
shjr.org" target=3D"_blank">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>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--001a113c3cdae44ad1055a7a791b--
|
