Hi Antoine,
I have a few high level thoughts on your post comparing these types of primitive to an explicit soft fork approach:
1) Transaction sponsors *is* a type of covenant. Precisely, it is very similar to an "Impossible Input" covenant in conjunction with a "IUTXO" I defined in my 2017 workshop
https://rubin.io/public/pdfs/multi-txn-contracts.pdf (I know, I know... self citation, not cool, but helps with context).
However, for Sponsors itself we optimize the properties of how it works & is represented, as well as "tighten the hatches" on binding to specific TX vs merely spend of the outputs (which wouldn't work as well with APO).
Perhaps thinking of something like sponsors as a form of covenant, rather than a special purpose thing, is helpful?
There's a lot you could do with a general "observe other txns in {this block, the chain}" primitive. The catch is that for sponsors we don't *care* to enable people to use this as a "smart contracting primitive", we want to use it for fee bumping. So we don't care about programmability, we care about being able to use the covenant to bump fees.
2) On Chain Efficiency.
A) Precommitted Levels
As you've noted, an approach like precomitted different fee levels might work, but has substantial costs.
However, with sponsors, the minimum viable version of this (not quite what is spec'd in my prior email, but it could be done this way if we care to optimize for bytes) would require 1 in and 1 out with only 32 bytes extra. So that's around 40 bytes outpoint + 64 bytes signature + 40 bytes output + 32 bytes metadata = 174 bytes per bump. Bumps in this way can also amortize, so bumping >1 txn at the same time would hit the limit of 32 bytes + 144/n bytes to bump more than one thing. You can imagine cases where this might be popular, like "close >1 of my LN channels" or "start withdrawals for 5 of my JamesOB vaulted coins"
B) Fancy(er) Covenants
We might also have something with OP_CAT and CSFS where bumps are done as some sort of covenant-y thing that lets you arbitrarily rewrite transactions.
Not too much to say other than that it is difficult to get these down in size as the scripts become more complex, not to mention the (hotly discussed of late) ramifications of those covenants more generally.
Absent a concrete fancy covenant with fee bumping, I can't comment.
3) On Capital Efficiency
Something like a precommitted or covenant fee bump requires the fee capital to be pre-committed inside the UTXO, whereas for something like Sponsors you can use capital you get sometime later. In certain models -- e.g., channels -- where you might expect only log(N) of your channels to fail in a given epoch, you don't need to allocate as much capital as if you were to have to do it in-band. This is also true for vaults where you know you only want to open 1 per month let's say, and not <all of your vaults> per month, which pre-committing requires.
4) On Protocol Design
It's nice that you can abstract away your protocol design concerns as a "second tier composition check" v.s. having to modify your protocol to work with a fee bumping thing.
There are a myriad of ways dynamic txns (e.g. for Eltoo) can lead to RBF pinning and similar, Sponsor type things allow you to design such protocols to not have any native way of paying for fees inside the actual "Transaction Intents" and use an external system to create the intended effect. It seems (to me) more robust that we can prove that a Sponsors mechanism allows any transaction -- regardless of covenant stuff, bugs, pinning, etc -- to move forward.
Still... careful protocol design may permit the use of optimized constructions! For example, in a vault rather than assigning *no fee* maybe you can have a single branch with a reasonable estimated fee. If you are correct or overshot (let's say 50% chance?) then you don't need to add a sponsor. If you undershot, not to worry, just add a sponsor. Adopted broadly, this would cut the expected value of using sponsors by <however good you are at estimating future fees>. This basically enables all protocols to try to be more efficient, but backstop that with a guaranteed to work safe mechanism.
There was something else I was going to say but I forgot about it... if it comes to me I'll send a follow up email.
Cheers,
Jeremy
p.s.
Of course this makes for a perfect DoS: it would be trivial for a miner to infer that you are using
a specific vault standard and guess other leaves and replace the witness to use the highest-feerate
spending path. You could require a signature from any of the participants. Or, at the cost of an
additional depth, in the tree you could "salt" each leaf by pairing it with -say- an OP_RETURN leaf.
you don't need a salt, you just need a unique payout addr (e.g. hardened derivation) per revocation txn and you cannot guess the branch.