From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
Date: Mon, 25 May 2015 17:26:38 -0400 [thread overview]
Message-ID: <20150525212638.GB12430@savin.petertodd.org> (raw)
In-Reply-To: <CANEZrP0DL8yA=neK0DTq0npEqc0q+RvTQD57OndNVg0vi2=yMg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
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.
>
> 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.
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.
--
'peter'[:-1]@petertodd.org
00000000000000000aa9033c06c10d6131eafa3754c3157d74c2267c1dd2ca35
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-05-25 21:26 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-09 17:09 [Bitcoin-development] A suggestion for reducing the size of the UTXO database Jim Phillips
2015-05-09 18:45 ` Peter Todd
2015-05-09 19:02 ` Jim Phillips
2015-05-09 19:00 ` Andreas Schildbach
2015-05-09 19:05 ` Jim Phillips
2015-05-09 19:06 ` Pieter Wuille
2015-05-09 19:16 ` Jim Phillips
2015-05-09 19:43 ` Ross Nicoll
[not found] ` <3862E01F-FD0F-48F5-A6D9-F8E0FB0AB68F@newcastle.ac.uk>
[not found] ` <CANe1mWys1gAO1CgPEpD7rdtXF2KYfvXA6bc0q-rAzg9xOFc-5A@mail.gmail.com>
[not found] ` <8029969D-FD22-43F7-930D-CEC7A87CEAD5@newcastle.ac.uk>
2015-05-09 19:28 ` Jim Phillips
2015-05-10 2:11 ` Matt Whitlock
2015-05-10 12:11 ` Jim Phillips
2015-05-25 18:41 ` Mike Hearn
2015-05-25 20:03 ` Matt Whitlock
2015-05-25 20:29 ` Andreas Schildbach
2015-05-25 21:05 ` Peter Todd
2015-05-26 12:40 ` Andreas Schildbach
2015-05-25 21:14 ` Warren Togami Jr.
2015-05-25 21:12 ` Mike Hearn
2015-05-10 13:35 ` Bob McElrath
2015-05-10 14:33 ` Jeff Garzik
2015-05-10 14:42 ` Bob McElrath
2015-05-12 19:50 ` Danny Thorpe
2015-05-25 18:44 ` Mike Hearn
2015-05-25 21:26 ` Peter Todd [this message]
2015-05-25 22:03 ` Mike Hearn
2015-05-26 0:10 ` [Bitcoin-development] Cost savings by using replace-by-fee, 30-90% Peter Todd
2015-05-26 18:22 ` Danny Thorpe
2015-05-26 18:38 ` Allen Piscitello
2015-05-26 18:42 ` Aaron Voisine
2015-05-26 18:47 ` Adam Back
2015-05-26 20:18 ` Matt Whitlock
2015-05-26 20:30 ` joliver
2015-05-26 20:56 ` Mark Friedenbach
2015-05-26 21:29 ` s7r
2015-05-26 22:06 ` Adam Back
2015-05-27 1:25 ` Peter Todd
2015-05-27 19:28 ` s7r
2015-05-26 22:29 ` Jeff Garzik
2015-05-09 19:25 [Bitcoin-development] A suggestion for reducing the size of the UTXO database Raystonn
2015-05-09 19:33 ` Jim Phillips
2015-05-09 19:43 Raystonn
2015-05-09 19:52 ` Jim Phillips
2015-05-09 20:20 Raystonn
2015-05-09 20:38 ` Pieter Wuille
2015-05-09 21:11 ` Jim Phillips
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150525212638.GB12430@savin.petertodd.org \
--to=pete@petertodd.org \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=mike@plan99.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox