From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: darosior <darosior@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: lisa neigut <niftynei@gmail•com>
Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
Date: Tue, 26 Oct 2021 16:38:27 +0000 [thread overview]
Message-ID: <9_2myR-nlP12e_UV4y5HTY8vLzvFirBNZSnNh4kiYP9BTvvHaByALKV1D5kl2BqTyexYYtmVbBZ1xLPYgtbTp-nNsfXEzc1ZlNN8wMGeiVg=@protonmail.com> (raw)
In-Reply-To: <Opd1OVGiyYCh2nGyCF1WbAozszMGHZSXiiC4cxN80cuIGS8TLzfzDjzcGulIOZDrq1bffF_UV6DO4QPFq1jmMY9UI0g5baUZMjWoeFqQvtM=@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
next prev parent reply other threads:[~2021-10-26 16:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-26 2:56 lisa neigut
2021-10-26 8:02 ` ZmnSCPxj
2021-10-26 8:31 ` eric
2021-10-26 8:56 ` ZmnSCPxj
2021-10-26 14:09 ` darosior
2021-10-26 16:38 ` ZmnSCPxj [this message]
2021-10-26 16:26 ` Pieter Wuille
2021-10-26 18:16 ` Gloria Zhao
2021-10-28 1:04 ` ZmnSCPxj
2021-11-03 10:12 ` ZmnSCPxj
2021-10-26 23:44 ` Antoine Riard
2021-10-27 20:01 ` Peter Todd
2021-10-27 8:44 ` LORD HIS EXCELLENCY JAMES HRMH
2021-10-27 23:05 ` yanmaani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='9_2myR-nlP12e_UV4y5HTY8vLzvFirBNZSnNh4kiYP9BTvvHaByALKV1D5kl2BqTyexYYtmVbBZ1xLPYgtbTp-nNsfXEzc1ZlNN8wMGeiVg=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=darosior@protonmail$(echo .)com \
--cc=niftynei@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox