Yeah, I guess there is a cyclic dependency issue in my previous example given the need for a coinbase transaction to commit to the block’s wtxid merkle root, but you need to known the txid of the coinbase transaction before you can construct the witness for a transaction that verifies a merkle proof for a block containing itself.
I think you could implement sponsors themselves with just OP_CAT as long as both the sponsor transaction and the transaction it sponsors are in a merkle sub-tree that doesn’t include the coinbase transaction.
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 agree, and I don’t claim a false equivalency. However, I think it’s an existing problem that would be nice to solve, especially if the solution also makes very low cost sponsorship more appealing. I’ll try to spend some time better understanding how cluster mempool works so that I can better understand your concerns.
I think this is my point: single-transaction sponsors can now be exactly as efficient as paying a miner OOB (zero overhead). For a sponsor transaction with multiple dependencies, it’s 0.5 vbytes per dependency. That’s less than 0.5% overhead to sponsor a 1-input, 1-output P2TR.
We now have an exogenous fee-paying mechanism that uses almost the same amount of space as the best endogenous mechanisms. (And, in many cases, sponsors effectively uses less space!) I don’t think that’s something we should rush to soft fork in, but it brings me a lot of comfort when thinking about increased use of exogenous fees. If we as users ever do become concerned about excessive OOB fee paying, we have a drop-in solution. Additionally, if more and more of the network shifts to the use of protocols that depend on exogenous fee paying, we’ll have a scaling improvement ready to go.
I think the efficient multiple-use form of sponsors described earlier in this thread really requires a new witness version, which will automatically provide some level of opt-in given how few wallets/services seem to have implemented automatic bech32(m) forward compatibility. I have some other ideas for things we could do for (nearly) free at the same time, which I plan to open a separate thread about after I’ve spent at least a week collecting some data about use of reorg safe transaction chains on the existing network. But, in general, I currently think allowing sponsorship is something we should probably add the next time we plan to create a new witness version for general use—not something I think we should rush to add next week.