"As Jeremy indicated to us above, this is the season for such shenanigans. It’s approaching summer after all."
Ah yes, the birds chirping, flowers blooming. Consensus drama looming. The wonderful signs that spring-time is finally here!
reply
@k00b this is where I think the newsletter feature would have come really handy for people who want to read the discussion about CTV from the bitcoin-dev and bitcoin-core-dev. You still planning on working on it?
reply
Yeah! It’ll go out today
reply
Oh no, I think you misunderstood and I completely forgot about this until now. I meant the ability to read emails sent to the bitcoin-dev mailing list on stacker news
reply
Awesome!
reply
I was waiting for a good roundup on this! Jeremy was at Bit Devs last night discussing but I had to cut out.
reply
Looks like its time for me to figure out what OP_CTV even does on a deeper level than it locks some stuff up
reply
The main proponent of this upgrade, Jeremy Rubin, in a bold move, recently announced the imminent release of a new client with OP_CTV activation parameters. We discuss the proposed softfork activation mechanisms with Jeremy, challenging him on some of the most controversial aspects of his proposal.
OP_CTV (Check Template Verify) allows a user to create a Bitcoin address that is associated with a commitment hash of some components in a potential future transaction, most notably the commiting to the transaction outputs.
If any coins are sent to this address, the funds can only be spent under certain conditions, the conditions that have already been committed to by the hash. This is sometimes called a covenant.
OP_CTV requires a new OP code (Or more precisely, tighter conditions associated with an existing unused OP code put there by Satoshi in 2010) and is therefore a softfork upgrade to the Bitcoin protocol.
Consider the scenario where a cryptocurrency exchange wants to conduct a batched withdrawal to many clients (one input and many outputs). However, fee market conditions are tight and the exchange wants to avoid high fees. Therefore the exchange uses OP_CTV, by creating two transactions:
  1. Sending the funds to one output in the commitment transaction, and
  2. The next transaction, which spends those coins, in a multiple output transaction
Since the commitment transaction is confirmed, the exchange’s clients know they are guaranteed to get the funds, or at least that the exchange can never double spend them. At some point later on, when fees market conditions have loosened, transaction 2 is confirmed and everyone gets their money.
This OP_CTV system is said to be superior to the RBF and CPFP alternatives.
Perhaps a more compelling use case for OP_CTV, with more immediate applications, is vaults. With a vault, one wants Bitcoin inside the vault to only be sent to certain addresses under certain conditions. [...] Without an OP_CTV type upgrade, it is difficult to see how to achieve this kind of feature in Bitcoin.
As far as we can tell, most people seem to support OP_CTV or some technology like it, due to the reasonably simple implementation and very minimal changes to consensus code. However, there are some critics and they seem to fall into the following overlapping categories:
  • People who feel the upgrade is not urgent, due to limited demand or limited use cases,
  • People who think a superior alternative covenant solution may emerge or should be adopted
Bitcoin developer Matt Corallo explained his strong opposition [...]
"There Are Still Various Proposals For Covenants Floating Around And We’re Still In The Very Early Stages Of The Reconciliation Of Them And The Bitcoin Technical Community (Or At Least Those Interested In Working On Covenants) Doesn’t Even Remotely Show Any Signs Of Consensus Around Any Concrete Proposal."
reply
Here is a related post:
Is OP_CTV opening up new potential attack vectors on bitcoins censorship resistance? #22486
reply
The main proponent of this upgrade, Jeremy Rubin, in a bold move, recently announced the imminent release of a new client with OP_CTV activation parameters. We discuss the proposed softfork activation mechanisms with Jeremy, challenging him on some of the most controversial aspects of his proposal.
OP_CTV (Check Template Verify) allows a user to create a Bitcoin address that is associated with a commitment hash of some components in a potential future transaction, most notably the commiting to the transaction outputs.
If any coins are sent to this address, the funds can only be spent under certain conditions, the conditions that have already been committed to by the hash. This is sometimes called a covenant.
OP_CTV requires a new OP code (Or more precisely, tighter conditions associated with an existing unused OP code put there by Satoshi in 2010) and is therefore a softfork upgrade to the Bitcoin protocol.
Consider the scenario where a cryptocurrency exchange wants to conduct a batched withdrawal to many clients (one input and many outputs). However, fee market conditions are tight and the exchange wants to avoid high fees. Therefore the exchange uses OP_CTV, by creating two transactions:
  1. Sending the funds to one output in the commitment transaction, and
  2. The next transaction, which spends those coins, in a multiple output transaction
Since the commitment transaction is confirmed, the exchange’s clients know they are guaranteed to get the funds, or at least that the exchange can never double spend them. At some point later on, when fees market conditions have loosened, transaction 2 is confirmed and everyone gets their money.
This OP_CTV system is said to be superior to the RBF and CPFP alternatives.
Perhaps a more compelling use case for OP_CTV, with more immediate applications, is vaults. With a vault, one wants Bitcoin inside the vault to only be sent to certain addresses under certain conditions. [...] Without an OP_CTV type upgrade, it is difficult to see how to achieve this kind of feature in Bitcoin.
As far as we can tell, most people seem to support OP_CTV or some technology like it, due to the reasonably simple implementation and very minimal changes to consensus code. However, there are some critics and they seem to fall into the following overlapping categories:
  • People who feel the upgrade is not urgent, due to limited demand or limited use cases,
  • People who think a superior alternative covenant solution may emerge or should be adopted
Bitcoin developer Matt Corallo explained his strong opposition [...]
"There Are Still Various Proposals For Covenants Floating Around And We’re Still In The Very Early Stages Of The Reconciliation Of Them And The Bitcoin Technical Community (Or At Least Those Interested In Working On Covenants) Doesn’t Even Remotely Show Any Signs Of Consensus Around Any Concrete Proposal."
reply