(Replying out of order)
I made the assumption (perhaps incorrectly?) that anything that enables OP_CAT or an equivalent allows verifying a merkle proof in conjunction with existing opcodes (namely OP_SHA256/OP_HASH256). Similarly, those functions also allow verifying proof of work and header chains. With OP_IF, I think you could be accommodate any consensus-compatible shape of the partial merkle branch.
If you want to implement something like “my transaction expires at height 1,234,567”, you require a partial merkle branch that commits to both your transaction and a coinbase transaction with a BIP34 commitment of less than 1,234,567.
Proposals that enable OP_CAT or an equivalent include:
- BIN24-1
- Simplicity
- BTC Lisp
- Elements-style streaming SHA opcodes
- MATT
Any time I create an output paying someone I don’t trust, doesn’t that have the same problem? Similarly, any time I receive an output in a batched transaction that also pays other people—people I didn’t choose to be in a relationship with—doesn’t that also create the same problem? I think it’s already the case that typical users can be significantly affected by transaction graph dependencies that they have no control over.
I’m not opposed to an opt-in flag, but that has the downside of making blockchain analysis easier, so I’d love to avoid it if possible. If it’s possible to make cluster mempool safe for always-allowed sponsorship, I think that would also address the existing problems described above.
I don’t understand this point. Let me quickly quote what I believe is the entire text you previously wrote about this:
the fee bumping improvement that this proposal aims at is really coming from the policy change, rather than the consensus change. But if policy changes are the direction we’re going to solve these problems, we could instead just propose new policy rules for the existing types of transaction chaining that we have, rather than couple them to a new transaction type.
It seems to me like the problem you’re attempting to solve here is transaction pinning. That’s a problem created by policy, so it makes sense to me that we can solve it by policy alone.
But there’s another problem which has come to my attention more recently, which is the high cost of exogenous fee bumping compared to paying miners out of band. When the cost difference is too high, users might be incentivized to work with large miners directly, undermining Bitcoin’s decentralization.
Peter Todd has wielded that argument as a weapon against v3 policy and ephemeral anchors, which I think is unfair: those policies improve the current state of using Bitcoin for a large number of users, so I think we should pursue them (and thank you for all of your work on them!). But I find his fundamental argument worth thinking about.
That’s where I think sponsors are interesting. Whereas ephemeral anchors cost ~11 vbytes for the anchor output and ~41 vbytes for the spend, this improved sponsor proposal is only ~0.5 vbytes. It’s almost the same as the 0 vbytes used when paying a miner out of band or when using RBF under ideal circumstances. It gives us all of the advantages of exogenous fees (for contract protocols and also for regular fee bumping) without it’s major long-term downside of potentially worsening decentralization.
I don’t think it’s possible to achieve that efficiency benefit using policy only, at least not if we stick with a UTXO model. Any policy we create that boosts the priority of transaction A using funds from transaction B must be rooted in the consensus rules, otherwise miners will claim the value from B without mining A. But, if I’m missing something, I would love to learn more!