Published on: 2014-10-29T20:08:48+00:00
Alex Morcos has discovered issues with the existing code for estimating fees in Bitcoin transactions. The current code estimates high fees based on limited data and only has a failsafe limit of 100mBTC/tx. This can lead to wallets being emptied quickly and exchanges losing significant amounts of money due to an exploit. To address this, a user-configurable failsafe limit is suggested, as well as a more sophisticated approach that takes into account the coin-age of observed transactions.Gavin Andresen and Alex Morcos discuss the fee estimation logic in Bitcoin. Gavin proposes a default threshold percentage of 80% to avoid complaints about slow confirmations. Alex suggests making the threshold percentage tunable through an RPC call. However, Gavin is cautious about adding too many options to the RPC interface and suggests using a command-line or bitcoin.conf option for the default percentage. The discussion also includes real-world test data indicating that even the highest fee rate transactions only have a 90% confirmation rate in one block, making it challenging to guarantee a greater than 90% chance of confirmation.The conversation between Alex and Gavin continues via email, discussing the idea of using a default fee estimation threshold for Bitcoin transactions. Alex suggests making the 90% number an argument to an RPC call, allowing users to specify their desired certainty. Gavin believes that a default percentage of 80% would be more suitable to avoid slow transaction complaints. He suggests setting the default percentage as a command-line or bitcoin.conf option instead of adding multiple parameters to the RPC interface.The new code proposed by Alex for fee estimation in Bitcoin aims to provide accurate estimates based on the prevailing transaction rates. It returns higher rates due to sorting and the fact that very few transactions are placed with such small fees. To give correct low answers, the new code requires frequent super low feerate transactions. Alex suggests specifying a default percentage (possibly 80%) and making the 90% number an argument to an RPC call to facilitate building more complex logic on top of the fee estimation.Gavin and Alex discuss the functioning of the fee market in Bitcoin transactions. Gavin agrees with Alex's approach, noting that hard-coded fees prevent the existence of a functioning fee market. The current git HEAD code suggests a fee of 10,000 satoshis/kb for a 90% chance of confirmation in the next block. However, Gavin raises concerns about the time it takes for Alex's code to gather enough data for accurate fee estimation, particularly for a 90% confirmation in 20 blocks. He suggests making the 90% number an argument to the RPC call with a default of 80% to simplify building more complex logic on top of it.In summary, Alex Morcos has identified issues with the existing code for estimating fees in Bitcoin transactions and proposes a new approach. The discussion between Alex and Gavin Andresen revolves around finding the best approach to fee estimation, including suggestions for user-configurable failsafe limits and a more sophisticated method that considers the coin-age of observed transactions. They also discuss the functionality of a fee market and the challenges of gathering enough data for accurate fee estimation. The proposed solutions involve making the threshold percentage tunable through an RPC call or setting it as a command-line/bitcoin.conf option.
Updated on: 2023-08-01T10:33:47.607838+00:00