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.
concept is sponsors. hrdnh and jeremy have talked about it a good bit. can be very efficient.
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.
Reverse it, it's still one bit for multiple transactions. "The next tx is committing to me".
Doesn't change anything. The transaction still needs to commit securely.
Oddbean new post about login | logout