Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

Bitcoin Core is somewhat outside my core competence, but the various OP_PUSHDATA are already multi-byte opcodes and GetOp already has a data return parameter that is suitable for returning the payload of an immediate 32-byte data variant of OP_SECURETHEBAG. All that I expect is needed is to ensure

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

I agree in principal, but I think that's just a bit of 'how things are' versus how they should be. I disagree that we get composability semantics because of OP_IF. E.g., the script "OP_IF " and "OP_END" are two scripts that separately are invalid as parsed, but together are valid. OP_IF alrea

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

I suspect that your conjecture is true. And given that it is plausible that we would want to add an opcode to tweak public keys, it seems like a reason design to avoid accidental covenants. (That said, I strongly prefer that the SECURETHEBAG data be the 32-bytes immediately following the opcode ra

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

Do you think the following hypothesis is more or less true: H: There is no set of pure extensions* to script E such that enabling E and OP_SECURETHEBAG as proposed enables recursive covenants, but E alone does not enable recursive covenants? * Of course there are things that specifically are spec

Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

OP_SECURETHEBAG doesn't include the script being executed (i.e the scriptPubKey specified in the output that is redeemed by this input) in its hash like ordinary signatures do . Of course, this ScriptPubKey is indirect