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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7EF9214B2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 May 2019 07:21:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 902C4A9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 May 2019 07:21:36 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1hV9wp-0005vw-Ow; Mon, 27 May 2019 17:21:33 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Mon, 27 May 2019 17:21:28 +1000
Date: Mon, 27 May 2019 17:21:28 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20190527072128.lbzeo6h23qgxvhsy@erisian.com.au>
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
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: Mon, 27 May 2019 14:25:27 +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: Mon, 27 May 2019 07:21:37 -0000
On Wed, May 22, 2019 at 05:01:21PM -0400, Russell O'Connor via bitcoin-dev wrote:
> Bitcoin Script appears designed to be a flexible programmable system that
> provides generic features to be composed to achieve various purposes.
Counterpoint: haven't the flexibly designed parts of script mostly been
a failure -- requiring opcodes to be disabled due to DoS vectors or
consensus bugs, and mostly not being useful in practice where they're
still enabled in BTC or on other chains where they have been re-enabled
(eg, Liquid and BCH)?
> Instead, I propose that, for the time being, we simply implement OP_CAT and
> OP_CHECKSIGFROMSTACKVERIFY.
FWIW, I'd like to see CAT enabled, though I'm less convinced about a
CHECKSIG that takes the message from the stack. I think CAT's plausibly
useful in practice, but a sig against data from the stack seems more
useful in theory than in practice. Has it actually seen use on BCH or
Liquid, eg? (Also, I think BCH's name for that opcode makes more sense
than Elements' -- all the CHECKSIG opcodes pull a sig from the stack,
after all)
> * Transaction introspection including:
> + Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply by the
> nature of the construction.
I think simulating an ANYPREVOUT sig with a data signature means checking:
S1 P CHECKSIG -- to check S1 is a signature for the tx
S1 H_TapSighash(XAB) P CHECKDATASIG
-- to pull out the tx data "X", "A", "B")
S2 H_TapSighash(XCB) Q CHECKDATASIG
-- for the ANYPREVOUT sig, with A changed to C to
avoid committing to prevout info
X SIZE 42 EQUALVERIFY
B SIZE 47 EQUALVERIFY
-- to make sure only C is replaced from "XCB"
So to get all those conditions checked, I think you could do:
P 2DUP TOALT TOALT CHECKSIGVERIFY
SIZE 42 EQUALVERIFY
"TapSighash" SHA256 DUP CAT SWAP CAT TOALT
SIZE 47 EQUALVERIFY TUCK
CAT FROMALT TUCK SWAP CAT SHA256 FROMALT SWAP FROMALT
CHECKDATASIGVERIFY
SWAP TOALT SWAP CAT FROMALT CAT SHA256 Q CHECKDATASIG
Where the stack elements are, from top to bottom:
S1: (65B) signature by P of tx
X: (42B) start of TapSighash spec
B: (47B) end of TapSighash spec (amount, nSequence, tapleaf_hash,
key_version, codesep_pos)
A: (73B) middle of TapSighash spec dropped for ANYPREVOUT (spend_type,
scriptPubKey and outpoint)
C: (1B) alternate middle (different spend_type)
S2: (64B) signature of "XCB" by key Q
So 298B for the witness data, and 119B or so for the script (if I've not
made mistakes), versus "P CHECKSIGVERIFY Q CHECKSIG" and S2 and S1 on
the stack, for 132B of witness data and 70B of script, or half that if
the chaperone requirement is removed.
I think you'd need to complicate it a bit further to do the
ANYPREVOUTANYSCRIPT variant, where you retain the commitment to
amount/nseq but drop the commitment to tapleaf_hash.
> I feel that this style of generic building blocks truly embodies what is meant
> by "programmable money".
For practical purposes, this doesn't seem like a great level of
abstraction to me. It's certainly better at "permissionless innovation"
though.
You could make these constructions a little bit simpler by having a
"CHECK_SIG_MSG_VERIFY" opcode that accepts [sig msg key], and does "sig
key CHECKSIGVERIFY" but also checks the the provided msg was what was
passed into bip-schnorr.
Cheers,
aj
|
