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

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.

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!

Would love to chat with reardoncode

Self hosted email is the way.

The annualized growth rate of bitcoin's chain state jumped from ~15% to ~28% over the last three weeks as inscription fever took off.

It will be interesting to see if the pace of chain state growth keeps up and what that means for the ability of people to run nodes in the future. Luckily, bandwidth is getting cheaper and high speed internet access is increasing, but it's hard to say what the long-term ramifications of 4MB blocks will be on the distribution of the network.