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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1TfXnG-0001aT-Gg
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 15:18:50 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.54 as permitted sender)
client-ip=209.85.216.54; envelope-from=etotheipi@gmail.com;
helo=mail-qa0-f54.google.com;
Received: from mail-qa0-f54.google.com ([209.85.216.54])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TfXnF-0005j2-La
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 15:18:50 +0000
Received: by mail-qa0-f54.google.com with SMTP id j15so1533482qaq.13
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Dec 2012 07:18:44 -0800 (PST)
Received: by 10.224.95.196 with SMTP id e4mr17258342qan.88.1354547924261;
Mon, 03 Dec 2012 07:18:44 -0800 (PST)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPS id em3sm9597559qab.12.2012.12.03.07.18.42
(version=SSLv3 cipher=OTHER); Mon, 03 Dec 2012 07:18:43 -0800 (PST)
Message-ID: <50BCC28A.4060503@gmail.com>
Date: Mon, 03 Dec 2012 10:17:30 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <80648682-E34A-455E-B34A-6BC24652C3EA@ceptacle.com>
<CAPg+sBi25xP8R03y1VR=q4ZJaeT6FAuV=hXsq_7niSHycpnPuA@mail.gmail.com>
<9CEDE4D4-3685-4F70-953E-15CC50A8AA3F@ceptacle.com>
<CAAS2fgTL=s-vvGsubUu9ZBMidd0wzZdVPb6rEUg+eTMaiipRbA@mail.gmail.com>
In-Reply-To: <CAAS2fgTL=s-vvGsubUu9ZBMidd0wzZdVPb6rEUg+eTMaiipRbA@mail.gmail.com>
X-Enigmail-Version: 1.4.6
Content-Type: multipart/alternative;
boundary="------------020109080207010107040606"
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
(etotheipi[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: 1TfXnF-0005j2-La
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 15:18:50 -0000
This is a multi-part message in MIME format.
--------------020109080207010107040606
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On 12/03/2012 10:02 AM, Gregory Maxwell wrote:
> (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.
FYI, Armory uses exactly this logic to try to clean up dust outputs in
the user's transactions. However, there's enough conditions on it, that
I don't know how often it triggers. Recommendations are welcome for how
to improve it.
Right now, if the transaction has less than 5 inputs, there exists dust
UTXOs from addresses already included in the transaction, and those
UTXOs are sufficiently small in priority, then the Armory will add them
to the input side and increase the change accordingly. Looking it just
made me realize I lost the last condition of making sure the tx already
has a change output -- don't want to turn a free tx into a fee-needed tx
just to do this. (reorganized the code
<https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine.py#L5279>
recently, and must have fell through the cracks).
Perhaps it could be improved by cleaning up dust from *any* address by
default (not just ones already included in the tx), with the option for
the user to disable that behavior. After all, anonymity was never a
core feature of the network -- I think it makes sense that the logic
would reduce anonymity by default in exchange for a cleaner network,
with a clear option to "opt-out" of that logic if user cares. I think
most users don't actually care...
-Alan
--------------020109080207010107040606
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/03/2012 10:02 AM, Gregory Maxwell
wrote:<br>
</div>
<blockquote
cite="mid:CAAS2fgTL=s-vvGsubUu9ZBMidd0wzZdVPb6rEUg+eTMaiipRbA@mail.gmail.com"
type="cite">(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.
<br>
</blockquote>
<br>
<br>
FYI, Armory uses exactly this logic to try to clean up dust outputs
in the user's transactions. However, there's enough conditions on
it, that I don't know how often it triggers. Recommendations are
welcome for how to improve it.<br>
<br>
Right now, if the transaction has less than 5 inputs, there exists
dust UTXOs from addresses already included in the transaction, and
those UTXOs are sufficiently small in priority, then the Armory will
add them to the input side and increase the change accordingly.
Looking it just made me realize I lost the last condition of making
sure the tx already has a change output -- don't want to turn a free
tx into a fee-needed tx just to do this. (reorganized <a
href="https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine.py#L5279">the
code</a> recently, and must have fell through the cracks).<br>
<br>
Perhaps it could be improved by cleaning up dust from <b>any</b>
address by default (not just ones already included in the tx), with
the option for the user to disable that behavior. After all,
anonymity was never a core feature of the network -- I think it
makes sense that the logic would reduce anonymity by default in
exchange for a cleaner network, with a clear option to "opt-out" of
that logic if user cares. I think most users don't actually care...<br>
<br>
-Alan<br>
</body>
</html>
--------------020109080207010107040606--
|
