BIP Proposal: Revised: UTPFOTIB - Use Transaction Priority For Ordering Transactions In Blocks



Summary:

In a Bitcoin Protocol Discussion, a BIP proposal was put forward to address the issue of transaction bandwidth limit and ensure that all valid transactions are eventually included in the blockchain. The proposed system changes the way miners calculate transaction priority so that an old transaction can be worth just as much as any new transaction coming later on. This ensures that older transactions with high enough thresholds will not be left unconfirmed. However, some argued that this system has flaws, and there is currently no known system that works as well as the current one.The issue of transactional reliability due to the transaction bandwidth limit approaching its threshold was also discussed. The proposal involves a hard fork scenario and has technical issues to resolve in implementation. It suggests using a fixed fee per block, calculated as the average of the amount transactions are prepared to pay in the last 1000 blocks, to make it easier to include all transactions eventually. The proposal faced critiques such as every node having a different mempool, which cannot be used to decide consensus values like the max block size. Additionally, the proposal asks miners to ignore their best interests and confirm transactions by "priority," which may not be incentive compatible. Furthermore, the proposal explicitly requires validating the commitment to the mempool properties, making mempool become a consensus critical, which is impossible.Damian Williamson, in an email to the bitcoin-dev mailing list, has proposed a revised BIP (Bitcoin Improvement Proposal) aimed at addressing transaction bandwidth limitations and improving Bitcoin's reliability. He argues that the current model of transaction fees is leading to an increasing number of valid transactions failing to confirm, resulting in decreased confidence in the system and limiting uptake. Williamson suggests using transaction priority, determined by a function of paid fees and time waiting in the transaction pool, to determine which transactions to include in the current block, as well as a target block size based on the current transaction pool size and the desired confirmation time. Williamson believes this proposal would increase transaction reliability, scalability, and market uptake, but acknowledges that it may initially lower total transaction fees per block and would require programming work.


Updated on: 2023-06-12T22:43:52.203866+00:00