> The idea can be more generalized in that there are many cases where the > generator of a transaction doesn't care about confirmation times, and > would really be willing to make their transaction lower priority than > other 0-fee transactions.
Just to be clear, I think this solution is a hack and don't support it because it's yet another change of network rules. Some random people will get whacked because of a heuristic "rule of thumb". If it's implemented, SD could/would switch to fresh addresses and nothing would have been achieved except making an already complex system more complex. I disagree with the notion that you need "less important than free". If you care about the confirmation time of a transaction that was sent to you and you need space in a limited resource, you can pay for it. It's an auction like any other. Besides, the idea that transactions are free today is just a psychological trick befitting governments but not us - transactions are funded by aggressive hyperinflation. I would never describe Bitcoin as a free system and I suggest nobody else does either. If grouped fee calculations are implemented, we can keep the nice property that the person who cares about double spending risk pays the fees, and if you assume most transactions are hub-and-spoke from buyers to merchants, rather than a pure p2p graph, in practice it'll work out to seeming free most of the time even if seen globally it doesn't make much difference. > My point was that the easiest way to do it would be to ship a pruned > snapshot with Bitcoin, and such a system, while verifiable, would > increase Bitocin's centralization. I'm not sure why. If you want to audit everything from scratch, after checking the code you could just blow away the included files and then "-connect=archive.bitcoin.org" or something like that. After rebuilding the chain from scratch, check the databases for consistency with the included data. It reduces the number of nodes with full copies of the block chain, yes, but as long as there's at least one copy of the old data in an accessible location new nodes can still bootstrap just fine. I'm sure we can find organizations willing to host full chains for people who want to rebuild their databases from scratch, given how cheap disk space is. > connect to, possibly complicating using Bitcoin for clients that either > wish to run a full IBD or older clients which need a non-fClient node Yes, but old nodes probably have a copy of the chain already, so it wouldn't affect them. New blocks would still be fully distributed, right? The only case where it'd cause issues is if you install a fresh copy of a very old node. Not a common occurrence, and those nodes will have to wait until they find an archival node announcing itself. Those nodes could be made to announce more frequently than normal, if need be. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
