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
|
Return-Path: <dp@simplexum.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1BC122391
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Jul 2019 10:25:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2244487C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Jul 2019 10:25:04 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
by mail.ruggedbytes.com (Postfix) with ESMTPS id 1E6EA260051D;
Mon, 8 Jul 2019 10:25:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
s=mail; t=1562581503;
bh=AE5Lvr3wltK5jyaOipdS8XGsLIBYR2zpa6S55QmLWdU=;
h=Date:From:To:Cc:Subject:In-Reply-To:References;
b=g31UOaP9uaccJad4dOCSKzmaNMpjcmSd0VqEvZx22+V3N4Tu8hQO3oddjnfXdq4jM
W/RZwnuCFqNNWfssV+ppbAAxODpyuZtHhmiqc2Tr2kmxLvcsb+AUmKBLVWljUyQ6QT
nVApNlyv5PK3XADJInD9wNPi5WKHCObY+FbeZ/40=
Date: Mon, 8 Jul 2019 15:26:24 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20190708152624.39c33985@simplexum.com>
In-Reply-To: <CAD5xwhgEQKdTCSLQn4-X_atT5_aE-1hEKk0xd1wm1m0qotwYXQ@mail.gmail.com>
References: <CAD5xwhjSj82YYuQHHbwgSLvUNV2RDY0b=yMYeLj-p6j7PpS9-Q@mail.gmail.com>
<20190605093039.xfo7lcylqkhsfncv@erisian.com.au>
<im0q8670MxshmvMLmoJU0dv4rFhwWZNvQeQYv7i4fBWJOx0ghAdH8fYuQSqNxO2z8uxXGV-kurinUDfl0FsLWD0knw_U_h3zVZ0xy7vmn8o=@protonmail.com>
<CAMZUoK=ZB06jwAbuX2D=aN8ztAqr_jSgEXS1z1ABjQYVawKCBQ@mail.gmail.com>
<20190620220552.metrqaul3iporwma@erisian.com.au>
<CAD5xwhgEQKdTCSLQn4-X_atT5_aE-1hEKk0xd1wm1m0qotwYXQ@mail.gmail.com>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU 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: Tue, 09 Jul 2019 06:03:36 +0000
Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)
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, 08 Jul 2019 10:25:06 -0000
If you make ANYPREVOUTANYSCRIPT signature not the only signature that
controls this UTXO, but use it solely for restricting the spending
conditions such as the set of outputs, and require another signature
that would commit to the whole transaction, you can eliminate
malleability, for the price of additional signature, of course.
<control-sig> <control-P> CHECKSIG <P> CHECKSIG
(CHECKMULTISIG/CHECKSIGADD might be used instead)
where control-P can even be a pubkey of a key that is publicly known,
and the whole purpose of control-sig would be to restrict the outputs
(control-sig would be created with flags meaning ANYPREVOUTANYSCRIPT).
Because control-sig does not depend on the script and on the current
input, there should be no circular dependency, and it can be part of
the redeem script.
P would be the pubkey of the actual key that is needed to spend this
UTXO, and the signature of P can commit to all the inputs and outputs,
preventing malleability.
I would like to add that it may make sense to just have 2 additional
flags for sighash: NOPREVOUT and NOSCRIPT.
NOPREVOUT would mean that previous output is not committed to, and when
combined with ANYONECANPAY, this will mean ANYPREVOUT/NOINPUT:
ANYONECANPAY means exclude all inputs except the current, and NOPREVOUT
means exclude the current input. Thus NOPREVOUT|ANYONECANPAY =3D NOINPUT
With NOPREVOUT|ANYONECANPAY|NOSCRIPT you would have ANYPREVOUTANYSCRIPT
with NOPREVOUT|NOSCRIPT you can commit to "all the inputs beside the
current one", which would allow to create a spending restriction like
"this UTXO, and also one (or more) other UTXO", which might be useful
to retroactively revoke or transfer the rights to spend certain UTXO
without actually moving it:
think 'vault' UTXO that is controlled by Alice, but requires additional
'control' UTXO to spend. Alice have keys for both 'vault' UTXO, and
'control' UTXO, but Bob have only key for 'control' UTXO.
If Bob learnsthat Alice's vault UTXO key is at risk of compromize,
he spends the control UTXO, and then Alice's ability to spend vault
UTXO vanishes.
You can use this mechanism to transfer this right to spend if you
prepare a number of taproot branches with different pairs of (vault,
control) keys and a chain of transactions that each spend the previous
control UTXO such that the newly created UTXO becomes controlled by the
control key of the next pair, together with vault key in that pair.
=D0=92 Sat, 22 Jun 2019 23:43:22 -0700
Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> This is insufficient: sequences must be committed to because they
> affect TXID. As with scriptsigs (witness data fine to ignore). NUM_IN
> too.
>=20
> Any malleability makes this much less useful.
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>=20
>=20
> On Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> > On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote: =20
> > > So with regards to OP_SECURETHEBAG, I am also "not really seeing
> > > any =20
> > reason to =20
> > > complicate the spec to ensure the digest is precommitted as part
> > > of the opcode." =20
> >
> > Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT
> > (NOINPUT) sighash (Johnson Lau's mentioned this before, but not
> > sure if it's been spelled out anywhere); ie instead of constructing
> >
> > X =3D Hash_BagHash( version, locktime, [outputs], [sequences],
> > num_in )
> >
> > and having the script be "<X> OP_SECURETHEBAG" you calculate an
> > ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:
> >
> > Y =3D Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,
> > amount, sequence)
> >
> > and calculate a signature sig =3D Schnorr(P,m) for some pubkey P, and
> > make your script be "<sig> <P> CHECKSIG".
> >
> > That loses the ability to commit to the number of inputs or restrict
> > the nsequence of other inputs, and requires a bigger script (sig
> > and P are ~96 bytes instead of X's 32 bytes), but is otherwise
> > pretty much the same as far as I can tell. Both scripts are
> > automatically satisfied when revealed (with the correct set of
> > outputs), and don't need any additional witness data.
> >
> > If you wanted to construct "X" via script instead of hardcoding a
> > value because it got you generalised covenants or whatever; I think
> > you could get the same effect with CAT,LEFT, and RIGHT: you'd
> > construct Y in much the same way you construct X, but you'd then
> > need to turn that into a signature. You could do so by using pubkey
> > P=3DG and nonce R=3DG, which means you need to calculate
> > s=3D1+hash(G,G,Y)*1 -- calculating the hash part is easy, multiplying
> > it by 1 is easy, and to add 1 you can probably do something along
> > the lines of:
> >
> > OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT
> >
> > (ie, take the last 4 bytes, increment it using 4-byte arithmetic,
> > then cat the first 28 bytes and the result. There's overflow issues,
> > but I think they can be worked around either by allowing you to
> > choose different locktimes, or by more complicated script)
> >
> > Cheers,
> > aj
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > =20
|
