Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming

[Gregory Maxwell <gmaxwell@gmail.com>]

On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager <gronager@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.