Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9C2D114F5 for ; Thu, 3 Oct 2019 23:23:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 554FD89D for ; Thu, 3 Oct 2019 23:23:02 +0000 (UTC) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x93NN0eL010696 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 3 Oct 2019 19:23:00 -0400 Received: by mail-io1-f53.google.com with SMTP id b136so9534247iof.3 for ; Thu, 03 Oct 2019 16:23:00 -0700 (PDT) X-Gm-Message-State: APjAAAXIMGh6w+kC1Wm5R7FV+sxK1v5BXzusk8wTnwPd9z7cUrj9AoIA dohkwFXRIjV3xvIND7c1CudDka2KGtd3n/yztBo= X-Google-Smtp-Source: APXvYqwY65f0eJU0eNVQAn277omG9ge0jXSzXIfn2q2IDY426EX9yqj5OzTqC36EV6UYuAwvHhAAMIjEX2nih7y8Qpc= X-Received: by 2002:a92:5bc4:: with SMTP id c65mr12564623ilg.90.1570144980034; Thu, 03 Oct 2019 16:23:00 -0700 (PDT) MIME-Version: 1.0 References: <20190605093039.xfo7lcylqkhsfncv@erisian.com.au> <20190620220552.metrqaul3iporwma@erisian.com.au> <20190708152624.39c33985@simplexum.com> In-Reply-To: <20190708152624.39c33985@simplexum.com> From: Jeremy Date: Thu, 3 Oct 2019 16:22:47 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Dmitry Petukhov Content-Type: multipart/alternative; boundary="000000000000c7ec98059409dd22" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 23:23:04 -0000 --000000000000c7ec98059409dd22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've updated the BIP to no longer be based on Taproot, and instead based on a OP_NOP upgrade. The example implementation and tests have also been updated. BIP: https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-b= ag.mediawiki Implementation: https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:securetheba= g_master The BIP defines OP_NOP4 with the same semantics as previously presented. This enables OP_SECURETHEBAG for segwit and bare script, but not p2sh (because of hash cycle, it's impossible to put the redeemscript on the scriptSig without changing the bag hash). The implementation also makes a bare OP_SECURETHEBAG script standard as that is a common use case. To address Russel's feedback, once Tapscript is fully prepared (with more thorough script parsing improvements), multibyte opcodes can be more cleanly specified. Best, Jeremy n.b. the prior BIP version remains at https://github.com/JeremyRubin/bips/blob/op-secure-the-bag-taproot/bip-secu= re-the-bag.mediawiki -- @JeremyRubin On Mon, Jul 8, 2019 at 3:25 AM Dmitry Petukhov wrote: > 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. > > CHECKSIG

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 wrote: > > > This is insufficient: sequences must be committed to because they > > affect TXID. As with scriptsigs (witness data fine to ignore). NUM_IN > > too. > > > > Any malleability makes this much less useful. > > -- > > @JeremyRubin > > > > > > > > On Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote: > > > > So with regards to OP_SECURETHEBAG, I am also "not really seeing > > > > any > > > reason to > > > > complicate the spec to ensure the digest is precommitted as part > > > > of the opcode." > > > > > > 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 " 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 "

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 > > > > > --000000000000c7ec98059409dd22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I've updated the BIP = to no longer be based on Taproot, and instead based on a OP_NOP upgrade. Th= e example implementation and tests have also been updated.

BIP: <= a href=3D"https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-se= cure-the-bag.mediawiki">https://github.com/JeremyRubin/bips/blob/op-secure-= the-bag/bip-secure-the-bag.mediawiki
Implementation: https://github.com/bitcoin/bitcoin= /compare/master...JeremyRubin:securethebag_master

The BIP defines= OP_NOP4 with the same semantics as previously presented. This enables OP_S= ECURETHEBAG for segwit and bare script, but not p2sh (because of hash cycle= , it's impossible to put the redeemscript on the scriptSig without chan= ging the bag hash). The implementation also makes a bare OP_SECURETHEBAG s= cript standard as that is a common use case.

To address Russel's = feedback, once Tapscript is fully prepared (with more thorough script parsi= ng improvements), multibyte opcodes can be more cleanly specified.

Best,

Jeremy



On Mon, Jul 8, 2019 at 3:25 AM Dmitry Petukhov <= ;dp@simplexum.com> wrote:
If you make ANYPREVOUT= ANYSCRIPT 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<= br> "this UTXO, and also one (or more) other UTXO", which might be us= eful
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 additi= onal
'control' UTXO to spend. Alice have keys for both 'vault' U= TXO, 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> wr= ote:

> This is insufficient: sequences must be committed to because they
> affect TXID. As with scriptsigs (witness data fine to ignore). NUM_IN<= br> > too.
>
> Any malleability makes this much less useful.
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wr= ote:=C2=A0
> > > So with regards to OP_SECURETHEBAG, I am also "not real= ly seeing
> > > any=C2=A0
> > reason to=C2=A0
> > > complicate the spec to ensure the digest is precommitted as = part
> > > of the opcode."=C2=A0
> >
> > Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT=
> > (NOINPUT) sighash (Johnson Lau's mentioned this before, but n= ot
> > sure if it's been spelled out anywhere); ie instead of constr= ucting
> >
> >=C2=A0 =C2=A0X =3D Hash_BagHash( version, locktime, [outputs], [se= quences],
> > num_in )
> >
> > and having the script be "<X> OP_SECURETHEBAG" yo= u calculate an
> > ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:=
> >
> >=C2=A0 =C2=A0Y =3D Hash_TapSighash( 0, 0xc1, version, locktime, [o= utputs], 0,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 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 restr= ict
> > the nsequence of other inputs, and requires a bigger script (sig<= br> > > and P are ~96 bytes instead of X's 32 bytes), but is otherwis= e
> > 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 ha= rdcoding a
> > value because it got you generalised covenants or whatever; I thi= nk
> > 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 t= hen
> > need to turn that into a signature. You could do so by using pubk= ey
> > 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, multipl= ying
> > it by 1 is easy, and to add 1 you can probably do something along=
> > the lines of:
> >
> >=C2=A0 =C2=A0 =C2=A0OP_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.linuxfoundatio= n.org/mailman/listinfo/bitcoin-dev
> >=C2=A0

--000000000000c7ec98059409dd22--