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