Author: Mike Hearn 2012-06-16 07:55:55
Published on: 2012-06-16T07:55:55+00:00
The context discusses several ideas related to Bitcoin transactions. One idea is to fill up the "free" space in a transaction with high-priority transactions based on factors such as transaction size, age of inputs, number of bitcoins, and ratio of inputs to outputs. However, this may not be necessary for those with numerous tiny outputs as they already have incentives to merge them. The process of defragmenting wallets could occur in the background during times when users are unlikely to need the outputs quickly. Newly started clients that haven't seen many transactions enter/exit the memory pool may have difficulty with this method. Peers could provide first-seen timestamps for transactions, but these timestamps may not be trustworthy, which could lead to potential attacks. SPV clients can estimate fees by getdata-ing on relevant inputs, but it is bandwidth-intensive. Another suggestion is for each client developer to run a "fee policy server," although this may not be worth worrying about currently. This is only an issue when an SPV client user wants to accept money from an untrusted source and wants it to confirm quickly, but can tolerate some delays. This scenario is likely to be rare. More common is the desire to accept payment immediately, a problem that has been discussed frequently.
Updated on: 2023-06-06T05:18:30.869148+00:00