Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style of covenants if it pulled data from the stack, the OP_SECURETHEBAG probably cannot create covenants even if it were to pull the data from the stack unless some OP_TWEEKPUBKEY operation is added to Script because the "commitment of the script itself" isn't part of the OP_SECURETHEBAG.
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." On Thu, Jun 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning aj, > > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote: > > > > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. > > > > I think you could generalise that slightly and make it fit in > > with the existing opcode naming by calling it something like > > "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the stack, > > consisting of a sha256 hash and a sighash-byte, and adding a new sighash > > value corresponding to the set of info you want to include in the hash, > > which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | SIGHASH_ALL" > > > > FWIW, I'm not really seeing any reason to complicate the spec to ensure > > the digest is precommitted as part of the opcode. > > > > I believe in combination with `OP_LEFT` and `OP_CAT` this allows > Turing-complete smart contracts, in much the same way as > `OP_CHECKSIGFROMSTACK`? > > Pass in the spent transaction (serialised for txid) and the spending > transaction (serialised for sighash) as part of the witness of the spending > transaction. > > Script verifies that the spending transaction witness value is indeed the > spending transaction by `OP_SHA256 <SIGHASH_ALL> OP_SWAP OP_CAT > OP_CHECKTXDIGESTVERIFY`. > Script verifies the spent transaction witness value is indeed the spent > transaction by hashing it, then splitting up the hash with `OP_LEFT` into > bytes, and comparing the bytes to the bytes in the input of the spending > transaction witness value (txid being the bytes in reversed order). > > Then the Script can extract a commitment of itself by extracting the > output of the spent transaction. > This lets the Script check that the spending transaction also pays to the > same script. > > The Script can then access a state value, for example from an `OP_RETURN` > output of the spent transaction, and enforce that a correct next-state is > used in the spending transaction. > If the state is too large to fit in a standard `OP_RETURN`, then the > current state can be passed in as a witness and validated against a hash > commitment in an `OP_RETURN` output. > > I believe this is the primary reason against not pulling data from the > stack. > > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
