Published on: 2013-03-13T09:20:17+00:00
In a discussion about transaction fees in Bitcoin, Stephen Pair proposes a new approach to paying for transactions. He suggests that instead of blocking uneconomical transactions, there should be a market for fee-bearing transactions. This system would allow for determining the probability of confirmation in a specific timeframe for a given fee. Peter Todd responds to this by discussing the costs of creating unspent transaction outputs (UTXO) and suggests a standard transaction type for unspendable but not provably so transaction outputs. He highlights the advantages of this approach for timestamping and secure data backups.The conversation also touches on the use of RAM as a database cache, potential attack scenarios on the UTXO, and the scalability of Bitcoin. The cost of storing data in the UTXO set is noted to be more expensive than storing the actual transaction data. The current fee system based on KB in a block is argued to not capture the long-term costs of UTXO creation. To address this, Todd suggests paying for a feed of economical transactions to determine confirmation probabilities. He also proposes using unspendable but not provably so transaction outputs for timestamping and secure data backups.There is a concern raised about potential attacks on the UTXO storage if it is not stored in fast storage. The specific attack scenario is not clarified, but it is mentioned that attempting to send fake transactions to nodes with invalid transactions would result in disconnection and IP banning. The need to prioritize addressing potential denial-of-service attacks on Bitcoin is emphasized.The UTXO set is currently stored in LevelDB and not in memory. Unspendable outputs are not part of the working set and can be moved to a separate database if necessary. Immediate pruning can be done for proven unspendable outputs, and consensus has been reached on adding a standard template for insta-pruning. However, low-value spendable outputs pose challenges, and wallet apps need to find a balance in output sizes. Wallets with lots of small outputs generate larger transactions that take longer to verify.The discussion explores the possibility of transitioning from a peer-to-peer network to a Distributed Hash Table (DHT) for storing, validating, and verifying UTXOs. While the current use of UTXOs in the Satoshi client does not directly involve DHT, it speeds up validation by checking if an output is unspent. An alternative method is suggested that uses an authenticated data structure storing UTXOs in a DHT.The issue of scalability of Bitcoin and the size of the UTXO set is addressed. The proposal is made to move from a peer-to-peer network to a DHT to accommodate a growing UTXO set. Concerns are raised about abusive/misuse or massive use of systems like SatoshiDice, which contribute to UTXO bloat. The need for protocol-level discouragement of such spamming is highlighted to allow for scaling without excessive memory leaks.Different opinions are expressed regarding the size of the UTXO set and the need for solutions. It is argued that the UTXO problem scales with the block size limit and should be resolved before considering increasing it. The idea of making transaction outputs with a value less than the transaction fee non-standard is debated, with alternative proposals like activating a non-proportional demurrage to incentivize old transactions to be moved. Concerns about the incentive structure and negative community response are raised.The possibility of introducing demurrage as a fee for holding bitcoins or any cryptocurrency is discussed. While some believe it would face negative publicity, the suggestion of creating a separate coin with a finite lifespan is proposed. This alt-coin, called "tempcoin," could have rules where miners reclaim coins older than a certain block height.In a discussion about micropayments and demurrage in Bitcoin, it is questioned whether these concepts are still relevant considering that the base rules of Bitcoin will not be changing. The size of the UTXO set is also debated, with some arguing that minimizing its size is unnecessary as it currently takes up only a few hundred megabytes and can easily fit into RAM or disk.Banning micropayments is seen as potentially detrimental to interesting applications without providing any real benefit. Instead, there are less invasive changes proposed for improving scalability. These include making transaction validation multi-threaded, transmitting merkle blocks instead of full blocks, moving blocking disk IO off the main loop, and completing the payment protocol work.Jorge Timón suggests an alternative solution to the perceived problem of micropayments and demurrage. He proposes a sudden "destruction" or re-generation of accounts after a certain period rather than rejecting potential use cases for the Bitcoin chain.
Updated on: 2023-08-01T04:30:01.703982+00:00