Hi,
I think the topic of how to improve transaction relay policy and fee bumping is an important one that needs to be worked on, so I'm glad this is a topic of discussion. However I am pretty skeptical of this consensus change proposal:
The Sponsor Vector TXIDs must also be in the block the transaction is validated in, with no restriction on order or on specifying a TXID more than once.
That means that if a transaction is confirmed in a block without its sponsor, the sponsor is no longer valid. This breaks a design principle that has been discussed many times over the years, which is that once a valid transaction is created, it should not become invalid later on unless the inputs are double-spent. This principle has some logical consequences that we've come to accept, such as transaction chains being valid across small reorgs in the absence of malicious (double-spend) behavior.
I think that this principle is a useful one and that there should be a high bar for doing away with it. And it seems to me that this proposal doesn't clear that bar -- 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.
My understanding of the main benefit of this approach is that this allows 3rd parties to participate in fee bumping. But that behavior strikes me as also problematic, because it introduces the possibility of 3rd party griefing, to the extent that sponsor transactions in any way limit chains of transactions that would be otherwise permitted. If Alice sends Bob some coins, and Alice and Bob are both honest and cooperating, Mallory shouldn't be able to interfere with their low-feerate transaction by (eg) pinning it with a large transaction that "sponsors" it (ie a large transaction that is just above the feerate of the parent, which prevents additional child transactions and makes it more expensive to RBF).
This last issue of pinning could be improved in this proposal by requiring that a sponsor transaction bring the effective feerate of its package up to something which should be confirmed soon (rather than just being a higher feerate than the tx it is sponsoring). However, we could also carve out a policy rule just like that today, without any consensus changes needed, to help with pinning (which is probably a good idea! I think this would be useful work). So I don't think that approaches in that direction would be unique to this proposal.
We allow one Sponsor to replace another subject to normal replacement policies, they are treated as conflicts.
This policy rule of allowing sponsor transactions to RBF each other also seems problematic; that means that if Alice is paying Bob in a transaction that is also sponsoring some other transaction (perhaps from Alice to someone else), then Mallory can cause the transaction going to Bob to become invalid by RBF bumping it and sponsoring the parent transaction herself? Allowing 3rd parties to interfere with transactions between others seems like a complex and undesirable design to introduce.
In summary: this proposal seems like a CPFP replacement, requiring many policy rules along with a consensus change to be worked out to get right; I think we could achieve largely the same effect by improving the current policy rules to make CPFP work better without a consensus change. And while what is unique about this proposal is that it allows for 3rd parties to attach themselves to the transaction graph of other parties, I think that is a complex interaction to introduce and has negative side effects as well.