The problem with CTV is fees. When you look at most designs using CTV, they need *another* tx, and an anchor output, so they can pay fees.

What they really want is "this tx, plus an input and optional change output".

People tend to ignore fees in their protocol design. But I'm implementation they're critical, and only getting more so. Lightning has been down this path!


Onward 🫡


But aren't fees less of a burden if the utxo is shared?


There is, potentially, a cool trick which could help though! Jeremy proposed a kind of "neighbor fee" tx which would pay the fees for the immediately-preceding tx in a block (which, annoyingly, I can't find now! Anyone?). You really want this to stack (so it's probably better as a forward, rather than backward bit) and I don't think there's any code, but it makes CTV a more obviously optimal choice for simple covenants, AFAICT.


Are there any better alternatives?

BTW thank you for Bolt12.


Usually these schemes are used for unilateral exit, so no :(


anchors arent so bad now that ephemeral anchor relay policy is moving forward. you just spend the anchor output with a single fee input to pull your ctv spend through.


concept is sponsors. hrdnh and jeremy have talked about it a good bit. can be very efficient.


Costs. Another output and another tx. Ouch.


But yes, they're now *possible*. But they're really a workaround for not being able to express what you actually want.

But sponsors is a general solution to the problem: at allows a marketplace for fee boosting which may be competitive with miners (though it will always take 1 tx more). This works for any covenant scheme, which all seem to have the same "constant, but for fees" problem.


I would love sponsors! So clean and can be a Bitcoin-only business.


Thanks! There was a refinement where it used a single bit, rather than txids (but it was limited to sponsoring a single tx: you need to reverse it to set the bit in the sponsee if you want multiple txs for one bit).

I would love to see this soft fork...


Neighbor transactions can't be implemented as a mere bit. They have to commit to the transactions they're paying for cryptographically or miners would be able to manipulate them.

Neighbor transactions could be more efficient by committing to multiple transactions at once though, eg "hash the next N txids".


And in fairness, they could use a special hashing mode so at least the signature is used for both commitments without an additional N byte hash. But that is getting complex.


For what people mainly want CTV for it would be sufficient to commit to the number of _hashed_ outputs, and then only hash those outputs. Secondly, only commit to the input index (typically zero).

That would allow additional inputs and change outputs to be added as needed. And to avoid N² hashing, commit to the outputs with a hashed linked list or tree.

Thing is, this additional complexity doesn't save that many bytes compared to just using keyless anchors and CPFP. Particularly in the UTXO tree case where we're getting a path down a tree mined.


you n me both!


Terbaik 👍🏽


Freedom 😻


CTV?


Whenever calculating tx fees, I find it important to keep all nessecary fee logic contained within a single file, then pour a ring of salt around the file. This prevents the fee demons from escaping your calculation and crossing into the mortal realm.


Reverse it, it's still one bit for multiple transactions. "The next tx is committing to me".


It can though. In a tree, n/2 anchor outputs and n/2 inputs which spend them. But if you're all paying (the same) agent to neighbor-boost, it's one tx for all of them...


Doesn't change anything. The transaction still needs to commit securely.