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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1TfYJB-0000vm-40
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 15:51:49 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.175 as permitted sender)
client-ip=209.85.216.175; envelope-from=gmaxwell@gmail.com;
helo=mail-qc0-f175.google.com;
Received: from mail-qc0-f175.google.com ([209.85.216.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TfYJ8-0000fN-RI
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 15:51:49 +0000
Received: by mail-qc0-f175.google.com with SMTP id j3so1642956qcs.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Dec 2012 07:51:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.198.217 with SMTP id ep25mr3867038qcb.59.1354549901366;
Mon, 03 Dec 2012 07:51:41 -0800 (PST)
Received: by 10.49.4.104 with HTTP; Mon, 3 Dec 2012 07:51:41 -0800 (PST)
In-Reply-To: <50BCC28A.4060503@gmail.com>
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>
<50BCC28A.4060503@gmail.com>
Date: Mon, 3 Dec 2012 10:51:41 -0500
Message-ID: <CAAS2fgRTHwTUADF+909zztv6_mXsmsT+obZ0X=qjNZ2=yWsD5Q@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1TfYJ8-0000fN-RI
Cc: 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 15:51:49 -0000
On Mon, Dec 3, 2012 at 10:17 AM, Alan Reiner <etotheipi@gmail.com> wrote:
> Perhaps it could be improved by cleaning up dust from any address by defa=
ult
> (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 b=
y
> default in exchange for a cleaner network, with a clear option to "opt-ou=
t"
> of that logic if user cares. I think most users don't actually care...
Yea, the obvious case would look for exact matches=E2=80=94 but because sa=
ne
software pays change to fresh addresses I expect this to trigger an
unfortunately infrequent amount of time.
Why do you bother with the 5 input limit? The way I'd handle this in
the reference client is as a pure post-processing step. E.g. take any
w/ change transaction formed and try adding small inputs in a greedy
fashion until the next would change the fees. Do you see a reason not
to do this?
A next step up in infrequency is to use input taint tracking
information to gather up coins from all inputs which are already
crosslinked. In the reference client, which doesn't avoid
crosslinking, this would likely be quite effective but I worry about
having an O(N^2)-ish algorithm as part of coin selection. And so I
think it would require maintaining in the wallet the cross link
history for each address rather than building it on the fly. This
seems like a lot of changes for a relatively modest optimization.
Another possibility would be to not apply the privacy rule to very
small inputs or to addresses which have only ever received a very
small sum total. But I don't know how to define very small in a robust
way, and I think that the privacy behavior of the software being
"inconsistent" from the users perspective would be somewhat
unfortunate. Perhaps a setting for the value considered very small
for this purpose which defaults to the relay MINFEE? (And also
include larger outputs when they're address matches).
The the problem with this is this: Say I have an address 1GMaxwellFOO
that everyone knows belongs to me. Someone who wants to identify all
my transactions sends me a constant spray of 1e-8 inputs to
1GMaxwellFOO. If the address association is ignored (even for only
very small inputs) then all my transactions become rapidly
identifiable. Privacy, of at least a basic form, is an important
element of the system, if it's not preserved than bitcoin is inferior
to traditional value transfer systems in an additional way.
(And FWIW, I've seen self-appointed sluths on IRC trying to catch
trouble makers by paying tiny amounts to their extortion addresses;
with the incorrect expectation that it would taint their other
transactions. So even when it doesn't usually work people have tried
using this to attack people)
|
