Right, I was off the shot. Thanks for the explanation.

As you mentioned, if the goal of the sponsor mechanism is to let any party drive a state N's first tx to completion, you still have the issue of concurrent states being pinned and thus non-observable for sponsoring by an honest party.

E.g, Bob can broadcast a thousand of revoked LN states and pin them with low-feerate sponsors such as these malicious packages absolute fee are higher than the honest state N. Alice can't fee-sponsor
them as we can assume she hasn't a global view of network mempools. Due to the proposed policy rule "The Sponsor Vector's entry must be present in the mempool", Alice's sponsors won't propagate. Even amending this rule, we can't assume Alice has a thousand of sponsoring utxos to avoid conflict between her own broadcast.

Of course, offchain protocols designers can limit a participant's capability to construct a pinning package by constraining its malleability and thus to always have a compelling feerate. E.g in Lightning you can bind the size of a commitment transaction by refusing relayed HTLCs and thus have less HTLC outputs. This security increase comes at the price of less protocol flexibility, e.g reducing payments throughput.

Further, a malicious counterparty can still take advantage of mempool-congestion spikes. Even if the pinning package has a compelling feerate, high enough to bounce off a honest broadcast, there is no guarantee it stays such. Just after the pinning, congestion can increase and bury it for long-enough until a timelock expires.

If we want to solve the hard cases of pinning, I still think mempool acceptance of a whole package only on the merits of feerate is the easiest solution to reason on.

Le sam. 19 sept. 2020 à 15:46, Jeremy <jlrubin@mit.edu> a écrit :

Antoine,

Yes I think you're a bit confused on where the actual sponsor vector is. If you have a transaction chain A->B->C and a sponsor S_A, S_A commits to txid A and A is unaware of S.

W.r.t your other points, I fully agree that the 1-to-N sponsored case is very compelling. The consensus rules are clear that sponsor commitments are non-rival, so there's no issue with allowing as many sponsors as possible and including them in aggregate. E.g., if S_A and S'_A both sponsor A with feerate(S*) > feerate(A), there's no reason not to include all of them in a block. The only issue is denial of service in the mempool. In the future, it would definitely be desirable to figure out rules that allow mempools to track both multiple sponsors and multiple sponsor targets. But in the interest of KISS, the current policy rules are designed to be minimally invasive and maximally functional.

In terms of location for the sponsor vector, I'm relatively indifferent. The annex is a possible location, but it's a bit odd as we really only need to allow one such vector per tx, not one per input, and one per input would enable some new use cases (maybe good, maybe bad). Further, being in the witness space would mean that if two parties create a 2 input transaction with a desired sponsor vector they would both need to specify it as you can't sign another input's witness data. I wholeheartedly agree with the sentiment though; there could be a more efficient place to put this data, but nothing jumps out to me as both efficient and simple in implementation (a new tx-level field sounds like a lot of complexity).

> n >=1 ? I think you can have at least one vector and this is matching the code

yes, this has been fixed in the gist (cred to Dmitry Petukhov for pointing it out first), but is correct in the code. Thank you for your careful reading.