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
|
Return-Path: <bram@chia.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1A6FC12C9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Mar 2018 00:47:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 34588624
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Mar 2018 00:47:04 +0000 (UTC)
Received: by mail-wm0-f51.google.com with SMTP id t7so12898186wmh.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Mar 2018 17:47:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=chia-net.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to;
bh=TDqPZNbgdpbH0xBHxIrY6o2IcvBJ8fzozAsQUR0/ECY=;
b=EtXNGJ1O9FY6w0mY+w69t0jNLu15sj+uSkRUAOYVj0EOP66MJcyZO2V1Zhiske5gKG
PBoJF8mGWbCSSGhyKsP3TFu36BVnTivHXso9PXKrdt+wuvzWCq/P8r+4+ou4qBGON8QC
tW3TMdjvVJetlHJxw0BEMP9sN7KOljosgGz+qvzhbTmEZu/JaDMHjH8bdT3koQQhd5LA
j0xedQ7pKg5Thw1DJTeSFGV418uTDuCuO6FVWs5fe7bnbt52EHS0C4803Lae9CwmGSqh
KAJUQZFGQh/4bULHuzqNqNtcTXMeCC0AjqgaYbz27jR9DoVhzeXwh7Pi4jmeCCnYVu1p
giFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=TDqPZNbgdpbH0xBHxIrY6o2IcvBJ8fzozAsQUR0/ECY=;
b=dOq3XqNVtEsIU8fx6XJLLpIQIVbdCfYWURpnLCccwnuBoRrRVc8whibUiyRP38kDV4
f0nDKPapzFWHYOH1Y7pk8YRToTv1is6wPQmt4GApIl/92NC23SNA7eggOSwKnoEG0Ex0
9hkty+vxmVI04NoRur56deWp6oHxP+H635gDZFxvsVwiugHlskqGibWNgvn+oJUQpLKI
snPZnnkBA5ouBYbcB9tlWfFQZ+ZQgGBPTdbDxVAl/w3NtfheIKdt1OXF/zCawjwsUT+y
P4rUEtefKh1MXkYrztawj+uyeZ5C6+lhJU7V36fuSkTLqXaucJcFV0cv2EENeEcZpy8Z
lRNg==
X-Gm-Message-State: AElRT7FQJJicw2+wWiag2f/aScA/Aff5yC9UFY44MeLOF/vL/dvgg8FE
jjGZAJyidIfgHVWrisxkz6XiLDPzBuPdSF0e6nCDz1K9
X-Google-Smtp-Source: AG47ELsI0JBeqozLofCrkcizRAiYSdKf8CrEgzq+k+LKO9al+38EhhOuOeYdMxkbyLUaZfdX6Vniz9xOVnvIkCuDllM=
X-Received: by 10.28.125.84 with SMTP id y81mr4083914wmc.66.1521679622355;
Wed, 21 Mar 2018 17:47:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.29.78 with HTTP; Wed, 21 Mar 2018 17:47:01 -0700 (PDT)
X-Originating-IP: [65.204.128.202]
From: Bram Cohen <bram@chia.net>
Date: Wed, 21 Mar 2018 17:47:01 -0700
Message-ID: <CAHUJnBAQwLfmvLyApcw8dKz1u8xX1KmdjiUmzSHXyw7npWUXHQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="001a1141d7005a4f520567f5a554"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 22 Mar 2018 01:45:31 +0000
Subject: Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation
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: Thu, 22 Mar 2018 00:47:05 -0000
--001a1141d7005a4f520567f5a554
Content-Type: text/plain; charset="UTF-8"
Regarding the proposed segwit v2 with reclaiming most things as
RETURN_VALID, the net result for what's being proposed in the near future
for supporting aggregated signatures in the not-so-near future is to punt.
A number of strategies are possible for how to deal with new opcodes being
added later on, and the general strategy of making unused opcodes be
RETURN_VALID for now and figuring out how to handle it later works for all
of them. I think this is the right approach, but wanted to clarify that it
is in fact the approach being proposed.
That said, there are some subtleties to getting it right which the last
message doesn't really cover. Most unused opcodes should be reclaimed as
RETURN_VALID, but there should still be one OP_NOP and there should be a
'real' RETURN_VALID, which (a) is guaranteed to not be soft forked into
something else in the future, and (b) doesn't have any parsing weirdness.
The parsing weirdness of all the unclaimed opcodes is interesting. Because
everything in an IF clause needs to be parsed in order to find where the
ELSE is, you have a few options for dealing with an unknown opcode getting
parsed in an unexecuted section of code. They are (a) avoid the problem
completely by exterminating IF and MASTing (b) avoid the problem completely
by getting rid of IF and adding IFJUMP, IFNJUMP, and JUMP which specify a
number of bytes (this also allows for script merkleization) (c) require all
new opcodes have fixed length 1, even after they're soft forked, (d) do
almost like (c) but require that on new soft forks people hack their old
scripts to still parse properly by avoiding the OP_ELSE in inopportune
places (yuck!) (e) make it so that the unknown opcodes case a RETURN_VALID
even when they're parsed, regardless of whether they're being executed.
By far the most expedient option is (e) cause a RETURN_VALID at parse time.
There's even precedent for this sort of behavior in the other direction
with disabled opcodes causing failure at parse time even if they aren't
being executed.
A lot can be said about all the options, but one thing I feel like snarking
about is that if you get rid of IFs using MAST, then it's highly unclear
whether OP_DEPTH should be nuked as well. My feeling is that it should and
that strict parsing should require that the bottom thing in the witness
gets referenced at some point.
Hacking in a multisig opcode isn't a horrible idea, but it is very stuck
specifically on m-of-n and doesn't support more complex formulas for how
signatures can be combined, which makes it feel hacky and weird.
Also it may make sense to seriously consider BLS signatures, which have a
lot of practical benefits starting with them being noninteractively
aggregatable so you can always assume that they're aggregated instead of
requiring complex semantics to specify what's aggregated with what. My team
is working on an implementation which has several advantages over what's
currently in the published literature but it isn't quite ready for public
consumption yet. This should probably go on the pile of reasons why it's
premature to finalize a plan for aggregation at this point.
--001a1141d7005a4f520567f5a554
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Regarding the proposed segwit v2 with reclaiming most thin=
gs as RETURN_VALID, the net result for what's being proposed in the nea=
r future for supporting aggregated signatures in the not-so-near future is =
to punt. A number of strategies are possible for how to deal with new opcod=
es being added later on, and the general strategy of making unused opcodes =
be RETURN_VALID for now and figuring out how to handle it later works for a=
ll of them. I think this is the right approach, but wanted to clarify that =
it is in fact the approach being proposed.<div><br></div><div>That said, th=
ere are some subtleties to getting it right which the last message doesn=
9;t really cover. Most unused opcodes should be reclaimed as RETURN_VALID, =
but there should still be one OP_NOP and there should be a 'real' R=
ETURN_VALID, which (a) is guaranteed to not be soft forked into something e=
lse in the future, and (b) doesn't have any parsing weirdness. The pars=
ing weirdness of all the unclaimed opcodes is interesting. Because everythi=
ng in an IF clause needs to be parsed in order to find where the ELSE is, y=
ou have a few options for dealing with an unknown opcode getting parsed in =
an unexecuted section of code. They are (a) avoid the problem completely by=
exterminating IF and MASTing (b) avoid the problem completely by getting r=
id of IF and adding IFJUMP, IFNJUMP, and JUMP which specify a number of byt=
es (this also allows for script merkleization) (c) require all new opcodes =
have fixed length 1, even after they're soft forked, (d) do almost like=
(c) but require that on new soft forks people hack their old scripts to st=
ill parse properly by avoiding the OP_ELSE in inopportune places (yuck!) (e=
) make it so that the unknown opcodes case a RETURN_VALID even when they=
9;re parsed, regardless of whether they're being executed.</div><div><b=
r></div><div>By far the most expedient option is (e) cause a RETURN_VALID a=
t parse time. There's even precedent for this sort of behavior in the o=
ther direction with disabled opcodes causing failure at parse time even if =
they aren't being executed.</div><div><br></div><div>A lot can be said =
about all the options, but one thing I feel like snarking about is that if =
you get rid of IFs using MAST, then it's highly unclear whether OP_DEPT=
H should be nuked as well. My feeling is that it should and that strict par=
sing should require that the bottom thing in the witness gets referenced at=
some point.</div><div><br></div><div>Hacking in a multisig opcode isn'=
t a horrible idea, but it is very stuck specifically on m-of-n and doesn=
9;t support more complex formulas for how signatures can be combined, which=
makes it feel hacky and weird.</div><div><br></div><div>Also it may make s=
ense to seriously consider BLS signatures, which have a lot of practical be=
nefits starting with them being noninteractively aggregatable so you can al=
ways assume that they're aggregated instead of requiring complex semant=
ics to specify what's aggregated with what. My team is working on an im=
plementation which has several advantages over what's currently in the =
published literature but it isn't quite ready for public consumption ye=
t. This should probably go on the pile of reasons why it's premature to=
finalize a plan for aggregation at this point.</div><div><br></div></div>
--001a1141d7005a4f520567f5a554--
|
