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