On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager <grona...@ceptacle.com> wrote: > Bitcoin aka the blockchain is defined by the majority of the miners. This is > what people have signed up to imo. A scheme that a) is of benefit for us all > and b) is also of economical benefit for the miners, will likely be accepted > quite fast - especially now when the bounty was just halved... I also fear > that there is a lot of BTCs that is effectively un-owned and it could even > drive Satoshi to use some of his BTCs ;)
Pieter already commented on this, but it's so important it must be said twice because everyone developing software for Bitcoin must understand and internalize it: Bitcoin is not a democracy, it's certainly not a democracy of miners. Every full node independently and autonomously validates the rules of the system without the influence of other participants. Unfortunately, there is no universally consistent way to evaluate the temporal ordering of transactions independently known— and none likely to ever exist— and a digital currency requires ordering to resolve double spends. Because of this Bitcoin must compromise the autonomy of its validation slightly: It uses a computational majority to determine transaction ordering. But only ordering! This is essential because if all the rules were subject to the whim of a computing majority the system would be far less trustworthy. The economic incentives which keep the mining participants honest depend on the value of defection being as limited as possible. So, no— you can't achieve by what you want with miners. Any miner which applied your rules would instantly stop mining from the perspective of Bitcoin users. As a miner myself, I welcome my competition adopting your proposal :P. You're looking for a hard fork of the system. Such a change must be supported by ~all users, and so it must be something which has near universal consensus that it is essential. I think it's not essential— though I agree that better UTXO set size management would have been a useful component if it had been in the origin economic promise of the system— and I already know that some participants take a principled position that views changes to the mere spendability of outputs as _theft_. Your proposal is also more economically hazardous than necessary: By paying unmoved coins to miners you create a substantial incentive for miners to delay processing transactions in the hopes that they expire first. There is also some risk that the return of large coins from the past after the currency has substantially deflated would be extremely economically disruptive. As far as your concern— as opposed to the mechanism— I share it. But it's important to note that the source of most of the problem transactions is a single source, and a rather unusual one that defies the normal anti-spamming economic incentives by attracting mentally ill people to subsidize pay for the bloating transactions, which are already penalized. I believe this specific issue can be adequately addressed primarily through a three fold process: (1) Make client software aggressive about sweeping up dust inputs: "Any time a transaction is created that has change keep adding in extra inputs— smallest to largest— until an additional one would increase the cost of the transaction by 0.0001 BTC or more" — the only major complication is doing this without concurrently harming privacy which is why it's not done yet in the reference client. (2) Change the default relay and mining rules to further penalize transactions with very small outputs. Making sure that its practically possible to create inexpensive transactions right now is very important for the long term success of the system while the small size of the system makes it unattractive to use, but I don't believe that applies for dust outputs. (3) Change the default relay and mining rules to further incentive reductions in the UTXO set size. This would make the actions of (1) save the participants funds instead of just being an altruistic behavior that most do because its a default. It might also be useful for client software to incorporate a "destroy wallet" button for people with wallets that only have dust remaining to send the private keys off to something of community benefit (e.g. bitcoin foundation, the faucet, or the developers of that that client) for recovery so that they don't perpetually bloat the UTXO set. I expect that these actions would substantially address your concerns, and even if they do not I believe that they would be the most basic prerequisites for any kind of argument that something more drastic (especially something that some would could consider theft!) is essential. ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
