Unless I’m missing something, I think any scripts that could be deployed using just tools like this would in fact be reorg safe – you’d need a way for a script to pull in data from the active headers chain itself in order to become invalid on a reorg.
(Thanks for linking to those examples – from a quick look, I don’t believe any of them propose op codes that would allow for inspecting anything outside of the transaction that is being validated, so as far as I can tell each of those proposals would be reorg safe. Please let me know if I’m mistaken!)
I believe there’s a substantial difference between a single transaction being able to be griefed by someone else, and anyone on the network always being able to grief anyone else on the network at any time.
I think it may be helpful to adopt the terminology that @instagibbs has described in Taxonomy of Transaction Fees in Smart Contracts.
As @instagibbs points out there, exogenous fees can (in theory) be used to pay for a transaction with or without CPFP; similarly, endogenous fees can also in theory arise with or without CPFP.
If we wanted to be true blockchain-space-minimalists, we would be arguing that all protocols move towards an endogenous-single-tx model only. I don’t work on layer 2 protocols myself and so don’t consider myself well-versed in what is possible and what is not, but my inclination is to think that this is probably overly restrictive. Of course, if people come up with protocols that work within that guideline, then that’s of course great.
I think what the transaction sponsor model is trying to do is make CPFP cheaper/more efficient in situations where a protocol is unable to bring endogenous fees to a transaction, compared with using anyone-can-spend outputs. However, in order to be workable, Jeremy had proposed a number of policy rules on top of the consensus change, which were needed in order to make sponsors useful as a CPFP/RBF alternative. From his mailing list post:
In this BIP, we only care to ensure a subset of behavior sufficient to replace CPFP and RBF for fee bumping.
Thus we restrict the mempool policy such that:
- No Transaction with a Sponsor Vector may have any child spends; and
- No Transaction with a Sponsor Vector may have any unconfirmed parents; and
- The Sponsor Vector must have exactly 1 entry; and
- The Sponsor Vector’s entry must be present in the mempool; and
- Every Transaction may have exactly 1 sponsor in the mempool; except
- Transactions with a Sponsor Vector may not be sponsored.
The mempool treats ancestors and descendants limits as follows:
- Sponsors are counted as children transactions for descendants; but
- Sponsoring transactions are exempted from any limits saturated at the time of submission.
This ensures that within a given package, every child transaction may have a sponsor, but that the mempool prefers to not accept new true children while there are parents that can be cleared.
To prevent garbage sponsors, we also require that:
- The Sponsor’s feerate must be greater than the Sponsored’s ancestor fee rate
We allow one Sponsor to replace another subject to normal replacement policies, they are treated as conflicts.
Looking at this now, this seems extremely similar to the rule set for v3 (TRUC!) children[1] – an opt-in policy to make RBF work better, while still allowing for CPFP. In Jeremy’s original post, he suggested that:
What is wanted is a minimal mechanism that allows arbitrary unconnected third parties to attach fees to an arbitrary transaction. The set of rules given tightly bounds how much extra work the mempool might have to do to account for the new sponsors in the worst case, while providing a “it always works” API for end users that is not subject to traditional issues around pinning.
What I argue instead is that the policy changes, not the consensus changes are what allow us to avoid the “traditional issues around pinning” – and the v3/TRUC proposal is an example of this.
So given that the policy changes are what is helpful here, the question becomes: is it worth changing the consensus model in order to save ~52 vbytes for protocols that rely on exogenous-fee-CPFP in order to fund transaction fees?
Exogenous-fee-CPFP is already still less efficient than paying a miner out of band to mine a given transaction, so if the concern is the miner-centralization-issue, then we should really abandon such protocols in favor of endogenous-fee-single-tx schemes. Given that we’re willing to tolerate some level of blockchain-inefficiency to make such protocols work, my personal view is that tradeoff to save those ~52vbytes is not worth it, and at a minimum, I’d suggest that the community first deploy exogenous-fee-CPFP protocols using existing methodologies (like anyone-can-spend outputs) to demonstrate utility and adoption before we seriously consider changing the consensus model.
And even if somehow such protocols gained enough adoption that shaving a few bytes to make them more efficient catches on, I’d still argue that we should not opt existing transactions into this behavior, because I believe there will always be unintended policy side effects from allowing arbitrary third parties to attach to the transaction graph, and I think good soft-fork design should compel us to avoid causing any potential harm to existing use cases/users when rolling out new features.
If I’m not mistaken, Jeremy’s original proposal didn’t seem to include a bound on the size of a sponsor transaction, something which is part of the TRUC/v3 proposal – without that, RBF pinning is still possible in a situation where someone creates a large sponsor transaction that is low feerate (but still above the feerate of the parent), making it difficult to replace with another higher feerate sponsor transaction. ↩︎