darosior [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-26 📝 Original message:Hi Niftynei, I share the ...
📅 Original date posted:2021-10-26
📝 Original message: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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211026/d151987f/attachment.html>;
📝 Original message: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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211026/d151987f/attachment.html>;