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 < firstname.lastname@example.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 > email@example.com > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list firstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev