From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TfXXF-0000PR-8a for bitcoin-development@lists.sourceforge.net; Mon, 03 Dec 2012 15:02:17 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.54 as permitted sender) client-ip=209.85.216.54; envelope-from=gmaxwell@gmail.com; helo=mail-qa0-f54.google.com; Received: from mail-qa0-f54.google.com ([209.85.216.54]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TfXXB-0004O5-K2 for bitcoin-development@lists.sourceforge.net; Mon, 03 Dec 2012 15:02:17 +0000 Received: by mail-qa0-f54.google.com with SMTP id j15so1513001qaq.13 for ; Mon, 03 Dec 2012 07:02:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.48.104 with SMTP id k8mr19362776qen.49.1354546928195; Mon, 03 Dec 2012 07:02:08 -0800 (PST) Received: by 10.49.4.104 with HTTP; Mon, 3 Dec 2012 07:02:07 -0800 (PST) In-Reply-To: <9CEDE4D4-3685-4F70-953E-15CC50A8AA3F@ceptacle.com> References: <80648682-E34A-455E-B34A-6BC24652C3EA@ceptacle.com> <9CEDE4D4-3685-4F70-953E-15CC50A8AA3F@ceptacle.com> Date: Mon, 3 Dec 2012 10:02:07 -0500 Message-ID: From: Gregory Maxwell To: Michael Gronager Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1TfXXB-0004O5-K2 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 15:02:17 -0000 On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager wr= ote: > 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 u= s all and b) is also of economical benefit for the miners, will likely be a= ccepted quite fast - especially now when the bounty was just halved... I al= so fear that there is a lot of BTCs that is effectively un-owned and it cou= ld 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=E2=80=94 and none lik= ely to ever exist=E2=80=94 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=E2=80=94 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=E2=80=94 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=E2=80=94 and I already k= now 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=E2=80=94 as opposed to the mechanism=E2=80=94 I shar= e 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=E2=80=94 smallest to largest=E2=80=94 until an additional one = would increase the cost of the transaction by 0.0001 BTC or more" =E2=80=94 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.