Author: Mike Koss 2012-06-15 17:37:04
Published on: 2012-06-15T17:37:04+00:00
In a discussion about the current state of Bitcoin and possible improvements, several ideas were put forward. One suggestion was to implement a fee estimation algorithm to avoid transactions getting stuck due to users not knowing what fee to set. Another proposal was for SatoshiDice to use the same fee algorithms as Bitcoin-Qt to prevent excessive fees and queue-jumping.The discussion also covers the topic of block size limits and how artificial limits like the block size limit puts a floor on prices by limiting supply beyond what it would otherwise be. The real limits are the bandwidth, computing and memory resources of participating nodes. Therefore, from an economic perspective, we do not need a global block size limit of any kind. Instead, miners should figure out what they want to do. On the miner side, the block size limit should be configurable with a relatively high default. It should also be a soft rather than a hard limit to allow for gradual upward adjustment.On the user side, displaying the fee on the Send Coins dialog and allowing users to choose a different fee per transaction would be beneficial. Discouraging address reuse will not change the number of transactions and may have negative impacts such as making certain use cases more complicated, difficulty in reading information straight out of the block chain, and increasing the address index used by block explorers and lightweight client servers.Improvements to scalability were also discussed, with a consensus that making the block size limit float would be better than picking an arbitrary threshold. However, there was disagreement over block chain pruning, with some saying it would make Bitcoin more centralized, while others argued that technical solutions could address this issue. Finally, it was suggested that SPV clients like MultiBit and Android Wallet could help address concerns about large blocks slowing down end user syncing and wasting their resources.The proposal to group mempool transactions based on fees is deemed unnecessary as it makes it harder to predict if an isolated transaction has enough "juice" to be included in the next block. A simpler algorithm, such as using an individual "fee per byte" priority algorithm, would be more understandable and predictable from the point of view of transaction generators.Lastly, the participants discussed proposals to address the current situation where SatoshiDice generates a lot of transactions, pushing more traditional traffic out due to artificial throttles. One proposal is to change the mining code to group transactions together with their mempool dependencies and then calculate all fees as a group, which allows a transition to "receiver pays" model for fees. This simplifies usage for end-users who primarily buy rather than sell and avoids the need to guess at fees.Overall, the discussion focused on finding ways to improve the functionality and accessibility of Bitcoin.
Updated on: 2023-06-06T05:15:52.275017+00:00