{"type":"rich","version":"1.0","author_name":"npub1ghl954l59wm5pnv8j2y0ymmp6dt70kx2037e06wavfut7gjh68hqdgc6pd","author_url":"https://nostr.ae/npub1ghl954l59wm5pnv8j2y0ymmp6dt70kx2037e06wavfut7gjh68hqdgc6pd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-01-28\n📝 Original message:As you point out, depending on the mempool, sometimes a miner makes more\nfee by including A and B, while other times a miner makes more fee by\nincluding C (the replacement for A and B) and D (a hypothetical transaction\nthat cannot be fit into a block that contains A and B but can be fit into a\nblock with C.\n\nSo what are we to make of this? Is it better to relay C or better to not\nrelay C?\n\nClearly it is better for the miner if they know about C, because knowing\nabout C costs them nothing, but not knowing about C will sometimes result\nin them earning less fees.\n\nClearly it is better for the people who are creating C for those\ntransactions to be mined instead of the more expensive A and B transactions.\n\nEveryone else is better off in that more transactions would get included in\nblocks.\n\nA concern about burdening full nodes with extra transactions to relay that\nmay not be more profitable to mine than the transactions they replace is\nstill rational -- though intuitively it seems like there would be a limit\non how many times an attacker could cheaply reorganize transactions into\nsomething with a higher fee rate.\n\nPerhaps there are also concerns with reconstruction of blocks from compact\nblocks, given that miners would have more decisions to make about which tx\nto include?\n\n\n\nOn Sun, Jan 28, 2018 at 12:29 PM, David A. Harding via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Sun, Jan 28, 2018 at 05:43:34PM +0100, Sjors Provoost via bitcoin-dev\n\u003e wrote:\n\u003e \u003e Peter Todd wrote:\n\u003e \u003e \u003e In fact I considered only requiring an increase in fee rate, based on\n\u003e the\n\u003e \u003e \u003e theory that if absolute fee went down, the transaction must be smaller\n\u003e and thus\n\u003e \u003e \u003e miners could overall earn more from the additional transactions they\n\u003e could fit\n\u003e \u003e \u003e into their block. But to do that properly requires considering whether\n\u003e or not\n\u003e \u003e \u003e that's actually true in the particular state the mempool as a whole\n\u003e happens to\n\u003e \u003e \u003e be in, so I ditched that idea early on for the much simpler criteria\n\u003e of both a\n\u003e \u003e \u003e feerate and absolute fee increase.\n\u003e \u003e\n\u003e \u003e Why would you need to consider the whole mempool?\n\u003e\n\u003e Imagine a miner is only concerned with creating the next block and his\n\u003e mempool currently only has 750,000 vbytes in it.  If two 250-vbyte\n\u003e transactions each paying a feerate of 100 nanobitcoins per vbyte (50k\n\u003e total) are replaced with one 325-vbyte transaction paying a feerate of\n\u003e 120 nBTC (39k total), the miner's potential income from mining the next\n\u003e block is reduced by 11k nBTC.\n\u003e\n\u003e Moving away from this easily worked example, the problem can still exist\n\u003e even if a miner has enough transactions to fill the next block.  For\n\u003e replacement consideration only by increased feerate to be guaranteed\n\u003e more profitable, one has to assume the mempool contains an effectively\n\u003e continuous distribution of feerates.  That may one day be true of the\n\u003e mempool (it would be good, because it helps keep block production\n\u003e regular sans subsidy) but it's often not the case these days.\n\u003e\n\u003e -Dave\n\u003e\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\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180128/3c990f38/attachment.html\u003e"}