Re: [bitcoin-dev] death to the mempool, long live the mempool

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Antoine,

> However, as we discussed recently, i do believe their is a failure mode here. On one hand, directly connecting to pools is already possible today and pretty effective given the current mining centralization. On the other hand, it's not possible for most pre-signed txs protocols to reliably (securely) use the Bitcoin tx relay network today to propagate time-sensitive transactions. Furthermore, even if these are fixed (eg via package-relay for (today's) Lightning Network) it seems like there is a stark contrast between what "L2 [0] protocols" need and what regular node operators can reasonably offer. A node operator is incentivized to relay transactions to:
> - have more privacy *if* they use their node to broadcast transactions (make it less distinguishable which relayed transaction comes from the wallet)
> - provide fee estimates *if* they need them
> - avoid bandwidth spikes on block connection (compact block relay)

To be clear: it is possible to design L2 protocols such that various counterparties (whose incentives may not align perfectly) can bid to put their views of the L2 state on the blockchain.
For instance, in Lightning, you may wish to close a channel at a high feerate in order to use your onchain funds quickly, yet your channel counterparty has no similar time pressure to get their onchain funds in a usable state.
Solutions such as anchor outputs have been devised to allow each counterparty to pay fees as they see fit, however, for instance for anchor outputs the commitment transaction has to be at the minimum relay feerate.
At times of high blockchain congestion, node operators may raise the minimum feerate they are willing to relay (in order to alleviate bandwidth use), which may prevent commitment transactions from being relayed; even if a CPFP were relayed later, since the parent transaction is not propagated in the first place, the CPFP transaction spending the anchor outputs cannot propagate too.

I believe that is what you are referring to here as an example of how an L2 protocol cannot rely on the current L1 network for timely confirmation?

> L2s would ideally need the tx relaying nodes to do more computation and lift their DOS mitigations for all miner-incentive-compatible transactions to eventually be relayed to most of the miners. One obvious instance of such a dilemma is the RBF rules.
> Such protocols getting increasingly developed and used create a strong incentive for their users/stakeholders to directly connect to mining pools [1], with all the consequences for the network mentioned in the replies to your mail and elsewhere.
> Before we get to this, i think there is a strong case for an opt-in and publicly accessible "overlay" network to relay miner-incentive compatible transactions with higher DOS limits. This way the cost is not imposed to L1 node runners, and L2s can operate with more safety assumptions without (entirely) falling for centralization.


Let us imagine how such a network would operate.

It seems to me that an issue here is that *relay is free*.

And: "you get what you pay for".
Since mere relay is free (i.e. nodes do not charge any fee to merely *relay* transactions) the quality of that relay is low.
Thus, L1 node operators may insist on policies that do not support well miner-incentive transaction packages.


So the question is: who should pay for relay?
Ultimately of course the transactor pays, but it seems to me that the direct payer should be miners; transactors would offer higher fees, and miners would then pay part of those fees to relayers to get those transactions.

So, perhaps, let us consider a sketch (which is probably impossible, but may trigger other ideas):


Ideally, a relayer system (whether a single node, or some cooperating/competing overlay network of nodes) would gather a bunch of transactions in a proposed package of high-paying transactions.
Miners then offer to pay the relayer contingent on learning such a package.

The miner wants:

* To be given proof, before paying, that the package:
  * Pays some certain value in fees.
  * Consist of valid transactions.
* To atomically get the actual package once they pay.

The relayer wants:

* To be paid when it reveals such a package of transaction.

Transactors want:

* Fees to the relayer to be included as part of the mining fees in their transaction.


The flow would be something like this:

* A transactor has a group of transactions it wants confirmed.
* It goes to some relayer and feeds the transactions to them.
* The relayer figures out the most lucrative package (a task that may be NP-hard?  Knapsack problem equivalent?).
* Miners look for relayers who have figured out the most lucrative next package.
* Miners pick the best package and pay for the package.
* Miners compete on mining.

The issues are:

* We need some way to prove that a bunch of transactions are valid, without showing the actual transactions.
  * Maybe part of Utreexo or similar concepts can be used?
* We need some way to prove that a bunch of transactions pays some fee.
  * Again, Utreexo?  Maybe?  Probably not?
  * Fees = inputs - outputs, so the delta between the input UTXO set and the output UTXO set should be the fee, how do we prove that?
* We need some way to actually get the actual transaction data contingent on some PTLC or HTLC.


Hmm.
Thoughts?

Regards,
ZmnSCPxj