eric at voskuil.org [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2020-12-01 to 2022-10-10
💬 Posted a total of 27 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:00:18 UTC

- reply

📅 Original date posted:2021-10-26
📝 Original message:Agree ZmnSCPxj
Hi lisa,
I'm all for removing it from memory. :) Did that a while ago. We just call it the transaction pool.
There will always be unconfirmed transactions floating around (even just from reorgs). Best to store them somewhere. Disk is cheap, block distribution (e.g. compact) works better if you have them already prevalidated, even if you aren't going to mine on them.
How you get them technically is not so important. There will always be a set of unconfirmed transactions, it's conceptual. But above all, anonymity is very important - on both ends. This is why transactions have integral fees. Anyone can get paid to mine, just need the txs.
Mining may be semi-restricted set is today, it may not be tomorrow. Imagine China everywhere, just like financial controls already are. That's when you see what Bitcoin can do from a security standpoint.
Treating miners as someone else is a poor security architecture. Everyone should look like a potential miner on the network, and a potential spender.
I think you are thinking of it a bit backwards. A node is a big pool of connected transactions. Block headers come along occasionally, and impose order on a subset of them.
e
> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces at lists.linuxfoundation.org> On Behalf
> Of ZmnSCPxj via bitcoin-dev
> Sent: Tuesday, October 26, 2021 1:02 AM
> To: lisa neigut <niftynei at gmail.com>; Bitcoin Protocol Discussion <bitcoin-
> dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool
>
>
> Good morning lisa,
>
> > 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.
>
> Unfortunately, this requires that miners have a persistent identity by which
> they can be contacted.
> While pseudonymity is possible, we all know that in practice, it can be easily
> pierced.
> For instance, consider that the injunction against address reuse is a
> recognition that a persistent pseudonym is a privacy leak.
>
> Ideally, the mining set should be as anonymous as possible, as some attacks
> are possible with sufficient hashpower, and making the miners keep a
> persistent identity by which they can be found may enable easier state co-
> option of mines.
> The strongest man on Earth cannot destroy his enemy if he does not know
> who and where his enemy is; so with enemies of Bitcoin and the miners of
> Bitcoin.
> (granted, near every darned mining pool self-identifies, sigh, wtf)
>
> Ideally, the set of relaying nodes hides the miners.
> Of course, in practice we can have a good guess of which relaying nodes are
> miners and which are not -- those who get blocks earlier are probably miners.
> Against this, we should note that this method of identification is probabilistic
> and not absolute (whereas miners advertising their services so they can be
> contacted and given unconfirmed transactions are a *definite* flag "I am a
> miner").
> And there is always the chance, however slim, that some node that has not
> been getting blocks "early" suddenly decides to buy a mining rig and start
> mining.
>
> In short: what you propose is to switch to side fee markets (as I understand it).
> Non-side fees are simply an anonymity layer, by which neither the miner nor
> the transactor need to know the identity of each other, they simply broadcast
> to the wider world.
> This anonymity layer remains important, however, as they help maintain the
> fee market: https://github.com/libbitcoin/libbitcoin-system/wiki/Side-Fee-
> Fallacy
>
>
> Ultimately, my objection here is simply that this requires miners to identify
> themselves.
> In practice, miners already identify themselves (even though they really,
> really should not), so this objection may be moot at this point.
>
> (Not to mention: something like P2Pool, as-is, would not work well in that
> model; you would need to implement a mempool for those as well)
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev