LORD HIS EXCELLENCY JAMES HRMH [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-27 📝 Original message:Good Afternoon, No. This ...
📅 Original date posted:2021-10-27
📝 Original message:Good Afternoon,
No. This has been discussed previously and eliminated as there is no proof that the transaction can exist without population through the mempool. As a method of payment not hearing about a transaction until it is possibly mined three months later as I have experienced is non-functional, there were discussions in this mailing list. The purpose of the mempool is not gossip it is gossip and any node technically can mine if they do.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
duigco.org DUIGCO API
and other projects
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this email if misdelivered.
________________________________
From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of lisa neigut via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Tuesday, 26 October 2021 1:56 PM
To: bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] death to the mempool, long live the mempool
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/20211027/e9782e39/attachment.html>;
📝 Original message:Good Afternoon,
No. This has been discussed previously and eliminated as there is no proof that the transaction can exist without population through the mempool. As a method of payment not hearing about a transaction until it is possibly mined three months later as I have experienced is non-functional, there were discussions in this mailing list. The purpose of the mempool is not gossip it is gossip and any node technically can mine if they do.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
duigco.org DUIGCO API
and other projects
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this email if misdelivered.
________________________________
From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of lisa neigut via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Sent: Tuesday, 26 October 2021 1:56 PM
To: bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] death to the mempool, long live the mempool
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/20211027/e9782e39/attachment.html>;