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.


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