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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] A suggestion for reducing the size of the
 UTXO database
Precedence: list

--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&#39;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&#39;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&#39;t do this then wallets won&#39;t automatically defragment, as=
 we&#39;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 (&quot;I thought bitcoin doe=
sn&#39;t have banks&quot; 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 &quot;free&quot; for =
another output or two. But wallets don&#39;t exploit this today.</div></div=
>

--001a11c38a22b9806f0516ec65f4--