From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Mon, 25 May 2015 20:44:18 +0200 X-Google-Sender-Auth: -WepOnTMuHJ3O3CdCdZT2klXqv0 Message-ID: From: Mike Hearn To: Jim Phillips 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.

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 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.

= 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 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.
--001a11c38a22b9806f0516ec65f4--