Right, that was a concern of @sdaftuar’s in the original thread. I agree that reorg safety has been a useful property these past 15 years, but I wonder if it will continue to be as useful in the future:
- Several of the soft fork proposals people are currently advocating for will allow scripts to verify SPV proofs, at which point it’ll be possible for scripts to implement the functionality of transaction sponsorship,
OP_EXPIRE, and several other features that are not reorg safe. - No one can safely rely upon an input in a contract protocol unless it’s been highly confirmed or comes from a chain of transactions they controlled that is rooted entirely in one or more highly confirmed transactions. Reorg safety is a convenience feature; contract protocols must not rely on it for security.
- Frequent use of RBF fee bumping on the network can also lead to completely accidental invalidation during reorgs.
If we expect the near future to include more expressive scripting, more use of contract protocols, and more use of RBF, then I don’t think we need to be as careful about protecting transaction chains against reorgs as we have been in the past.
I think that works fine with the scheme described in my OP. If we set a coinbase-like maturity limit on the output of any sponsor transaction, then any one of those outputs could be spent as the input to another sponsor transaction prior to maturity.