Rusty Russell on nostr

Open in Damus

@Rusty Russell 1732685661

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!

2011❤️27🤙5🚀3❤️2🎉1🏛️1

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

Rusty Russell · 64w

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 th...

Are there any better alternatives? BTW thank you for Bolt12.

Rearden 🥪🤖🍴🛩 · 64w

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.

Peter Todd · 64w

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,...

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.