1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
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 <pieter.wuille@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CAPg+sBi25xP8R03y1VR=q4ZJaeT6FAuV=hXsq_7niSHycpnPuA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Michael Gronager <gronager@ceptacle.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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
--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 <span dir=3D"ltr"><<a =
href=3D"mailto:gronager@ceptacle.com" target=3D"_blank">gronager@ceptacle.c=
om</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">(Also posted on the forum: <a href=3D"https:=
//bitcointalk.org/index.php?topic=3D128900.0" target=3D"_blank">https://bit=
cointalk.org/index.php?topic=3D128900.0</a>)<br>
<br>
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!)<br>
</blockquote><div><br></div><div>I've noticed this too, and it is a con=
cern indeed.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<a h=
ref=3D"http://en.wikipedia.org/wiki/Demurrage_(currency)" target=3D"_blank"=
>http://en.wikipedia.org/wiki/Demurrage_(currency)</a> 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:<br>
1-99 Satoshi: lives for 210 blocks<br>
100-9999 Satoshi: lives for 2100 blocks<br>
10000-999999 Satoshi: lives for 21000 blocks<br>
1000000-99999999 Satoshi: lives for 210000 blocks<br></blockquote><div><br>=
</div><div>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.</=
div>
<div><br></div><div>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.</div><div><br></div><div>
--=A0</div><div>Pieter</div><div>=A0</div></div></div>
--e89a8fb1fd807801f004cff19155--
|
