{"type":"rich","version":"1.0","title":"Antoine Riard [ARCHIVE] wrote","author_name":"Antoine Riard [ARCHIVE] (npub1vj…4x8dd)","author_url":"https://yabu.me/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2022-02-17\n📝 Original message:While I roughly agree with the thesis that different replacement policies\noffer marginal block reward gains _in the current state_ of the ecosystem,\nI would be more conservative about extending the conclusions to the\nmedium/long-term future.\n\n\u003e I suspect the \"economically rational\" choice would be to happily trade\n\u003e off that immediate loss against even a small chance of a simpler policy\n\u003e encouraging higher adoption of bitcoin, _or_ a small chance of more\n\u003e on-chain activity due to higher adoption of bitcoin protocols like\n\u003e lightning and thus a lower chance of an empty mempool in future.\n\nThis is making the assumption that the economic interests of the different\nclass of actors in the Bitcoin ecosystem are not only well-understood but\nalso aligned. We have seen in the past mining actors behaviors delaying the\nadoption of protocol upgrades which were expected to encourage higher\nadoption of Bitcoin. Further, if miners likely have an incentive to see an\nincrease of on-chain activity, there is also the possibility that lightning\nwill be so throughput-efficient to drain mempools backlog, to a point where\nthe block demand is not high enough to pay back the cost of mining hardware\nand operational infrastructure. Or at least not matching the return on\nmining investments expectations.\n\nOf course, it could be argued that as a utxo-sharing protocol like\nlightning just compresses the number of payments per block space unit, it\nlowers the fees burden, thus making Bitcoin as a payment system far more\nattractive for a wider population of users. In fine increasing the block\nspace demand and satisfying the miners.\n\nIn the state of today's knowledge, this hypothesis sounds the most\nplausible. Though, I would say it's better to be cautious until we\nunderstand better the interactions between the different layers of the\nBitcoin ecosystem ?\n\n\u003e Certainly those percentages can be expected to double every four years as\n\u003e the block reward halves (assuming we don't also reduce the min relay fee\n\u003e and block min tx fee), but I think for both miners and network stability,\n\u003e it'd be better to have the mempool backlog increase over time, which\n\u003e would both mean there's no/less need to worry about the special case of\n\u003e the mempool being empty, and give a better incentive for people to pay\n\u003e higher fees for quicker confirmations.\n\nIntuitively, if we assume that liquidity isn't free on lightning [0], there\nshould be a subjective equilibrium where it's cheaper to open new channels\nto reduce one's own graph traversal instead of paying too high routing fees.\n\nAs the core of the network should start to be more busy, I think we should\nsee more LN actors doing that kind of arbitrage, guaranteeing in the\nlong-term mempools backlog.\n\n\u003e If you really want to do that\n\u003e optimally, I think you have to have a mempool that retains conflicting\n\u003e txs and runs a dynamic programming solution to pick the best set, rather\n\u003e than today's simple greedy algorithms both for building the block and\n\u003e populating the mempool?\n\nAs of today, I think power efficiency of mining chips and access to\naffordable sources of energy are more significant factors of the\nrentability of mining operations rather than optimality of block\nconstruction/replacement policy. IMO, making the argument that small deltas\nin block reward gains aren't that much relevant.\n\nThat said, the former factors might become a commodity, and the latter one\nbecome a competitive advantage. It could incentivize the development of\nsuch greedy algorithms, potentially in a covert way as we have seen with\nAsicBoost ?\n\n\u003e Is there a plausible example where the difference isn't that marginal?\n\nThe paradigm might change in the future. If we see the deployment of\nchannel factories/payment pools, we might have users competing to spend a\nshared-utxo with different liquidity needs and thus ready to overbid. Lack\nof a \"conflict pool\" logic might make you lose income.\n\n\u003e Always accepting (package/descendent) fee rate increases removes the\npossibility of pinning entirely, I think\n\nI think the pinnings we're affected with today are due to the ability of a\nmalicious counterparty to halt the on-chain resolution of the channel. The\npresence of a  pinning commitment transaction with low-chance of\nconfirmation (abuse of BIP125 rule 3)\nprevents the honest counterparty to fee-bump her own version of the\ncommitment, thus redeeming a HTLC before timelock expiration. As long as\none commitment confirms, independently of who issued it, the pinning is\nover. I think moving to replace-by-feerate allows the honest counterparty\nto fee-bump her commitment, thus offering a compelling block space demand,\nor forces the malicious counterparty to enter in a fee race.\n\n\nTo gather my thinking on the subject, the replace-by-feerate policy could\nproduce lower fees blocks in the presence of today's environment of\nempty/low-fulfilled blocks. That said, the delta sounds marginal enough\nw.r.t other factors of mining business units\nto not be worried (or at least low-key) about the potential implications on\ncentralization. If the risk is perceived as too intolerable, it could be\nargued an intermediate solution would be to deploy a \"dual\" RBF policy\n(replace-by-fee for the top of the mempool, replace-by-feerate\nfor the remaining part).\n\nStill, I believe we might have to adopt more sophisticated replacement\npolicies in the long term to level the field among the mining ecosystem if\nblock construction/mempool acceptance strategies become a competitive\nfactor. Default to do so might provoke a latent centralization of mining\ndue to heterogeneity in the block reward offered. This heterogeneity would\nalso likely downgrade the safety of L2 nodes, as those actors wouldn't be\nable to know how to format their fee-bumpings, in the lack of _a_ mempool\nreplacement standard.\n\n\u003e Note that if we did have this policy, you could abuse it to cheaply drain\n\u003e people's mempools: if there was a 300MB backlog, you could publish 2980\n\u003e 100kB txs paying a fee rate just below the next block fee, meaning you'd\n\u003e kick out the previous backlog and your transactions take up all but the\n\u003e top 2MB of the mempool; if you then replace them all with perhaps 2980\n\u003e 100B txs paying a slightly higher fee rate, the default mempool will be\n\u003e left with only 2.3MB, at an ultimate cost to you of only about 30% of a\n\u003e block in fees, and you could then fill the mempool back up by spamming\n\u003e 300MB of ultra low fee rate txs.\n\nI believe we might have bandwidth-bleeding issues with our current\nreplacement policy. I think it would be good to have a cost estimate of\nthem and ensure a newer replacement policy would stay in the same bounds.\n\n\u003e I think spam prevention at the outbound relay level isn't enough to\n\u003e prevent that: an attacker could contact every public node and relay the\n\u003e txs directly, clearing out the mempool of most public nodes directly. So\n\u003e you'd want some sort of spam prevention on inbound txs too?\n\nThat we have to think about replacement spam prevention sounds reasonable\nto me. I would be worried about utxo-based replacement limitations which\ncould be abused in the context of multi-party protocol (introducing a new\npinning vector). One solution\ncould be to have a per-party transaction \"tag\" and allocate a replacement\nslot in function ? Maybe preventing a malicious counterparty to abuse a\n\"global\" utxo slot during periods of low fees...\n\nAntoine\n\n[0] https://twitter.com/alexbosworth/status/1476946257939628035\n\nLe jeu. 17 févr. 2022 à 09:32, Anthony Towns via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e On Thu, Feb 10, 2022 at 07:12:16PM -0500, Matt Corallo via bitcoin-dev\n\u003e wrote:\n\u003e \u003e This is where *all* the complexity comes from. If our goal is to \"ensure\n\u003e a\n\u003e \u003e bump increases a miner's overall revenue\" (thus not wasting relay for\n\u003e \u003e everyone else), then we precisely *do* need\n\u003e \u003e \u003e Special consideration for \"what should be in the next\n\u003e \u003e \u003e block\" and/or the caching of block templates seems like an imposing\n\u003e \u003e \u003e dependency\n\u003e \u003e Whether a transaction increases a miner's revenue depends precisely on\n\u003e \u003e whether the transaction (package) being replaced is in the next block -\n\u003e if\n\u003e \u003e it is, you care about the absolute fee of the package and its\n\u003e replacement.\n\u003e\n\u003e On Thu, Feb 10, 2022 at 11:44:38PM +0000, darosior via bitcoin-dev wrote:\n\u003e \u003e It's not that simple. As a miner, if i have less than 1vMB of\n\u003e transactions in my mempool. I don't want a 10sats/vb transaction paying\n\u003e 100000sats by a 100sats/vb transaction paying only 10000sats.\n\u003e\n\u003e Is it really true that miners do/should care about that?\n\u003e\n\u003e If you did this particular example, the miner would be losing 90k sats\n\u003e in fees, which would be at most 1.44 *millionths* of a percent of the\n\u003e block reward with the subsidy at 6.25BTC per block, even if there were\n\u003e no other transactions in the mempool. Even cumulatively, 10sats/vb over\n\u003e 1MB versus 100sats/vb over 10kB is only a 1.44% loss of block revenue.\n\u003e\n\u003e I suspect the \"economically rational\" choice would be to happily trade\n\u003e off that immediate loss against even a small chance of a simpler policy\n\u003e encouraging higher adoption of bitcoin, _or_ a small chance of more\n\u003e on-chain activity due to higher adoption of bitcoin protocols like\n\u003e lightning and thus a lower chance of an empty mempool in future.\n\u003e\n\u003e If the network has an \"empty mempool\" (say less than 2MvB-10MvB of\n\u003e backlog even if you have access to every valid 1+ sat/vB tx on any node\n\u003e connected to the network), then I don't think you'll generally have txs\n\u003e with fee rates greater than ~20 sat/vB (ie 20x the minimum fee rate),\n\u003e which means your maximum loss is about 3% of block revenue, at least\n\u003e while the block subsidy remains at 6.25BTC/block.\n\u003e\n\u003e Certainly those percentages can be expected to double every four years as\n\u003e the block reward halves (assuming we don't also reduce the min relay fee\n\u003e and block min tx fee), but I think for both miners and network stability,\n\u003e it'd be better to have the mempool backlog increase over time, which\n\u003e would both mean there's no/less need to worry about the special case of\n\u003e the mempool being empty, and give a better incentive for people to pay\n\u003e higher fees for quicker confirmations.\n\u003e\n\u003e If we accept that logic (and assuming we had some additional policy\n\u003e to prevent p2p relay spam due to replacement txs), we could make\n\u003e the mempool accept policy for replacements just be (something like)\n\u003e \"[package] feerate is greater than max(descendent fee rate)\", which\n\u003e seems like it'd be pretty straightforward to deal with in general?\n\u003e\n\u003e\n\u003e\n\u003e Thinking about it a little more; I think the decision as to whether\n\u003e you want to have a \"100kvB at 10sat/vb\" tx or a conflicting \"1kvB at\n\u003e 100sat/vb\" tx in your mempool if you're going to take into account\n\u003e unrelated, lower fee rate txs that are also in the mempool makes block\n\u003e building \"more\" of an NP-hard problem and makes the greedy solution\n\u003e we've currently got much more suboptimal -- if you really want to do that\n\u003e optimally, I think you have to have a mempool that retains conflicting\n\u003e txs and runs a dynamic programming solution to pick the best set, rather\n\u003e than today's simple greedy algorithms both for building the block and\n\u003e populating the mempool?\n\u003e\n\u003e For example, if you had two such replacements come through the network,\n\u003e a miner could want to flip from initially accepting the first replacement,\n\u003e to unaccepting it:\n\u003e\n\u003e Initial mempool: two big txs at 100k each, many small transactions at\n\u003e 15s/vB and 1s/vB\n\u003e\n\u003e  [100kvB at 20s/vB] [850kvB at 15s/vB] [100kvB at 12s/vB] [1000kvB at\n\u003e 1s/vB]\n\u003e    -\u003e 0.148 BTC for 1MvB (100*20 + 850*15 + 50*1)\n\u003e\n\u003e Replacement for the 20s/vB tx paying a higher fee rate but lower total\n\u003e fee; that's worth including:\n\u003e\n\u003e  [10kvB at 100s/vB] [850kvB at 15s/vB] [100kvB at 12s/vB [1000kvB at 1s/vB]\n\u003e    -\u003e 0.1499 BTC for 1MvB (10*100 + 850*15 + 100*12 + 40*1)\n\u003e\n\u003e Later, replacement for the 12s/vB tx comes in, also paying higher fee\n\u003e rate but lower total fee. Worth including, but only if you revert the\n\u003e original replacement:\n\u003e\n\u003e  [100kvB at 20s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [1000kvB at 1s/vB]\n\u003e    -\u003e 0.16 BTC for 1MvB (150*20 + 850*15)\n\u003e\n\u003e  [10kvB at 100s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [1000kvB at 1s/vB]\n\u003e    -\u003e 0.1484 BTC for 1MvB (10*100 + 50*20 + 850*15 + 90*1)\n\u003e\n\u003e Algorithms/mempool policies you might have, and their results with\n\u003e this example:\n\u003e\n\u003e  * current RBF rules: reject both replacements because they don't\n\u003e    increase the absolute fee, thus get the minimum block fees of\n\u003e    0.148 BTC\n\u003e\n\u003e  * reject RBF unless it increases the fee rate, and get 0.1484 BTC in\n\u003e    fees\n\u003e\n\u003e  * reject RBF if it's lower fee rate or immediately decreases the block\n\u003e    reward: so, accept the first replacement, but reject the second,\n\u003e    getting 0.1499 BTC\n\u003e\n\u003e  * only discard a conflicting tx when it pays both a lower fee rate and\n\u003e    lower absolute fees, and choose amongst conflicting txs optimally\n\u003e    via some complicated tx allocation algorithm when generating a block,\n\u003e    and get 0.16 BTC\n\u003e\n\u003e In this example, those techniques give 92.5%, 92.75%, 93.69% and 100% of\n\u003e total possible fees you could collect; and 99.813%, 99.819%, 99.84% and\n\u003e 100% of the total possible block reward at 6.25BTC/block.\n\u003e\n\u003e Is there a plausible example where the difference isn't that marginal?\n\u003e Seems like the simplest solution of just checking the (package/descendent)\n\u003e fee rate increases works well enough here at least.\n\u003e\n\u003e If 90kvB of unrelated txs at 14s/vB were then added to the mempool, then\n\u003e replacing both txs becomes (just barely) optimal, meaning the smartest\n\u003e possible algorithm and the dumbest one of just considering the fee rate\n\u003e produce the same result, while the others are worse:\n\u003e\n\u003e  [10kvB at 100s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB]\n\u003e    -\u003e 0.1601 BTC for 1MvB\n\u003e    (accepting both)\n\u003e\n\u003e  [100kvB at 20s/vB] [50kvB at 20s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB]\n\u003e    -\u003e 0.1575 BTC for 1MvB\n\u003e    (accepting only the second replacement)\n\u003e\n\u003e  [10kvB at 100s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB] [100kvB at 12s/vB]\n\u003e    -\u003e 0.1551 BTC for 1MvB\n\u003e    (first replacement only, optimal tx selection: 10*100, 850*15, 50*14,\n\u003e 100*12)\n\u003e\n\u003e  [100kvB at 20s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB] [100kvB at 12s/vB]\n\u003e    -\u003e 0.1545 BTC for 1MvB\n\u003e    (accepting neither replacement)\n\u003e\n\u003e  [10kvB at 100s/vB] [850kvB at 15s/vB] [90kvB at 14s/vB] [100kvB at 12s/vB]\n\u003e    -\u003e 0.1506 BTC for 1MvB\n\u003e    (first replacement only, greedy tx selection: 10*100, 850*15, 90*14,\n\u003e 50*1)\n\u003e\n\u003e Always accepting (package/descendent) fee rate increases removes the\n\u003e possibility of pinning entirely, I think -- you still have the problem\n\u003e where someone else might get a conflicting transaction confirmed first,\n\u003e but they can't get a conflicting tx stuck in the mempool without\n\u003e confirming if you're willing to pay enough to get it confirmed.\n\u003e\n\u003e\n\u003e\n\u003e Note that if we did have this policy, you could abuse it to cheaply drain\n\u003e people's mempools: if there was a 300MB backlog, you could publish 2980\n\u003e 100kB txs paying a fee rate just below the next block fee, meaning you'd\n\u003e kick out the previous backlog and your transactions take up all but the\n\u003e top 2MB of the mempool; if you then replace them all with perhaps 2980\n\u003e 100B txs paying a slightly higher fee rate, the default mempool will be\n\u003e left with only 2.3MB, at an ultimate cost to you of only about 30% of a\n\u003e block in fees, and you could then fill the mempool back up by spamming\n\u003e 300MB of ultra low fee rate txs.\n\u003e\n\u003e I think spam prevention at the outbound relay level isn't enough to\n\u003e prevent that: an attacker could contact every public node and relay the\n\u003e txs directly, clearing out the mempool of most public nodes directly. So\n\u003e you'd want some sort of spam prevention on inbound txs too?\n\u003e\n\u003e So I think you'd need to carefully think about relay spam before making\n\u003e this sort of change.  Also, if we had tx rebroadcast implemented then\n\u003e having just a few nodes with large mempools might allow the network to\n\u003e recover from this situation automatically.\n\u003e\n\u003e Cheers,\n\u003e aj\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220217/b4aa2987/attachment-0001.html\u003e"}