I think this is a worthy idea as the funding outpoint of any off-chain protocols is an invariant known by participants. Thus by sponsoring an outpoint you're requiring from network mempools to increase the feerate of the package locally known without assuming about the concrete state as any of them confirming is moving protocol forward.

That said, a malicious counterparty can still broadcast a heavy-weighted transaction such as an honest party, devoid of knowledge of this weight, won't attach a sponsor with a fee high enough to timely confirm the sponsoree. This counterparty capability is a function of package malleability allowed by the off-chain protocol.

Thus an honest party has to overshoot your bump as a default setting. Now this is a new concern as such a mechanism can be used as a fee-burning one by your counterparty. I believe we want a fee-burning equilibrium for any pinning solution, Mallet shouldn't force Alice to overpay in fee more than Mallet is ready to feerate-bid in network mempools.

> I don't think package relay based only on feerate solves RBF transaction
> pinning (and maybe also doesn't solve ancestor/dependent limit pinning).

Yes I agree with this. There are some really nasty cases of pinning where an adversary with knowledge of the tx-relay topology can block your compelling feerate bids (sponsors/package relay/anchor whatever) from propagating by leveraging conflicts and RBF logic.

Outbound tx-relay peers rotation which makes the tx-relay topology harder to observe could help.

Antoine

Le lun. 21 sept. 2020 à 12:27, Jeremy <jlrubin@mit.edu> a écrit :
Responses Inline:

Would it make sense that, instead of sponsor vectors
pointing to txids, they point to input outpoints?  E.g.:

1. Alice and Bob open a channel with funding transaction 0123...cdef,
   output 0.

2. After a bunch of state updates, Alice unilaterally broadcasts a
   commitment transaction, which has a minimal fee.

3. Bob doesn't immediately care whether or not Alice tried to close the
   channel in the latest state---he just wants the commitment
   transaction confirmed so that he either gets his money directly or he
   can send any necessary penalty transactions.  So Bob broadcasts a
   sponsor transaction with a vector of 0123...cdef:0

4. Miners can include that sponsor transaction in any block that has a
   transaction with an input of 0123...cdef:0.  Otherwise the sponsor
   transaction is consensus invalid.

(Note: alternatively, sponsor vectors could point to either txids OR
input outpoints.  This complicates the serialization of the vector but
seems otherwise fine to me.)

This seems like a fine suggestion and I think addresses Antoine's issue.

I think there are likely some cases where you do want TXID and not Output (e.g., if you
are sponsoring a payment to your locktime'd cold storage wallet (no CPFP) from an untrusted third party (no RBF), they can grift you into paying for an unrelated payment). This isn't a concern when the root utxo is multisig & you are a participant.

The serialization to support both, while slightly more complicated, can be done in a manner that permits future extensibility as well if there are other modes people require.

 

> 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.

I don't think package relay based only on feerate solves RBF transaction
pinning (and maybe also doesn't solve ancestor/dependent limit pinning).
Though, certainly, package relay has the major advantage over this
proposal (IMO) in that it doesn't require any consensus changes.
Package relay is also very nice for fixing other protocol rough edges
that are needed anyway.

-Dave

I think it's important to keep in mind this is not a rival to package relay; I think you also want package relay in addition to this, as they solve different but related problems.

Where you might be able to simplify package relay with sponsors is by doing a sponsor-only package relay, which is always limited to 2 transactions, 1 sponsor, 1 sponsoree. This would not have some of the challenges with arbitrary-package package-relay, and would (at least from a ux perspective) allow users to successfully get parents with insufficient fee into the mempool.