Author: Matt Corallo 2012-06-15 16:18:36
Published on: 2012-06-15T16:18:36+00:00
In a discussion thread, Mike Hearn expressed his disagreement with the idea of deprioritizing transactions to below 0-fee transactions. He sees it as a hack that would make the system more complex and could whack some random people due to a heuristic "rule of thumb". However, Matt argued that it's not a change to network rules since users can already do this by patching their clients. He believes that any implementation would have sane defaults to avoid hurting random people unless they are large enough to be fully aware of how Bitcoin works. He also suggested that SatoshiDice (SD) would switch to using fresh addresses for each bet, which is good for user privacy. However, he hoped that SD would consider implementing sendmulti support to avoid having to generate a number of new addresses per second or having a huge pool of many thousands of addresses if they went the pool route. Both agreed that free transactions are not something that should be aggressively pushed as a feature of Bitcoin. In the current system, free transactions are usually confirmed within a small number of blocks, and for a number of users, that is an important feature that draws them to Bitcoin. They believe that if we can incentivize large transaction creators to avoid delaying free transactions, we should. Allowing transaction creators to delay their own transactions seems like a reasonable way to do so. Matt also suggested implementing grouped fee calculations to keep the nice property that the person who cares about double spending risk pays the fees. However, he doesn't see it as something that replaces the option to deprioritize your own transactions to below 0-fee transactions. It could even allow users who receive payouts below 0-fee transactions to place a fee on subsequent transactions to allow the payouts to confirm quicker. Regarding the idea of shipping a pruned snapshot with Bitcoin, Matt thinks it would increase centralization since he doubts more than a handful of devs would audit it. Also, old nodes do not know where to look for such data, and people running old nodes probably won't see announcements asking them to connect to archive.bitcoin.org to avoid initially having horrible initial bootstrap times and eventually not being able to connect to full-chain-serving nodes at all. Finally, he thinks that organizations willing to host full chains for people who want to rebuild their databases from scratch would need significant resources.
Updated on: 2023-05-19T03:37:20.420044+00:00