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

I've updated the BIP to no longer be based on Taproot, and instead based on a OP_NOP upgrade. The example implementation and tests have also been updated. BIP: https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag.mediawiki Implementation:

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

If you make ANYPREVOUTANYSCRIPT signature not the only signature that controls this UTXO, but use it solely for restricting the spending conditions such as the set of outputs, and require another signature that would commit to the whole transaction, you can eliminate malleability, for the price of

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

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

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

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

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

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

Good morning Jeremy, While `OP_SECURETHEBAG` commits to the desired output script of the spending TX, what is being referred to here is the ability to verify the output script being spent, i.e. the script that actually contains the `OP_SECURETHEBAG`. By this, we are able to create a contract

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

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 On Fri, Jun 21, 2019 at

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

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

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

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

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

Good morning aj, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev wrote: > On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote: > > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of

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

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

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

Hi Russell, Thanks for the response. I double checked my work in drafting my response and realized I didn't address all the malleability concerns, I believe I have now (fingers crossed) addressed all points of malleability. *The malleability concerns are as follows:* A TXID is computed as: def

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

On Sat, Jun 1, 2019 at 12:47 PM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi All, > > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. > OP_SECURETHEBAG does more or less the same thing, but fixes malleability > issues and lifts the single output

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

> Using an OP_SECURETHEBAG Taproot, the recipient may even give the sender an > address which makes a channel unbeknownst to them. This requires special design to be safe. Every offchain protocol requires a backout transaction to be created before the funding transaction output is committed

[bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)

Hi All, OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*. OP_SECURETHEBAG does more or less the same thing, but fixes malleability issues and lifts the single output restriction to a known number of inputs restriction. OP_CHECKOUTPUTSVERIFY had some issues with malleability of