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
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 78FC4AC7
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 21:01:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f46.google.com (mail-io1-f46.google.com
[209.85.166.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C78B65D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 21:01:33 +0000 (UTC)
Received: by mail-io1-f46.google.com with SMTP id m7so3053087ioa.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 14:01:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:from:date:message-id:subject:to;
bh=lfNja15zaKVr8gEVTZx2JdSjlWLKih/VOjRD1uTiKFQ=;
b=XVd+0f94hxPR4kaEfHIWhC/+9llxTVPxf4h99zTRLBboE2H1qeES9r2lkJJhr5mBVS
Gr1fnHcbNX37L/cSOGwdr+eiYIp5PKOTS6U7xbN/cICEO6VH2pGdfqNNvSxl/iASKBs5
8yzqsK2OyR+yftSpEcVQKBu9iIB7pTFDMiKvs=
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=lfNja15zaKVr8gEVTZx2JdSjlWLKih/VOjRD1uTiKFQ=;
b=dSANB0fzT7UmsCj81xJfN3NsylcCa0p4RBFZ+b2bajQn+38lRUMhFgucEGZU/EmQJl
KsflISpEW5Btax7o8q3kgep6oDr2b/gN69R20rC9mabHxuR42M33IG7XvBWmLDap5Ev+
dn+PNrVgf+h06KR2Hlmw1zSSmN0sCgm4oY35/iUiHuMlNUJHYQsVhMRMFCr2i3VH+Y3S
vm/CBGn8Sauwbbh53Hw4GLwTm0NSWpfXuAYSzxpt4LKB1ahMUti/YTwIBbMGonRrwSa2
OxVdrps4RhCdnKZmIrbEYqSmpRleRgAy67dpO0q7C+S+Otz3TW3ZwHeDmTmF0lrA52s3
fCNg==
X-Gm-Message-State: APjAAAWKag7RABOjisKwMZ8cIH6exoWcYzLuaY0G4h7lxjIZ2iK7u5kx
qLKvUDpecduRpQFa/2FhsU9JHqC2CXVihHSnYzjfgrXelkg=
X-Google-Smtp-Source: APXvYqw0JQGbZETkOzpeOUvBj9wFSyb2uEmiirfkLuvi3XWgvcCJJrmLafoPlPOuzme2pPEJ+JIdFU8bhT93buJAgWg=
X-Received: by 2002:a5e:c817:: with SMTP id y23mr5567901iol.290.1558558892722;
Wed, 22 May 2019 14:01:32 -0700 (PDT)
MIME-Version: 1.0
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Wed, 22 May 2019 17:01:21 -0400
Message-ID: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000029a5ce05898045db"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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, 23 May 2019 13:31:42 +0000
Subject: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
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: Wed, 22 May 2019 21:01:34 -0000
--00000000000029a5ce05898045db
Content-Type: text/plain; charset="UTF-8"
Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and
OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for
Bitcoin via new Script operations. However, I think that these proposals
miss the mark when it comes to how they approach Bitcoin Script and
language features.
Bitcoin Script appears designed to be a flexible programmable system that
provides generic features to be composed to achieve various purposes.
Thus, when we design new language features for Script, we should be
striving, as much as possible, to similarly build general purpose tools
which can in turn be used for a variety of purposes.
I feel the SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY proposals fail
to achieve these design goals. They are both are designed with very narrow
applications in mind, while also going out of their way to extend the
semantic domain of the interpretation of Bitcoin operations in new ways
that complicate their specification. In the case of SIGHASH_ANYPREVOUT,
the semantic domain is extended by adding new counters to track the use of
various v0 and v2 signature types. In the case of
OP_CHECKOUTPUTHASHVERIFY, it employs a new context-sensitive operation that
peeks at the value of surrounding opcodes.
Instead, I propose that, for the time being, we simply implement OP_CAT and
OP_CHECKSIGFROMSTACKVERIFY. OP_CAT pops two byte arrays off the stack and
pushes their concatenation back onto the stack. OP_CHECKSIGFROMSTACKVERIFY
pops a signature, message, and pubkey off the stack and performs a
bip-schnorr verification on the SHA256 hash of the message.
In concert, these two operations enable:
* Oracle signature verification, including discrete log contracts.
* Amortized secure multiparty computations (see "Amortizing Secure
Computation with Penalties" by Kumaresan and Bentov).
* Transaction introspection including:
+ Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply by
the nature of the construction.
+ Decide if a transaction has exactly one input or not. (etc.)
+ Weak covenants, which can verify output scripts to see if they are among
a set of predefined values or verify the output hash.
and presumably more applications as well.
For better or for worse, without an OP_PUBKEYTWEEK operation available, the
more interesting recursive-covenants remain largely out of reach, with the
exception of a recursive covenant that is only able to send back to its own
address, possibly abusing its own TXO value as a state variable.
All this is accomplished by two straightforward opcodes whose semantics are
pure computational operations on stack values. The only semantic
side-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the
existing 'sigops_passed' count. Moreover, I feel that adding these
operations does not preclude adding more specialized opcodes in the future
as an optimization for whatever popular constructions come up, once we know
what those are.
I feel that this style of generic building blocks truly embodies what is
meant by "programmable money".
--00000000000029a5ce05898045db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div>Recently there have been some tapscript proposals, SIGHASH_A=
NYPREVOUT and OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new f=
eatures for Bitcoin via new Script operations.=C2=A0 However, I think that =
these proposals miss the mark when it comes to how they approach Bitcoin Sc=
ript and language features.</div><div><br></div><div>Bitcoin Script appears=
designed to be a flexible programmable system that provides generic featur=
es to be composed to achieve various purposes.=C2=A0 Thus, when we design n=
ew language features for Script, we should be striving, as much as possible=
, to similarly build general purpose tools which can in turn be used for a=
variety of purposes.</div><div><br></div><div>I feel the SIGHASH_ANYPREVOU=
T and OP_CHECKOUTPUTHASHVERIFY proposals fail to achieve these design goals=
.=C2=A0 They are both are designed with very narrow applications in mind, w=
hile also going out of their way to extend the semantic domain of the inter=
pretation of Bitcoin operations in new ways that complicate their specifica=
tion.=C2=A0 In the case of SIGHASH_ANYPREVOUT, the semantic domain is exten=
ded by adding new counters to track the use of various v0 and v2 signature =
types.=C2=A0 In the case of OP_CHECKOUTPUTHASHVERIFY, it employs a new cont=
ext-sensitive operation that peeks at the value of surrounding opcodes.</di=
v><div><br></div><div>Instead, I propose that, for the time being, we simpl=
y implement OP_CAT and OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 OP_CAT pops two by=
te arrays off the stack and pushes their concatenation back onto the stack.=
=C2=A0 OP_CHECKSIGFROMSTACKVERIFY pops a signature, message, and pubkey off=
the stack and performs a bip-schnorr verification on the SHA256 hash of th=
e message.<br></div><div><br></div><div>In concert, these two operations en=
able:</div><div><br></div><div>* Oracle signature verification, including d=
iscrete log contracts.</div><div>* Amortized secure multiparty computations=
(see "Amortizing Secure Computation with Penalties" by Kumaresan=
and Bentov).</div><div>* Transaction introspection including:<br></div><di=
v><a class=3D"gmail_plusreply" id=3D"gmail-plusReplyChip-0">+</a>=C2=A0Simu=
lated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply by the na=
ture of the construction.<br></div><div><a class=3D"gmail_plusreply" id=3D"=
gmail-plusReplyChip-1">+</a> Decide if a transaction has exactly one input =
or not. (etc.)</div><div>+ Weak covenants, which can verify output scripts =
to see if they are among a set of predefined values or verify the output ha=
sh.<br></div><div><br></div><div>and presumably more applications as well.<=
br></div><div><br></div><div>For better or for worse, without an OP_PUBKEYT=
WEEK operation available, the more interesting recursive-covenants remain l=
argely out of reach, with the exception of a recursive covenant that is onl=
y able to send back to its own address, possibly abusing its own TXO value =
as a state variable.</div><div><br></div><div>All this is accomplished by t=
wo straightforward opcodes whose semantics are pure computational operation=
s on stack values.=C2=A0 The only semantic side-effect is that OP_CHECKSIGF=
ROMSTACKVERIFY would count towards the existing 'sigops_passed' cou=
nt.=C2=A0 Moreover, I feel that adding these operations does not preclude a=
dding more specialized opcodes in the future as an optimization for whateve=
r popular constructions come up, once we know what those are.<br></div><div=
><br></div><div>I feel that this style of generic building blocks truly emb=
odies what is meant by "programmable money".<br></div></div></div=
></div></div></div>
--00000000000029a5ce05898045db--
|
