Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

It's also not something that's trivial to set up in any scheme because you have to have an ordering around when you set up the tx intended to be the inverse lock before you create the tx using it. -- @JeremyRubin On Thu, Sep

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

CTV does not enable this afaiu because it does not commit to the inputs (otherwise there's a hash cycle for predicting the output's TXID. -- @JeremyRubin On Thu, Sep 3, 2020 at 7:39 AM Dmitry Petukhov wrote: > Just had an

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Just had an idea that an an "inverse timelock" can be made almost-certainly automatic: a revocation UTXO shall become anyone-can-spend after a timeout, and bear some non-dust amount. Before the timelock expiration, it shall be spendable only along with the covenant-locked 'main' UTXO (via a

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

В Sun, 7 Jun 2020 15:45:16 -0700 Jeremy via bitcoin-dev wrote: > What I think we'll eventually land on is a way of doing a tx > that contributes fee to another tx chain as a passive observer to > them. While this breaks one abstraction around how dependencies > between transactions are

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Hi Joachim, Fantastic questions! I think it makes sense to think about it in terms of today, and then in terms of a long-dated future where wallets have much richer native understandings of these things. This helps preserve the purity of the arguments I'm making with respect to what it would

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Hello everyone, regarding OP_CTV, I am considering the scaling use case, specifically an exchange (or similar) who wants to batch pay to OP_CTV to many users, and I wonder 1) How do you expect the exchange to communicate the proof of the payment to the user wallets such that they are able to

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Good morning Dmitry, and Jeremy, > There is a principle that some find valuable: "During reorgs of depth > less than 100, it is always possible to eventually replay transactions > from the old branch into the new branch as long as no double spends are > attempted" (quoted from Russel O'Connor

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Hi Dmitry, I don't think that this is fundamentally introducing new behavior, but let's take a closer look. We can talk about the issue you bring up purely in terms of a hypothetical "OP_CHECKINPUTOUTPOINTVERIFY" and "OP_CHECKINPUTSCRIPTVERIFY" (CIOV, CISV) with obvious implied by name

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

I decided to take this thread back on-list because I beleive that the 'revocation utxo' feature enabled by OP_CTV commiting to scriptSig may have wider implications that can slightly change the behavior of Bitcoin as a system, and some might not expect such changes or might not find them

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

I've updated the main branch (ctv) to match ctv-v2, and pushed branches ctv-v1 which points at the prior versions. Thanks to Dmitry Petukhov for helping me fix several typos and errors. I also wanted to share some some "non-technical" tax analysis covering the use of OP_CTV for batched payments.

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

I've prepared a draft of the changes noted above (some small additional modifications on the StandardTemplateHash described in the BIP), but have not yet updated the main branches for the BIP to leave time for any further feedback. See below: BIP:

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Three changes I would like to make to the OP_CTV draft. I think this should put the draft in a very good place w.r.t. outstanding feedback. The changes can all be considered/merged independently, though, they are written below assuming all of them are reasonable. 1) *Make the hash commit to the

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Thanks for the feedback Russell, now and early. It deeply informed the version I'm proposing here. I weighed carefully when selecting this design that I thought it would be an acceptable tradeoff after our discussion, but I recognize this isn't exactly what you had argued for. First off, with

Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Thanks for this work Jeremy. I know we've discussed this before, but I'll restate my concerns with adding a new "global" state variable to the Script interpreter for tracking whether the previous opcode was a push-data operation or not. While it isn't so hard to implement this in Bitcoin Core's

[bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

Bitcoin Developers, Pleased to announce refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY (replaces previous OP_SECURETHEBAG BIP). Primarily: 1) Changed the name to something more fitting and acceptable to the community 2) Changed the opcode specification to use the argument off of the