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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1TfVKX-000199-1T
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 12:41:01 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.47 as permitted sender)
client-ip=209.85.214.47; envelope-from=laanwj@gmail.com;
helo=mail-bk0-f47.google.com;
Received: from mail-bk0-f47.google.com ([209.85.214.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TfVKU-0001bJ-Kh
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 12:41:00 +0000
Received: by mail-bk0-f47.google.com with SMTP id j4so999279bkw.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Dec 2012 04:40:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.129.17 with SMTP id hg17mr2795010bkc.41.1354538452235;
Mon, 03 Dec 2012 04:40:52 -0800 (PST)
Received: by 10.204.4.89 with HTTP; Mon, 3 Dec 2012 04:40:52 -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:40:52 +0100
Message-ID: <CA+s+GJAxGxrtqHSx4ssowg=C=Q+ajELHsEfAgjNh9W2+ExpgVQ@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Michael Gronager <gronager@ceptacle.com>
Content-Type: multipart/alternative; boundary=001517447cee47b5cb04cff20f9a
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
(laanwj[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: 1TfVKU-0001bJ-Kh
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:41:01 -0000
--001517447cee47b5cb04cff20f9a
Content-Type: text/plain; charset=UTF-8
I do think it would be nice to sweep up dust transactions, however I'm not
that happy with your solution
1) Wouldn't the need to re-transact your coins to keep them safe from
"vultures", result in people frantically sending coins to themselves, and
thus expand the block chain, instead of reduce growth?
2) putting those hard limits in passes a value judgement that IMO should
not be present in the protocol. <1BTC may be worth a lot some day, or it
could go the other way around, with dust spam of 10+ BTC. Either way the
limits will have to be changed again, with yet another fork.
3) The (normal) user does not have a view of his balance consisting of
inputs and outputs of various sizes. He just sees his balance as one
number. And somehow, inexplicably (except through a very difficult
explanation), it's going down... what if he has 10000 BTC in 0.9999999 BTC
units? Annnnnd it's gone after 210000 blocks.
I wonder if there is a way for the whole process to be transparent to the
user. The wallet is 'defragmented' but without losing the swept up coins to
the miner.
Wladimir
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!)
>
> This means that a huge part of the block chain is used for essentially
> nothing - e.g. the sum of the 11% is worth roughly 2 US cents !
>
> The main source for these 1 Satoshi payouts is Sahtoshi Dice. And nothing
> wrong with that, however, we should work on ensuring that too many too
> small payments will not kill the size of the blockchain in the end -
> further, they are essentially too small to be included in other transaction
> as the added fee will often make it more expensive to remove them. Hence,
> there is no incentive to get rid of them.
>
> 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
>
> Only amounts above 1BTC lives forever - (or we could even impose aging on
> those too..)
>
> The aged coins are simply included in the block mining reward, creating
> another incentive for miners. Further, if we include all coins in this
> recycle scheme coins will never be lost forever.
>
> This scheme will impose some lifetimes also on e.g. colored coins (hence
> you need to use a certain amount to borrow space on the blockchain for the
> time needed, or simply transact them).
>
> If you like this I would be happy to write it into a BIP.
>
> Thoughts ?
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> BUILD Helping you discover the best ways to construct your parallel
> projects.
> http://goparallel.sourceforge.net
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001517447cee47b5cb04cff20f9a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div><br></div><div>I do think it would be nice to sweep up dust transactio=
ns, however I'm not that happy with your solution</div><div><br></div><=
div>1) Wouldn't the need to re-transact your coins to keep them safe fr=
om "vultures", result in people=C2=A0frantically=C2=A0sending coi=
ns to themselves, and thus expand the block chain, instead of reduce growth=
?</div>
<div><br></div><div>2) putting those hard limits in passes a value judgemen=
t that IMO should not be present in the protocol. <1BTC may be worth a l=
ot some day, or it could go the other way around, with dust spam of 10+ BTC=
. Either way the limits will have to be changed again, with yet another for=
k.</div>
<div><br></div><div>3) The (normal) user does not have a view of his balanc=
e consisting of inputs and outputs of various sizes. He just sees his balan=
ce as one number. And somehow,=C2=A0inexplicably (except through a very dif=
ficult explanation), it's going down... what if he has 10000 BTC in 0.9=
999999 BTC units? Annnnnd it's gone after 210000 blocks.</div>
<div><br></div><div>I wonder if there is a way for the whole process to be =
transparent to the user. The wallet is 'defragmented' but without l=
osing the swept up coins to the miner.</div><div><br></div>Wladimir<div>
<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On =
Mon, Dec 3, 2012 at 12:19 PM, Michael Gronager <span dir=3D"ltr"><<a hre=
f=3D"mailto:gronager@ceptacle.com" target=3D"_blank">gronager@ceptacle.com<=
/a>></span> wrote:<br>
<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>
<br>
This means that a huge part of the block chain is used for essentially noth=
ing - e.g. the sum of the 11% is worth roughly 2 US cents !<br>
<br>
The main source for these 1 Satoshi payouts is Sahtoshi Dice. And nothing w=
rong with that, however, we should work on ensuring that too many too small=
payments will not kill the size of the blockchain in the end - further, th=
ey are essentially too small to be included in other transaction as the add=
ed fee will often make it more expensive to remove them. Hence, there is no=
incentive to get rid of them.<br>
<br>
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>
<br>
Only amounts above 1BTC lives forever - (or we could even impose aging on t=
hose too..)<br>
<br>
The aged coins are simply included in the block mining reward, creating ano=
ther incentive for miners. Further, if we include all coins in this recycle=
scheme coins will never be lost forever.<br>
<br>
This scheme will impose some lifetimes also on e.g. colored coins (hence yo=
u need to use a certain amount to borrow space on the blockchain for the ti=
me needed, or simply transact them).<br>
<br>
If you like this I would be happy to write it into a BIP.<br>
<br>
Thoughts ?<br>
---------------------------------------------------------------------------=
---<br>
Keep yourself connected to Go Parallel:<br>
BUILD Helping you discover the best ways to construct your parallel project=
s.<br>
<a href=3D"http://goparallel.sourceforge.net" target=3D"_blank">http://gopa=
rallel.sourceforge.net</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>
--001517447cee47b5cb04cff20f9a--
|
