{"type":"rich","version":"1.0","title":"darosior [ARCHIVE] wrote","author_name":"darosior [ARCHIVE] (npub1pj…x22xp)","author_url":"https://yabu.me/npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2022-02-18\n📝 Original message:James,\n\nYou seem to imply that the scenario described isn't prevented today. It is. The mempool acceptance for a replacement not only\ndepend on the transaction feerate but also the transaction fee [0]. That's why i raised it in the first place...\n\nAntoine\n\n[0] https://github.com/bitcoin/bitcoin/blob/66636ca438cb65fb18bcaa4540856cef0cee2029/src/validation.cpp#L944-L947\n\nOf course if you are evicting transactions then you don't have the issue i mentioned, so it's fine doing so.\n-------- Original Message --------\nOn Feb 17, 2022, 19:18, James O'Beirne \u003c james.obeirne at gmail.com\u003e wrote:\n\n\u003e\u003e Is it really true that miners do/should care about that?\n\u003e\n\u003e De facto, any miner running an unmodified version of bitcoind doesn't\n\u003e care about anything aside from ancestor fee rate, given that the\n\u003e BlockAssembler as-written orders transactions for inclusion by\n\u003e descending ancestor fee-rate and then greedily adds them to the block\n\u003e template. [0]\n\u003e\n\u003e If anyone has any indication that there are miners running forks of\n\u003e bitcoind that change this behavior, I'd be curious to know it.\n\u003e\n\u003e Along the lines of what AJ wrote, optimal transaction selection is\n\u003e NP-hard (knapsack problem). Any time that a miner spends deciding how\n\u003e to assemble the next block is time not spent grinding on the nonce, and\n\u003e so I'm skeptical that miners in practice are currently doing anything\n\u003e that isn't fast and simple like the default implementation: sorting\n\u003e fee-rate in descending order and then greedily packing.\n\u003e\n\u003e But it would be interesting to hear evidence to the contrary.\n\u003e\n\u003e ---\n\u003e\n\u003e You can make the argument that transaction selection is just a function\n\u003e of mempool contents, and so mempool maintenance criteria might be the\n\u003e thing to look at. Mempool acceptance is gated based on a minimum\n\u003e feerate[1]. Mempool eviction (when running low on space) happens on\n\u003e the basis of max(self_feerate, descendant_feerate) [2]. So even in the\n\u003e mempool we're still talking in terms of fee rates, not absolute fees.\n\u003e\n\u003e That presents us with the \"is/ought\" problem: just because the mempool\n\u003e *is* currently gating only on fee rate doesn't mean that's optimal. But\n\u003e if the whole point of the mempool is to hold transactions that will be\n\u003e mined, and if there's good reason that txns are chosen for mining based\n\u003e on fee rate (it's quick and good enough), then it seems like fee rate\n\u003e is the approximation that should ultimately prevail for txn\n\u003e replacement.\n\u003e\n\u003e [0]:\n\u003e https://github.com/bitcoin/bitcoin/blob/master/src/node/miner.cpp#L310-L320\n\u003e [1]:\n\u003e https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1106\n\u003e [2]:\n\u003e https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1138-L1144\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220218/1da83193/attachment.html\u003e"}