Date: Tue, 26 Oct 2021 16:38:27 +0000
To: darosior <darosior@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <9_2myR-nlP12e_UV4y5HTY8vLzvFirBNZSnNh4kiYP9BTvvHaByALKV1D5kl2BqTyexYYtmVbBZ1xLPYgtbTp-nNsfXEzc1ZlNN8wMGeiVg=@protonmail.com>
In-Reply-To: <Opd1OVGiyYCh2nGyCF1WbAozszMGHZSXiiC4cxN80cuIGS8TLzfzDjzcGulIOZDrq1bffF_UV6DO4QPFq1jmMY9UI0g5baUZMjWoeFqQvtM=@protonmail.com>
References: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
 <Opd1OVGiyYCh2nGyCF1WbAozszMGHZSXiiC4cxN80cuIGS8TLzfzDjzcGulIOZDrq1bffF_UV6DO4QPFq1jmMY9UI0g5baUZMjWoeFqQvtM=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: lisa neigut <niftynei@gmail.com>
Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
Precedence: list


Good morning Antoine,

> However, as we discussed recently, i do believe their is a failure mode h=
ere. On one hand, directly connecting to pools is already possible today an=
d pretty effective given the current mining centralization. On the other ha=
nd, it's not possible for most pre-signed txs protocols to reliably (secure=
ly) use the Bitcoin tx relay network today to propagate time-sensitive tran=
sactions. Furthermore, even if these are fixed (eg via package-relay for (t=
oday'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 (m=
ake 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 counte=
rparties (whose incentives may not align perfectly) can bid to put their vi=
ews of the L2 state on the blockchain.
For instance, in Lightning, you may wish to close a channel at a high feera=
te in order to use your onchain funds quickly, yet your channel counterpart=
y 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 counterpar=
ty to pay fees as they see fit, however, for instance for anchor outputs th=
e commitment transaction has to be at the minimum relay feerate.
At times of high blockchain congestion, node operators may raise the minimu=
m feerate they are willing to relay (in order to alleviate bandwidth use), =
which may prevent commitment transactions from being relayed; even if a CPF=
P were relayed later, since the parent transaction is not propagated in the=
 first place, the CPFP transaction spending the anchor outputs cannot propa=
gate 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 l=
ift their DOS mitigations for all miner-incentive-compatible transactions t=
o 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 in=
centive for their users/stakeholders to directly connect to mining pools [1=
], with all the consequences for the network mentioned in the replies to yo=
ur mail and elsewhere.
> Before we get to this, i think there is a strong case for an opt-in and p=
ublicly accessible "overlay" network to relay miner-incentive compatible tr=
ansactions with higher DOS limits. This way the cost is not imposed to L1 n=
ode runners, and L2s can operate with more safety assumptions without (enti=
rely) 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 min=
er-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 direc=
t payer should be miners; transactors would offer higher fees, and miners w=
ould then pay part of those fees to relayers to get those transactions.

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


Ideally, a relayer system (whether a single node, or some cooperating/compe=
ting overlay network of nodes) would gather a bunch of transactions in a pr=
oposed 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 tr=
ansaction.


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 pac=
kage.
* 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 =3D 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 o=
n some PTLC or HTLC.


Hmm.
Thoughts?

Regards,
ZmnSCPxj