From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TfUmW-0002wf-8U for bitcoin-development@lists.sourceforge.net; Mon, 03 Dec 2012 12:05:52 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.175 as permitted sender) client-ip=209.85.214.175; envelope-from=pieter.wuille@gmail.com; helo=mail-ob0-f175.google.com; Received: from mail-ob0-f175.google.com ([209.85.214.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TfUmQ-0006Ez-QI for bitcoin-development@lists.sourceforge.net; Mon, 03 Dec 2012 12:05:52 +0000 Received: by mail-ob0-f175.google.com with SMTP id vb8so2449539obc.34 for ; Mon, 03 Dec 2012 04:05:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.0.228 with SMTP id 4mr7779496oeh.88.1354536341471; Mon, 03 Dec 2012 04:05:41 -0800 (PST) Received: by 10.76.143.38 with HTTP; Mon, 3 Dec 2012 04:05:41 -0800 (PST) In-Reply-To: <80648682-E34A-455E-B34A-6BC24652C3EA@ceptacle.com> References: <80648682-E34A-455E-B34A-6BC24652C3EA@ceptacle.com> Date: Mon, 3 Dec 2012 13:05:41 +0100 Message-ID: From: Pieter Wuille To: Michael Gronager Content-Type: multipart/alternative; boundary=e89a8fb1fd807801f004cff19155 X-Spam-Score: -0.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 (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1TfUmQ-0006Ez-QI 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 12:05:52 -0000 --e89a8fb1fd807801f004cff19155 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 3, 2012 at 12:19 PM, Michael Gronager 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 --e89a8fb1fd807801f004cff19155 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Dec 3, 2012 at 12:19 PM, Michael Gronager <gronager@ceptacle.c= om> wrote:
(Also posted on the forum: https://bit= cointalk.org/index.php?topic=3D128900.0)

The amount of "dust" in the block chain is getting large and it i= s growing all the time. Currently 11% of unspent tx outputs (UTXO) are of 1= Satoshi (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 con= cern indeed.
=A0
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 b= een tried in freicoin), but as a mean to recycle pennies over time. The pro= posal 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) tr= ansactions that reduce the number of UTXO's.

--=A0
Pieter
=A0
--e89a8fb1fd807801f004cff19155--