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
|
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 <mh.in.england@gmail.com>) id 1YwxMP-0006m0-9p
for bitcoin-development@lists.sourceforge.net;
Mon, 25 May 2015 18:44:25 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.54 as permitted sender)
client-ip=74.125.82.54; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f54.google.com;
Received: from mail-wg0-f54.google.com ([74.125.82.54])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YwxMO-0004k3-8k
for bitcoin-development@lists.sourceforge.net;
Mon, 25 May 2015 18:44:25 +0000
Received: by wgez8 with SMTP id z8so78872679wge.0
for <bitcoin-development@lists.sourceforge.net>;
Mon, 25 May 2015 11:44:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.206.229 with SMTP id lr5mr34073129wic.86.1432579458300;
Mon, 25 May 2015 11:44:18 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.143.9 with HTTP; Mon, 25 May 2015 11:44:18 -0700 (PDT)
In-Reply-To: <CANe1mWzBy8-C+CWfwaOLxJ2wokjy8ytQUh2TkRY_Ummn1BpPzw@mail.gmail.com>
References: <CANe1mWzBy8-C+CWfwaOLxJ2wokjy8ytQUh2TkRY_Ummn1BpPzw@mail.gmail.com>
Date: Mon, 25 May 2015 20:44:18 +0200
X-Google-Sender-Auth: -WepOnTMuHJ3O3CdCdZT2klXqv0
Message-ID: <CANEZrP0DL8yA=neK0DTq0npEqc0q+RvTQD57OndNVg0vi2=yMg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jim Phillips <jim@ergophobia.org>
Content-Type: multipart/alternative; boundary=001a11c38a22b9806f0516ec65f4
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1YwxMO-0004k3-8k
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] A suggestion for reducing the size of the
UTXO database
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, 25 May 2015 18:44:25 -0000
--001a11c38a22b9806f0516ec65f4
Content-Type: text/plain; charset=UTF-8
Wallets are incentivised to do a better job with defragmentation already,
as if you have lots of tiny UTXOs then your fees end up being huge when
trying to make a payment.
The reason they largely don't is just one of manpower. Nobody is working on
it.
As a wallet developer myself, one way I'd like to see this issue be fixed
by making free transactions more reliable. Then wallets can submit free
transactions to the network to consolidate UTXOs together, e.g. at night
when the user is sleeping. They would then fit into whatever space is
available in the block during periods of low demand, like on Sunday.
If we don't do this then wallets won't automatically defragment, as we'd be
unable to explain to the user why their money is slowly leaking out of
their wallet without them doing anything. Trying to explain the existing
transaction fees is hard enough already ("I thought bitcoin doesn't have
banks" etc).
There is another way: as the fee is based on a rounded 1kb calculation, if
you go into the next fee band adding some more outputs and making a bigger
change output becomes "free" for another output or two. But wallets don't
exploit this today.
--001a11c38a22b9806f0516ec65f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Wallets are incentivised to do a better job with defragmen=
tation already, as if you have lots of tiny UTXOs then your fees end up bei=
ng huge when trying to make a payment.<div><br></div><div><div class=3D"gma=
il_extra">The reason they largely don't is just one of manpower. Nobody=
is working on it.</div></div><div class=3D"gmail_extra"><br></div><div cla=
ss=3D"gmail_extra">As a wallet developer myself, one way I'd like to se=
e this issue be fixed by making free transactions more reliable. Then walle=
ts can submit free transactions to the network to consolidate UTXOs togethe=
r, e.g. at night when the user is sleeping. They would then fit into whatev=
er space is available in the block during periods of low demand, like on Su=
nday.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
If we don't do this then wallets won't automatically defragment, as=
we'd be unable to explain to the user why their money is slowly leakin=
g out of their wallet without them doing anything. Trying to explain the ex=
isting transaction fees is hard enough already ("I thought bitcoin doe=
sn't have banks" etc).</div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">There is another way: =C2=A0as the fee is based o=
n a rounded 1kb calculation, if you go into the next fee band adding some m=
ore outputs and making a bigger change output becomes "free" for =
another output or two. But wallets don't exploit this today.</div></div=
>
--001a11c38a22b9806f0516ec65f4--
|
