{"type":"rich","version":"1.0","title":"eric at voskuil.org [ARCHIVE] wrote","author_name":"eric at voskuil.org [ARCHIVE] (npub1r3…6s8vu)","author_url":"https://yabu.me/npub1r34khxrz9w39zpzezymqz04dcel95adfxf6qpjul9wdv2qn5vtps06s8vu","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-10-26\n📝 Original message:Agree ZmnSCPxj\n\nHi lisa,\n\nI'm all for removing it from memory. :) Did that a while ago. We just call it the transaction pool.\n\nThere 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.\n\nHow 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.\n\nMining 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.\n\nTreating miners as someone else is a poor security architecture. Everyone should look like a potential miner on the network, and a potential spender.\n\nI 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.\n\ne\n\n\u003e -----Original Message-----\n\u003e From: bitcoin-dev \u003cbitcoin-dev-bounces at lists.linuxfoundation.org\u003e On Behalf\n\u003e Of ZmnSCPxj via bitcoin-dev\n\u003e Sent: Tuesday, October 26, 2021 1:02 AM\n\u003e To: lisa neigut \u003cniftynei at gmail.com\u003e; Bitcoin Protocol Discussion \u003cbitcoin-\n\u003e dev at lists.linuxfoundation.org\u003e\n\u003e Subject: Re: [bitcoin-dev] death to the mempool, long live the mempool\n\u003e \n\u003e \n\u003e Good morning lisa,\n\u003e \n\u003e \u003e Hi all,\n\u003e \u003e\n\u003e \u003e In a recent conversation with @glozow, I had the realization that the\n\u003e mempool is obsolete and should be eliminated.\n\u003e \u003e\n\u003e \u003e Instead, users should submit their transactions directly to mining pools,\n\u003e preferably over an anonymous communication network such as tor. This can\n\u003e easily be achieved by mining pools running a tor onion node for this express\n\u003e purpose (or via a lightning network extension etc)\n\u003e \u003e\n\u003e \u003e Mempools make sense in a world where mining is done by a large number\n\u003e of participating nodes, eg where the block template is constructed by a\n\u003e majority of the participants on the network. In this case, it is necessary to\n\u003e socialize pending transaction data to all participants, as you don’t know which\n\u003e participant will be constructing the winning block template.\n\u003e \u003e\n\u003e \u003e In reality however, mempool relay is unnecessary where the majority of\n\u003e hashpower and thus block template creation is concentrated in a semi-\n\u003e restricted set.\n\u003e \u003e\n\u003e \u003e Removing the mempool would greatly reduce the bandwidth requirement\n\u003e for running a node, keep intentionality of transactions private until\n\u003e confirmed/irrevocable, and naturally resolve all current issues inherent in\n\u003e package relay and rbf rules. It also resolves the recent minimum relay\n\u003e questions, as relay is no longer a concern for unmined transactions.\n\u003e \u003e\n\u003e \u003e Provided the number of block template producing actors remains beneath,\n\u003e say 1000, it’d be quite feasible to publish a list of tor endpoints that nodes can\n\u003e independently  + directly submit their transactions to. In fact, merely allowing\n\u003e users to select their own list of endpoints to use alternatively to the mempool\n\u003e would be a low effort starting point for the eventual replacement.\n\u003e \u003e\n\u003e \u003e On the other hand, removing the mempool would greatly complicate solo\n\u003e mining and would also make BetterHash proposals, which move the block\n\u003e template construction away from a centralized mining pool back to the\n\u003e individual miner, much more difficult. It also makes explicit the target for DoS\n\u003e attacks.\n\u003e \n\u003e Unfortunately, this requires that miners have a persistent identity by which\n\u003e they can be contacted.\n\u003e While pseudonymity is possible, we all know that in practice, it can be easily\n\u003e pierced.\n\u003e For instance, consider that the injunction against address reuse is a\n\u003e recognition that a persistent pseudonym is a privacy leak.\n\u003e \n\u003e Ideally, the mining set should be as anonymous as possible, as some attacks\n\u003e are possible with sufficient hashpower, and making the miners keep a\n\u003e persistent identity by which they can be found may enable easier state co-\n\u003e option of mines.\n\u003e The strongest man on Earth cannot destroy his enemy if he does not know\n\u003e who and where his enemy is; so with enemies of Bitcoin and the miners of\n\u003e Bitcoin.\n\u003e (granted, near every darned mining pool self-identifies, sigh, wtf)\n\u003e \n\u003e Ideally, the set of relaying nodes hides the miners.\n\u003e Of course, in practice we can have a good guess of which relaying nodes are\n\u003e miners and which are not -- those who get blocks earlier are probably miners.\n\u003e Against this, we should note that this method of identification is probabilistic\n\u003e and not absolute (whereas miners advertising their services so they can be\n\u003e contacted and given unconfirmed transactions are a *definite* flag \"I am a\n\u003e miner\").\n\u003e And there is always the chance, however slim, that some node that has not\n\u003e been getting blocks \"early\" suddenly decides to buy a mining rig and start\n\u003e mining.\n\u003e \n\u003e In short: what you propose is to switch to side fee markets (as I understand it).\n\u003e Non-side fees are simply an anonymity layer, by which neither the miner nor\n\u003e the transactor need to know the identity of each other, they simply broadcast\n\u003e to the wider world.\n\u003e This anonymity layer remains important, however, as they help maintain the\n\u003e fee market: https://github.com/libbitcoin/libbitcoin-system/wiki/Side-Fee-\n\u003e Fallacy\n\u003e \n\u003e \n\u003e Ultimately, my objection here is simply that this requires miners to identify\n\u003e themselves.\n\u003e In practice, miners already identify themselves (even though they really,\n\u003e really should not), so this objection may be moot at this point.\n\u003e \n\u003e (Not to mention: something like P2Pool, as-is, would not work well in that\n\u003e model; you would need to implement a mempool for those as well)\n\u003e \n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}