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: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 995A2BDF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Sep 2017 17:38:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C6F81421
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Sep 2017 17:38:10 +0000 (UTC)
Received: from [10.8.0.102] (119246244201.ctinets.com [119.246.244.201]) by
mx.zohomail.com with SMTPS id 150601548627574.65223904552363;
Thu, 21 Sep 2017 10:38:06 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <201709211633.17714.luke@dashjr.org>
Date: Fri, 22 Sep 2017 01:38:01 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <7BF7D0B8-A38C-44B9-B6E9-44A74782CC81@xbt.hk>
References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org>
<201709210411.50642.luke@dashjr.org>
<21D6060D-97F0-439A-86D3-065C21BACC3F@xbt.hk>
<201709211633.17714.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>
X-Mailer: Apple Mail (2.3273)
X-ZohoMailClient: External
X-Spam-Status: No, score=0.0 required=5.0 tests=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
Cc: bitcoin-dev <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: Thu, 21 Sep 2017 17:38:11 -0000
> On 22 Sep 2017, at 12:33 AM, Luke Dashjr <luke@dashjr.org> wrote:
>=20
> On Thursday 21 September 2017 8:02:42 AM Johnson Lau wrote:
>> I think it=E2=80=99s possible only if you spend more witness space to =
store the
>> (pubkey, message) pairs, so that old clients could understand the
>> aggregation produced by new clients. But this completely defeats the
>> purpose of doing aggregation.
>=20
> SigAgg is a softfork, so old clients *won't* understand it... am I =
missing=20
> something?
>=20
> For example, perhaps the lookup opcode could have a data payload =
itself (eg,=20
> like pushdata opcodes do), and the script can be parsed independently =
from=20
> execution to collect the applicable ones.
I think the current idea of sigagg is something like this: the new =
OP_CHECKSIG still has 2 arguments: top stack must be a 33-byte public =
key, and the 2nd top stack item is signature. Depends on the sig size, =
it returns different value:
If sig size is 0, it returns a 0 to the top stack
If sig size is 1, it is treated as a SIGHASH flag, and the =
SignatureHash() =E2=80=9Cmessage=E2=80=9D is calculated. It sends the =
(pubkey, message) pair to the aggregator, and always returns a 1 to the =
top stack
If sig size is >1, it is treated as the aggregated signature. The last =
byte is SIGHASH flag. It sends the (pubkey, message) pair and the =
aggregated signature to the aggregator, and always returns a 1 to the =
top stack.
If all scripts pass, the aggregator will combine all pairs to obtain the =
aggkey and aggmsg, and verify against aggsig. A tx may have at most 1 =
aggsig.
(The version I presented above is somewhat simplified but should be =
enough to illustrate my point)
So if we have this script:
OP_1 OP_RETURNTRUE <pubkey> OP_CHECKSIG
Old clients would stop at the OP_RETURNTRUE, and will not send the =
pubkey to the aggregator
If we softfork OP_RETURNTRUE to something else, even as OP_NOP11, new =
clients will send the (key, msg) pair to the aggregator. Therefore, the =
aggregator of old and new clients will see different data, leading to a =
hardfork.
OTOH, OP_NOP based softfork would not have this problem because it =
won=E2=80=99t terminate script and return true.
>=20
>>> This is another approach, and one that seems like a good idea in =
general.
>>> I'm not sure it actually needs to take more witness space - in =
theory,
>>> such stack items could be implied if the Script engine is designed =
for
>>> it upfront. Then it would behave as if it were non-verify, while
>>> retaining backward compatibility.
>>=20
>> Sounds interesting but I don=E2=80=99t get it. For example, how could =
you make a
>> OP_MUL out of OP_NOP?
>=20
> The same as your OP_MULVERIFY at the consensus level, except new =
clients would=20
> execute it as an OP_MUL, and inject pops/pushes when sending such a=20
> transaction to older clients. The hash committed to for the script =
would=20
> include the inferred values, but not the actual on-chain data. This =
would=20
> probably need to be part of some kind of MAST-like softfork to be =
viable, and=20
> maybe not even then.
>=20
> Luke
I don=E2=80=99t think it=E2=80=99s worth the code complexity, just to =
save a few bytes of data sent over wire; and to be a soft fork, it still =
takes the block space.
Maybe we could create many OP_DROPs and OP_2DROPs, so new VERIFY =
operations could pop the stack. This saves 1 byte and also looks =
cleaner.
Another approach is to use a new script version for every new non-verify =
type operation. Problem is we will end up with many versions. Also, =
signatures from different versions can=E2=80=99t be aggregated. (We may =
have multiple aggregators in a transaction)
|
