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-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_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-secure-the-bag.mediawiki
--
@JeremyRubin


On Mon, Jul 8, 2019 at 3:25 AM Dmitry Petukhov <dp@simplexum.com> 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.

<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 = 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.

В 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.
>
> 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 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 = 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 = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,
> >                        amount, sequence)
> >
> > and calculate a signature sig = 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=G and nonce R=G, which means you need to calculate
> > s=1+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
> >