From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ywztd-0000qQ-KX for bitcoin-development@lists.sourceforge.net; Mon, 25 May 2015 21:26:53 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.99 as permitted sender) client-ip=62.13.148.99; envelope-from=pete@petertodd.org; helo=outmail148099.authsmtp.net; Received: from outmail148099.authsmtp.net ([62.13.148.99]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Ywztb-0000Kg-8s for bitcoin-development@lists.sourceforge.net; Mon, 25 May 2015 21:26:53 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4PLQiuu094572; Mon, 25 May 2015 22:26:44 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4PLQcN2054674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 May 2015 22:26:41 +0100 (BST) Date: Mon, 25 May 2015 17:26:38 -0400 From: Peter Todd To: Mike Hearn Message-ID: <20150525212638.GB12430@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: bc68f103-0324-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAcUFVQNAgsB AmMbWVZeUlt7XWI7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRhh en9NLBtycgFAf3o+ ZERhXXIVDhd8fRB8 Qk1JFW4EYXphaTUa TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDN3Yn Wh8NEC4zHEoDDys0 NVQ8J1IBF0cXPQ0u MVZpQlMKPlcVBEVC H0wvSBJlF35JSyM3 BAlTRkN2 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Ywztb-0000Kg-8s 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 21:26:53 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 25, 2015 at 08:44:18PM +0200, Mike Hearn wrote: > 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. >=20 > The reason they largely don't is just one of manpower. Nobody is working = on > it. >=20 > 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. This can cause problems as until those transactions confirm, even more of the user's outputs are unavailable for spending, causing confusion as to why they can't send their full balance. It's also inefficient, as in the case where the user does try to send a small payment that could be satisfied by one or more of these small UTXO's, the wallet has to use a larger UTXO. With replace-by-fee however this problem goes away, as you can simply double-spend the pending defragmentation transactions instead if they are still unconfirmed when you need to use them. --=20 'peter'[:-1]@petertodd.org 00000000000000000aa9033c06c10d6131eafa3754c3157d74c2267c1dd2ca35 --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVY5OKXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwZmEyODc2ZmNjMGIxMjYxZDJkZWUyMjhlYmM0Yzg3MWYz OTVlNjFkMmU2ODc1YzYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftfgQf9F+G5++Zz5iElo/CNO3tfgwkj M7+bXk5wR9p1C/v6EnZWlgNNToQp7hYhJEUZ0+KY3ocTtJ+dd/uaX0YVa6djZvJ6 lk9veaoBvLSGTSfgXnoJ3eaQJ+MuTq2y4daXbWu+X8OIWaM3lrlll/vmCG9VWyYg SLo1206+H4fxPRBMhjxRvvZXQeMAIXMwio7ESHdOQ/SvfdgNEjYNacfq6RUttaSe ETtUiX//BWLESgtmCt7SS756a//ZRo4HlCECacidcCQlUWqJDhXhS2zsOxb5Hsma 4iQMZySF997N8UlOwFnac5H31viWaT1xN4qtPNqMS0DDx8NhdsgXHaxWHhkQUA== =Swwy -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD--