From: Pieter Wuille <pieter.wuille@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 13:05:41 +0100 [thread overview]
Message-ID: <CAPg+sBi25xP8R03y1VR=q4ZJaeT6FAuV=hXsq_7niSHycpnPuA@mail.gmail.com> (raw)
In-Reply-To: <80648682-E34A-455E-B34A-6BC24652C3EA@ceptacle.com>
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
On Mon, Dec 3, 2012 at 12:19 PM, Michael Gronager <gronager@ceptacle•com>wrote:
> (Also posted on the forum:
> https://bitcointalk.org/index.php?topic=128900.0)
>
> The amount of "dust" in the block chain is getting large and it is growing
> all the time. Currently 11% of unspent tx outputs (UTXO) are of 1Satoshi
> (0.00000001BTC), 32% is less than 0.0001BTC and 60% is less than 0.001BTC.
> (Thanks to Jan for digging out these numbers!)
>
I've noticed this too, and it is a concern indeed.
> I have an idea for a possible mitigation of this problem - introduction of
> demurrage - not as in it normal meaning as a percentage over time (see:
> http://en.wikipedia.org/wiki/Demurrage_(currency) btw, this has also been
> tried in freicoin), but as a mean to recycle pennies over time. The
> proposal is simple - UTXOs age out if not re-transacted - the smaller the
> coin the faster the aging:
> 1-99 Satoshi: lives for 210 blocks
> 100-9999 Satoshi: lives for 2100 blocks
> 10000-999999 Satoshi: lives for 21000 blocks
> 1000000-99999999 Satoshi: lives for 210000 blocks
>
If this were a proposal at the time Bitcoin was created, I would definitely
be in favor, but I feel we can't just change such a policy right now - it's
not what people signed up for when they started using the system. I also
see no way to implement this without a hard fork, which would require
planning at least 1-2 years in advance (imho). By that time, the economic
landscape of Bitcoin may be vastly different, and either dust spam will
have killed it, or we will have found another solution already.
Personally, I think the best solution is to change the mining policy to
prioritize (and perhaps favor for free relay/inclusion) transactions that
reduce the number of UTXO's.
--
Pieter
[-- Attachment #2: Type: text/html, Size: 2484 bytes --]
next prev parent reply other threads:[~2012-12-03 12:05 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 [this message]
2012-12-03 12:24 ` Michael Gronager
2012-12-03 12:33 ` Pieter Wuille
2012-12-03 15:02 ` Gregory Maxwell
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='CAPg+sBi25xP8R03y1VR=q4ZJaeT6FAuV=hXsq_7niSHycpnPuA@mail.gmail.com' \
--to=pieter.wuille@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