From: Gregory Maxwell <gmaxwell@gmail•com>
To: Michael Gronager <gronager@ceptacle•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming
Date: Mon, 3 Dec 2012 10:02:07 -0500 [thread overview]
Message-ID: <CAAS2fgTL=s-vvGsubUu9ZBMidd0wzZdVPb6rEUg+eTMaiipRbA@mail.gmail.com> (raw)
In-Reply-To: <9CEDE4D4-3685-4F70-953E-15CC50A8AA3F@ceptacle.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.
next prev parent reply other threads:[~2012-12-03 15:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-03 11:19 Michael Gronager
2012-12-03 12:05 ` Pieter Wuille
2012-12-03 12:24 ` Michael Gronager
2012-12-03 12:33 ` Pieter Wuille
2012-12-03 15:02 ` Gregory Maxwell [this message]
2012-12-03 15:17 ` Alan Reiner
2012-12-03 15:30 ` Mike Hearn
2012-12-03 16:18 ` Stephen Pair
2012-12-03 16:29 ` Alan Reiner
2012-12-03 19:50 ` Andreas Petersson
2012-12-03 20:14 ` Gregory Maxwell
2012-12-03 15:51 ` Gregory Maxwell
2012-12-03 12:40 ` Wladimir
2012-12-03 13:04 ` Michael Gronager
2012-12-03 15:00 ` Mike Hearn
2012-12-03 15:07 ` Gregory Maxwell
2012-12-03 15:09 ` Mike Hearn
2012-12-03 17:02 ` Mark Friedenbach
2012-12-04 9:54 ` Andy Parkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAS2fgTL=s-vvGsubUu9ZBMidd0wzZdVPb6rEUg+eTMaiipRbA@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gronager@ceptacle$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox