From: darosior <darosior@protonmail•com>
To: lisa neigut <niftynei@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
Date: Tue, 26 Oct 2021 14:09:28 +0000 [thread overview]
Message-ID: <Opd1OVGiyYCh2nGyCF1WbAozszMGHZSXiiC4cxN80cuIGS8TLzfzDjzcGulIOZDrq1bffF_UV6DO4QPFq1jmMY9UI0g5baUZMjWoeFqQvtM=@protonmail.com> (raw)
In-Reply-To: <CAM1a7P04apCwwmqNp4VLRam5_uk59tVRWv74UVD_g0-DUGNghw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5764 bytes --]
Hi Niftynei,
I share the concerns raised about direct connections to mining pools being a centralization pressure: de-anonymization and an inevitable higher barrier to entry. Making it more difficult to reach smaller miners is another one.
Regarding fee estimation you state:
> Initial feerate estimation would need to be based on published blocks, not pending transactions (as this information would no longer be available)
The current fee estimation algorithm uses both, not only the pending transactions (game-able). Although i agree that past-block(s) based fee estimation isn't that bad, it's worth mentioning that not tracking the confirmation time of relayed transactions drops the ability to have a target in the estimation. That is it's good enough for time-sensitive transactions where you always target the next block but not for other usages which usually target a few dozen of blocks in the future.
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)
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.
Thanks for publicly starting this discussion,
Antoine
[0] Using "L2s" for the sake of brevety, whatever it means i mean "protocols using pre-signed Bitcoin transactions which timely confirmation might be a security requirement".
[1] Wen block space insurance contracts
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le mardi 26 octobre 2021 à 4:56 AM, lisa neigut via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> a écrit :
> Hi all,
>
> In a recent conversation with @glozow, I had the realization that the mempool is obsolete and should be eliminated.
>
> Instead, users should submit their transactions directly to mining pools, preferably over an anonymous communication network such as tor. This can easily be achieved by mining pools running a tor onion node for this express purpose (or via a lightning network extension etc)
>
> Mempools make sense in a world where mining is done by a large number of participating nodes, eg where the block template is constructed by a majority of the participants on the network. In this case, it is necessary to socialize pending transaction data to all participants, as you don’t know which participant will be constructing the winning block template.
>
> In reality however, mempool relay is unnecessary where the majority of hashpower and thus block template creation is concentrated in a semi-restricted set.
>
> Removing the mempool would greatly reduce the bandwidth requirement for running a node, keep intentionality of transactions private until confirmed/irrevocable, and naturally resolve all current issues inherent in package relay and rbf rules. It also resolves the recent minimum relay questions, as relay is no longer a concern for unmined transactions.
>
> Provided the number of block template producing actors remains beneath, say 1000, it’d be quite feasible to publish a list of tor endpoints that nodes can independently + directly submit their transactions to. In fact, merely allowing users to select their own list of endpoints to use alternatively to the mempool would be a low effort starting point for the eventual replacement.
>
> On the other hand, removing the mempool would greatly complicate solo mining and would also make BetterHash proposals, which move the block template construction away from a centralized mining pool back to the individual miner, much more difficult. It also makes explicit the target for DoS attacks.
>
> A direct communication channel between block template construction venues and transaction proposers also provides a venue for direct feedback wrt acceptable feerates at the time, which both makes transaction confirmation timelines less variable as well as provides block producers a mechanism for (independently) enforcing their own minimum security budget. In other words, expressing a minimum acceptable feerate for continued operation.
>
> Initial feerate estimation would need to be based on published blocks, not pending transactions (as this information would no longer be available), or from direct interactions with block producers.
>
> ~niftynei
[-- Attachment #2: Type: text/html, Size: 6781 bytes --]
next prev parent reply other threads:[~2021-10-26 14:09 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 [this message]
2021-10-26 16:38 ` ZmnSCPxj
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='Opd1OVGiyYCh2nGyCF1WbAozszMGHZSXiiC4cxN80cuIGS8TLzfzDjzcGulIOZDrq1bffF_UV6DO4QPFq1jmMY9UI0g5baUZMjWoeFqQvtM=@protonmail.com' \
--to=darosior@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--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