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-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 <gmaxwell@gmail.com>) id 1TfXXF-0000PR-8a
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 15:02:17 +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=gmaxwell@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 1TfXXB-0004O5-K2
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 15:02:17 +0000
Received: by mail-qa0-f54.google.com with SMTP id j15so1513001qaq.13
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Dec 2012 07:02:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.49.48.104 with SMTP id k8mr19362776qen.49.1354546928195; Mon,
03 Dec 2012 07:02:08 -0800 (PST)
Received: by 10.49.4.104 with HTTP; Mon, 3 Dec 2012 07:02:07 -0800 (PST)
In-Reply-To: <9CEDE4D4-3685-4F70-953E-15CC50A8AA3F@ceptacle.com>
References: <80648682-E34A-455E-B34A-6BC24652C3EA@ceptacle.com>
<CAPg+sBi25xP8R03y1VR=q4ZJaeT6FAuV=hXsq_7niSHycpnPuA@mail.gmail.com>
<9CEDE4D4-3685-4F70-953E-15CC50A8AA3F@ceptacle.com>
Date: Mon, 3 Dec 2012 10:02:07 -0500
Message-ID: <CAAS2fgTL=s-vvGsubUu9ZBMidd0wzZdVPb6rEUg+eTMaiipRbA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Michael Gronager <gronager@ceptacle.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: 1TfXXB-0004O5-K2
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 15:02:17 -0000
On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager <gronager@ceptacle.com> wr=
ote:
> Bitcoin aka the blockchain is defined by the majority of the miners. This=
is what people have signed up to imo. A scheme that a) is of benefit for u=
s all and b) is also of economical benefit for the miners, will likely be a=
ccepted quite fast - especially now when the bounty was just halved... I al=
so fear that there is a lot of BTCs that is effectively un-owned and it cou=
ld even drive Satoshi to use some of his BTCs ;)
Pieter already commented on this, but it's so important it must be
said twice because everyone developing software for Bitcoin must
understand and internalize it:
Bitcoin is not a democracy, it's certainly not a democracy of miners.
Every full node independently and autonomously validates the rules of
the system without the influence of other participants.
Unfortunately, there is no universally consistent way to evaluate the
temporal ordering of transactions independently known=E2=80=94 and none lik=
ely
to ever exist=E2=80=94 and a digital currency requires ordering to resolve
double spends. Because of this Bitcoin must compromise the autonomy of
its validation slightly: It uses a computational majority to determine
transaction ordering. But only ordering!
This is essential because if all the rules were subject to the whim of
a computing majority the system would be far less trustworthy. The
economic incentives which keep the mining participants honest depend
on the value of defection being as limited as possible.
So, no=E2=80=94 you can't achieve by what you want with miners. Any miner
which applied your rules would instantly stop mining from the
perspective of Bitcoin users. As a miner myself, I welcome my
competition adopting your proposal :P. You're looking for a hard fork
of the system. Such a change must be supported by ~all users, and so
it must be something which has near universal consensus that it is
essential. I think it's not essential=E2=80=94 though I agree that better
UTXO set size management would have been a useful component if it had
been in the origin economic promise of the system=E2=80=94 and I already k=
now
that some participants take a principled position that views changes
to the mere spendability of outputs as _theft_.
Your proposal is also more economically hazardous than necessary: By
paying unmoved coins to miners you create a substantial incentive for
miners to delay processing transactions in the hopes that they expire
first. There is also some risk that the return of large coins from
the past after the currency has substantially deflated would be
extremely economically disruptive.
As far as your concern=E2=80=94 as opposed to the mechanism=E2=80=94 I shar=
e it. But
it's important to note that the source of most of the problem
transactions is a single source, and a rather unusual one that defies
the normal anti-spamming economic incentives by attracting mentally
ill people to subsidize pay for the bloating transactions, which are
already penalized. I believe this specific issue can be adequately
addressed primarily through a three fold process:
(1) Make client software aggressive about sweeping up dust inputs:
"Any time a transaction is created that has change keep adding in
extra inputs=E2=80=94 smallest to largest=E2=80=94 until an additional one =
would
increase the cost of the transaction by 0.0001 BTC or more" =E2=80=94 the
only major complication is doing this without concurrently harming
privacy which is why it's not done yet in the reference client.
(2) Change the default relay and mining rules to further penalize
transactions with very small outputs. Making sure that its
practically possible to create inexpensive transactions right now is
very important for the long term success of the system while the small
size of the system makes it unattractive to use, but I don't believe
that applies for dust outputs.
(3) Change the default relay and mining rules to further incentive
reductions in the UTXO set size. This would make the actions of (1)
save the participants funds instead of just being an altruistic
behavior that most do because its a default.
It might also be useful for client software to incorporate a "destroy
wallet" button for people with wallets that only have dust remaining
to send the private keys off to something of community benefit (e.g.
bitcoin foundation, the faucet, or the developers of that that client)
for recovery so that they don't perpetually bloat the UTXO set.
I expect that these actions would substantially address your concerns,
and even if they do not I believe that they would be the most basic
prerequisites for any kind of argument that something more drastic
(especially something that some would could consider theft!) is
essential.
|
