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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E5F99C9F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 16:59:25 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DD28E7FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 16:59:24 +0000 (UTC)
Date: Thu, 23 May 2019 16:59:15 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1558630762;
bh=MWs4f8qv30e7PMlO4x2bVVktmOtJNmFruVpQcPXln2k=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=l24xRn5TVrcWPprgKbXs8Wypl5L3ODq0QMoY3EtjdUip7lWUkEhSjTj8GPfIP4S0l
UWtfgSL9Ar+BquvBTYpgfn9J0w3agJeIwPuYPnx31Hqehl5CBXQLusXeqBIAnEM9M8
3Pt73vZrUsIdEAO/UHYjREvAmW3Eatx7mx2fo8Q0=
To: Russell O'Connor <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-doGGpQeidaYIWCJLexeiJPyi1leWSjZ4nMdO6K2CmhnaTLLtJCz4kOTY5stLEuly0qe7TUSYjzqoksbiXPp7IrA-qk0c8Abr_2Nad7ZJks=@protonmail.com>
In-Reply-To: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW 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 17:02:47 +0000
Subject: Re: [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: Thu, 23 May 2019 16:59:26 -0000
Good morning Russell,
While I am sympathetic to this argument from first principles, as I underst=
and it, it requires that provided witness inputs will become larger, compar=
ed to "shortcuts" like `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`=
.
For instance, to simulate `SIGHASH_ANYPREVOUT` with `OP_CAT` and `OP_CHECKS=
IGFROMSTACK`, I would effectively split the unsigned transaction into its "=
inputs" and "outputs" part, concat them and use `OP_CHECKSIGFROMSTACK` on t=
he chaperone signature, and also use a normal `OP_CHECKSIGVERIFY` on that s=
ame chaperone signature, then dup the "outputs" part and use `OP_CHECKSIGFR=
OMSTACK` on the "any prevout"/"noinput" signature.
I would effectively give the transaction to itself as part of the witness, =
and further, I would also have to very carefully write the script (admitted=
ly the writing of the template could be done once, but it would require far=
more review than simple usages of the "limited" operations like `SIGHASH_A=
NYPREVOUT`).
So my witness stack would contain two signatures, and a duplicate of the tr=
ansaction itself, plus a very much complicated script, whereas use of `SIGH=
ASH_ANYPREVOUT` just requires two signatures and a script not much longer t=
han pre-Schnorr multisig scripts.
It seems to me desirable, to try to reduce bandwidth consumption on the Bit=
coin blockchain, including witness data.
Indeed, I had thought the whole exercise of putting `OP_CHECKSIGFROMSTACK` =
in a federated sidechain (Elements/Liquid) was to try to identify common pa=
tterns of usage for that opcode, and *then* to propose those common pattern=
s as specific "optimized" opcodes as a sort of "jet" for Bitcoin itself (bu=
t not `OP_CHECKSIGFROMSTACK` itself).
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Thursday, May 23, 2019 5:01 AM, Russell O'Connor via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:
> Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and=
OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for B=
itcoin via new Script operations.=C2=A0 However, I think that these proposa=
ls miss the mark when it comes to how they approach Bitcoin Script and lang=
uage features.
>
> Bitcoin Script appears designed to be a flexible programmable system that=
provides generic features to be composed to achieve various purposes.=
=C2=A0 Thus, when we design new language features for Script, we should be =
striving, as much as possible, to similarly build general purpose tools whi=
ch 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.=C2=A0 They are both are designed with very =
narrow applications in mind, while also going out of their way to extend th=
e semantic domain of the interpretation of Bitcoin operations in new ways t=
hat complicate their specification.=C2=A0 In the case of SIGHASH_ANYPREVOUT=
, the semantic domain is extended by adding new counters to track the use o=
f various v0 and v2 signature types.=C2=A0 In the case of OP_CHECKOUTPUTHAS=
HVERIFY, it employs a new context-sensitive operation that peeks at the val=
ue of surrounding opcodes.
>
> Instead, I propose that, for the time being, we simply implement OP_CAT a=
nd OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 OP_CAT pops two byte arrays off the st=
ack and pushes their concatenation back onto the stack.=C2=A0 OP_CHECKSIGFR=
OMSTACKVERIFY pops a signature, message, and pubkey off the stack and perfo=
rms 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 Comput=
ation with Penalties" by Kumaresan and Bentov).
> * Transaction introspection including:
> +=C2=A0Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned sim=
ply 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 amon=
g 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, t=
he more interesting recursive-covenants remain largely out of reach, with t=
he 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 a=
re pure computational operations on stack values.=C2=A0 The only semantic s=
ide-effect is that OP_CHECKSIGFROMSTACKVERIFY would count towards the exist=
ing 'sigops_passed' count.=C2=A0 Moreover, I feel that adding these operati=
ons does not preclude adding more specialized opcodes in the future as an o=
ptimization for whatever popular constructions come up, once we know what t=
hose are.
>
> I feel that this style of generic building blocks truly embodies what is =
meant by "programmable money".
|
