Published on: 2015-11-12T21:26:38+00:00
The conversation on the bitcoin-dev mailing list focuses on the challenges of maintaining mining policy while also allowing priority-based transactions in a limited mempool world. One of the examples discussed is issue #6992, which recently closed. Another issue highlighted is #6357, which raises concerns about potential logic breaking in future changes. It is suggested that unit tests could address this concern. The usefulness and complexity of free transactions and rebroadcasting them if they are still in memory pools are also debated.In another conversation between Jorge Timón and Luke Dashjr, the use of starting priority in the mining code is discussed. Luke argues that it should be optional, while Jorge believes that maintaining the current priority algorithm is not expensive. The default block priority size is also debated, with Luke objecting to changing defaults as it could influence miner policy. However, he agrees that priority is currently the best metric for ensuring legitimate transactions get mined despite spam attacks.On November 12, 2015, the bitcoin-dev mailing list discusses the implementation of mining code and the block priority size. Luke suggests that starting priority should be optional for ease of implementation, while the default block priority size should be set to 0. Matt agrees with the former but disagrees with changing defaults as it could influence miner policy. The idea of merging priority, feerate, and sigoprate into one number is proposed by Chun Wang, with some members supporting customizable cost and reward. The main issue raised is that priority is not integrated into the reward function and changing it may slow down other improvements in mempool limits.The Bitcoin network is facing issues with mempool bloating and GBT latency due to the priority space. Free transactions are not getting mined and cleared from the mempool anymore. To prevent mempool size increase during a spam attack, setting minrelaytxfee=0.0001 is not enough; limitfreerelay=0 is also necessary to prevent GBT latency degradation. However, spammers generally cannot use the priority space, and it is an important way for legitimate users to have their transactions processed cheaply despite ongoing spam attempts.In a conversation with Chun Wang, Luke expresses confusion regarding Chun's statement that the priority space is "always the best place for spam nowadays." Luke argues that spammers generally cannot use the priority space and that it is actually beneficial for legitimate users. He asks Chun to explain their reasoning behind the statement.Email exchanges between Matt Corallo and Luke Dashjr discuss proposed changes for Bitcoin version 0.12. Matt mentions disabling high-priority relay when mempools are full and agrees to use starting priority in mining code for ease of implementation. However, Luke disagrees with changing defaults and suggests changing the priority size to 0 instead, which he believes is the best place for spam. He also proposes merging priority, feerate, and sigoprate into one number. The discussion revolves around finding the right balance between maintaining mining policy and preserving the ability for priority-based transactions.During an IRC meeting, the focus is on handling the old "transaction priority" feature in Bitcoin version 0.12. There is an agreement that it will either be removed or replaced with something less costly to maintain in the future. With mempool limiting already implemented, high-priority relay is disabled when mempools are full. For version 0.12, the mining code will use starting priority for ease of implementation, the default block priority size will be set to 0, and the wallet will no longer create 0-fee transactions when mempool limiting is in effect. Users are advised to exercise caution when relying on priority to mine their transactions and analyze previous blocks to ensure their transactions will be relayed.
Updated on: 2023-08-01T16:50:20.604277+00:00