> This would be bloating UTXO data at a speed of 52 GB/year. That's a very > big memory leak. And this is just the unspendable outputs.
Firstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs that never get spent are not in the working set by definition, after a while they just end up in the bottom levels and hardly ever get accessed. If need be we can always help LevelDB out a bit by moving outputs that we suspect are unlikely to get spent into a separate database, but I doubt it's needed. Secondly, if an output can be proven unspendable it can be pruned immediately. We already reached consensus on adding some standard template using OP_RETURN that results in insta-pruning. So people who want to create unspendable outputs can do so with the only side-effect being long term chain storage. It would be effectively "free" to pruning nodes. So the issue is not really with unspendable outputs but with low-value spendable outputs. Wallets with lots of tiny outputs end up generating large transactions that take a long time to verify, in situations where the network redlines those transactions would end up at the bottom of the priority queue and might take longer to confirm. So wallet apps already have incentives to try and find a good balance in output sizes and defragment themselves if their average output gets too low in value, eg, by send-to-self transactions at night. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
