summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeff Garzik <jgarzik@bitpay.com>2015-05-10 10:33:56 -0400
committerbitcoindev <bitcoindev@gnusha.org>2015-05-10 14:34:25 +0000
commit05b06465da43e0c9a4aed02e4d5436f34eacd378 (patch)
tree8823488f3c5be10b98444bbc65ab9b42f8aff5fc
parent25f3629ab7938ac1ebff9c7ef6cb09232c47f1e4 (diff)
downloadpi-bitcoindev-05b06465da43e0c9a4aed02e4d5436f34eacd378.tar.gz
pi-bitcoindev-05b06465da43e0c9a4aed02e4d5436f34eacd378.zip
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
-rw-r--r--42/a41488a9cb355eca5989b3bd6ab10459bdbbe4689
1 files changed, 689 insertions, 0 deletions
diff --git a/42/a41488a9cb355eca5989b3bd6ab10459bdbbe4 b/42/a41488a9cb355eca5989b3bd6ab10459bdbbe4
new file mode 100644
index 000000000..bca0adbfe
--- /dev/null
+++ b/42/a41488a9cb355eca5989b3bd6ab10459bdbbe4
@@ -0,0 +1,689 @@
+Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
+ helo=mx.sourceforge.net)
+ by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <jgarzik@bitpay.com>) id 1YrSJF-0003KL-2h
+ for bitcoin-development@lists.sourceforge.net;
+ Sun, 10 May 2015 14:34:25 +0000
+Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of bitpay.com
+ designates 209.85.218.48 as permitted sender)
+ client-ip=209.85.218.48; envelope-from=jgarzik@bitpay.com;
+ helo=mail-oi0-f48.google.com;
+Received: from mail-oi0-f48.google.com ([209.85.218.48])
+ by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
+ (Exim 4.76) id 1YrSJC-0006Xy-5W
+ for bitcoin-development@lists.sourceforge.net;
+ Sun, 10 May 2015 14:34:25 +0000
+Received: by oift201 with SMTP id t201so88321731oif.3
+ for <bitcoin-development@lists.sourceforge.net>;
+ Sun, 10 May 2015 07:34:16 -0700 (PDT)
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20130820;
+ h=x-gm-message-state:mime-version:in-reply-to:references:from:date
+ :message-id:subject:to:cc:content-type;
+ bh=DPsoIXgx5S6C++/oIPTRp/+j8sxK5AUXV/DVt/SG0Nk=;
+ b=jetxZXZXmo72giuKJMeA4X9J7CkCEogth4l8WTKWFjJdFYMmG8g0R+w/qFef8xLRgi
+ d4e9xYCkTVYIsIEeJ90oc40ayClFTJIPvVXl0MAa1Yrmw+gtK32yVIbGcyJezEpWsJTA
+ L00bdGsA6GcqWw9GqyWTYa30ipAEUioa95pA+YiwusYnJ8GBRwAUby8HB8cEehNRBxf3
+ Y9mKJynkWpcivZknS8DQhEGl95+3/021TbDflyJrOS6X2kh2ihhx7o+dhl8DyxCX/T3/
+ XUGk2DpYhs9WBMsSsUt/Qbi67VhHgYBOjp0XLv9p77acNyfuUikvTOTbv7YsqBci7DEm
+ toPg==
+X-Gm-Message-State: ALoCoQmW3F8UFUUYFc3CCcTgOdhIs6iWFy1N+In/f4WJyhFqMXBIiWA8geili/OmC8Abf+2y1Mnx
+X-Received: by 10.202.59.213 with SMTP id i204mr4657798oia.120.1431268456588;
+ Sun, 10 May 2015 07:34:16 -0700 (PDT)
+MIME-Version: 1.0
+Received: by 10.202.108.149 with HTTP; Sun, 10 May 2015 07:33:56 -0700 (PDT)
+In-Reply-To: <20150510133525.GD6182@mcelrath.org>
+References: <CANe1mWzBy8-C+CWfwaOLxJ2wokjy8ytQUh2TkRY_Ummn1BpPzw@mail.gmail.com>
+ <20150510133525.GD6182@mcelrath.org>
+From: Jeff Garzik <jgarzik@bitpay.com>
+Date: Sun, 10 May 2015 10:33:56 -0400
+Message-ID: <CAJHLa0NOQkCk=JGoTyNBz8OgKYy_G+M0+a3DP6fGKjsaWq2-aw@mail.gmail.com>
+To: Bob McElrath <bob_bitcoin@mcelrath.org>, Jim Phillips <jim@ergophobia.org>
+Content-Type: multipart/alternative; boundary=001a113cf46aeefdaa0515bb27a1
+X-Spam-Score: -0.6 (/)
+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
+ 1.0 HTML_MESSAGE BODY: HTML included in message
+ -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
+ author's domain
+ 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
+ 0.0 T_REMOTE_IMAGE Message contains an external image
+ -0.0 AWL AWL: Adjusted score from AWL reputation of From: address
+X-Headers-End: 1YrSJC-0006Xy-5W
+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: Sun, 10 May 2015 14:34:25 -0000
+
+--001a113cf46aeefdaa0515bb27a1
+Content-Type: text/plain; charset=UTF-8
+
+This has been frequently explored on IRC.
+
+My general conclusion is "dollar bills" - pick highly common denominations
+of bitcoins. Aggregate to obtain these denominations, but do not aggregate
+further.
+
+This permits merge avoidance (privacy++), easy coinjoin where many hide in
+the noise (privacy++), wallet dust de-fragmentation, while avoiding the
+over-aggregation problem where you have consolidated down to one output.
+
+Thus a wallet would have several consolidation targets.
+
+Another strategy is simply doubling outputs. Say you pay 0.1 BTC to
+Starbucks. Add another 0.1 BTC output to yourself, and a final change
+output. Who can say which output goes to Starbucks?
+
+There are many iterations and trade-offs between fragmentation and privacy.
+
+
+
+
+
+
+
+
+
+On Sun, May 10, 2015 at 9:35 AM, Bob McElrath <bob_bitcoin@mcelrath.org>
+wrote:
+
+> This is my biggest headache with practical bitcoin usage. I'd love to hear
+> it if
+> anyone has any clever solutions to the wallet/utxo locked problem. Spending
+> unconfirmed outputs really requires a different security model on the part
+> of
+> the receiver than #confirmations, but isn't inherently bad if the receiver
+> has a
+> better security model and knows how to compute the probability that an
+> unconfirmed-spend will get confirmed. Of course the bigger problem is
+> wallet
+> software that refuses to spend unconfirmed outputs.
+>
+> I've thought a bit about a fork/merge design: if the change were computed
+> by the
+> network instead of the submitter, two transactions having the same change
+> address and a common input could be straightforwardly merged or split (in a
+> reorg), where with bitcoin currently it would be considered a
+> double-spend. Of
+> course that has big privacy implications since it directly exposes the
+> change
+> address, and is a hard fork, but is much closer to what people expect of a
+> debit-based "account" in traditional banking.
+>
+> The fact of the matter is that having numerous sequential debits on an
+> account
+> is an extremely common use case, and bitcoin is obtuse in this respect.
+>
+> On May 9, 2015 1:09:32 PM EDT, Jim Phillips <jim@ergophobia.org> wrote:
+> >Forgive me if this idea has been suggested before, but I made this
+> >suggestion on reddit and I got some feedback recommending I also bring
+> >it
+> >to this list -- so here goes.
+> >
+> >I wonder if there isn't perhaps a simpler way of dealing with UTXO
+> >growth.
+> >What if, rather than deal with the issue at the protocol level, we deal
+> >with it at the source of the problem -- the wallets. Right now, the
+> >typical
+> >wallet selects only the minimum number of unspent outputs when building
+> >a
+> >transaction. The goal is to keep the transaction size to a minimum so
+> >that
+> >the fee stays low. Consequently, lots of unspent outputs just don't get
+> >used, and are left lying around until some point in the future.
+> >
+> >What if we started designing wallets to consolidate unspent outputs?
+> >When
+> >selecting unspent outputs for a transaction, rather than choosing just
+> >the
+> >minimum number from a particular address, why not select them ALL? Take
+> >all
+> >of the UTXOs from a particular address or wallet, send however much
+> >needs
+> >to be spent to the payee, and send the rest back to the same address or
+> >a
+> >change address as a single output? Through this method, we should wind
+> >up
+> >shrinking the UTXO database over time rather than growing it with each
+> >transaction. Obviously, as Bitcoin gains wider adoption, the UTXO
+> >database
+> >will grow, simply because there are 7 billion people in the world, and
+> >eventually a good percentage of them will have one or more wallets with
+> >spendable bitcoin. But this idea could limit the growth at least.
+> >
+> >The vast majority of users are running one of a handful of different
+> >wallet
+> >apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle;
+> >Blockchain.info; and maybe a few others. The developers of all these
+> >wallets have a vested interest in the continued usefulness of Bitcoin,
+> >and
+> >so should not be opposed to changing their UTXO selection algorithms to
+> >one
+> >that reduces the UTXO database instead of growing it.
+> >
+> >>From the miners perspective, even though these types of transactions
+> >would
+> >be larger, the fee could stay low. Miners actually benefit from them in
+> >that it reduces the amount of storage they need to dedicate to holding
+> >the
+> >UTXO. So miners are incentivized to mine these types of transactions
+> >with a
+> >higher priority despite a low fee.
+> >
+> >Relays could also get in on the action and enforce this type of
+> >behavior by
+> >refusing to relay or deprioritizing the relay of transactions that
+> >don't
+> >use all of the available UTXOs from the addresses used as inputs.
+> >Relays
+> >are not only the ones who benefit the most from a reduction of the UTXO
+> >database, they're also in the best position to promote good behavior.
+> >
+> >--
+> >*James G. Phillips IV*
+> ><https://plus.google.com/u/0/113107039501292625391/posts>
+> >
+> >*"Don't bunt. Aim out of the ball park. Aim for the company of
+> >immortals."
+> >-- David Ogilvy*
+> >
+> >*This message was created with 100% recycled electrons. Please think
+> >twice
+> >before printing.*
+> >
+> >
+> >!DSPAM:554e4e5450787476022393!
+> >
+> >
+> >------------------------------------------------------------------------
+> >
+>
+> >------------------------------------------------------------------------------
+> >One dashboard for servers and applications across
+> >Physical-Virtual-Cloud
+> >Widest out-of-the-box monitoring support with 50+ applications
+> >Performance metrics, stats and reports that give you Actionable
+> >Insights
+> >Deep dive visibility with transaction tracing using APM Insight.
+> >http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
+> >
+> >!DSPAM:554e4e5450787476022393!
+> >
+> >
+> >------------------------------------------------------------------------
+> >
+> >_______________________________________________
+> >Bitcoin-development mailing list
+> >Bitcoin-development@lists.sourceforge.net
+> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
+> >
+> >
+> >!DSPAM:554e4e5450787476022393!
+>
+> --
+> Sent from my Android device with K-9 Mail. Please excuse my brevity.
+>
+> This is my biggest headache with practical bitcoin usage. I'd love to hear
+> it if anyone has any clever solutions to the wallet/utxo locked problem.
+> Spending unconfirmed outputs really requires a different security model on
+> the part of the receiver than #confirmations, but isn't inherently bad if
+> the receiver has a better security model and knows how to compute the
+> probability that an unconfirmed-spend will get confirmed. Of course the
+> bigger problem is wallet software that refuses to spend unconfirmed outputs.
+>
+> I've thought a bit about a fork/merge design: if the change were computed
+> by the network instead of the submitter, two transactions having the same
+> change address could be straightforwardly merged or split (in a reorg). Of
+> course that has big privacy implications and is pretty far from bitcoin's
+> design, but is much closer to what people expect of a debit-based "account"
+> in traditional banking.
+>
+> The fact of the matter is that having numerous sequential debits on an
+> account is an extremely common use case, and bitcoin is obtuse in this
+> respect.
+>
+> On May 9, 2015 1:09:32 PM EDT, Jim Phillips <jim@ergophobia.org> wrote:
+>>
+>> Forgive me if this idea has been suggested before, but I made this
+>> suggestion on reddit and I got some feedback recommending I also bring it
+>> to this list -- so here goes.
+>>
+>> I wonder if there isn't perhaps a simpler way of dealing with UTXO
+>> growth. What if, rather than deal with the issue at the protocol level, we
+>> deal with it at the source of the problem -- the wallets. Right now, the
+>> typical wallet selects only the minimum number of unspent outputs when
+>> building a transaction. The goal is to keep the transaction size to a
+>> minimum so that the fee stays low. Consequently, lots of unspent outputs
+>> just don't get used, and are left lying around until some point in the
+>> future.
+>>
+>> What if we started designing wallets to consolidate unspent outputs? When
+>> selecting unspent outputs for a transaction, rather than choosing just the
+>> minimum number from a particular address, why not select them ALL? Take all
+>> of the UTXOs from a particular address or wallet, send however much needs
+>> to be spent to the payee, and send the rest back to the same address or a
+>> change address as a single output? Through this method, we should wind up
+>> shrinking the UTXO database over time rather than growing it with each
+>> transaction. Obviously, as Bitcoin gains wider adoption, the UTXO database
+>> will grow, simply because there are 7 billion people in the world, and
+>> eventually a good percentage of them will have one or more wallets with
+>> spendable bitcoin. But this idea could limit the growth at least.
+>>
+>> The vast majority of users are running one of a handful of different
+>> wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase;
+>> Circle; Blockchain.info; and maybe a few others. The developers of all
+>> these wallets have a vested interest in the continued usefulness of
+>> Bitcoin, and so should not be opposed to changing their UTXO selection
+>> algorithms to one that reduces the UTXO database instead of growing it.
+>>
+>> From the miners perspective, even though these types of transactions
+>> would be larger, the fee could stay low. Miners actually benefit from them
+>> in that it reduces the amount of storage they need to dedicate to holding
+>> the UTXO. So miners are incentivized to mine these types of transactions
+>> with a higher priority despite a low fee.
+>>
+>> Relays could also get in on the action and enforce this type of behavior
+>> by refusing to relay or deprioritizing the relay of transactions that don't
+>> use all of the available UTXOs from the addresses used as inputs. Relays
+>> are not only the ones who benefit the most from a reduction of the UTXO
+>> database, they're also in the best position to promote good behavior.
+>>
+>> --
+>> *James G. Phillips IV*
+>> <https://plus.google.com/u/0/113107039501292625391/posts>
+>>
+>> *"Don't bunt. Aim out of the ball park. Aim for the company of
+>> immortals." -- David Ogilvy*
+>>
+>> *This message was created with 100% recycled electrons. Please think
+>> twice before printing.*
+>> !DSPAM:554e4e5450787476022393!
+>>
+>> ------------------------------
+>>
+>> One dashboard for servers and applications across Physical-Virtual-Cloud
+>> Widest out-of-the-box monitoring support with 50+ applications
+>> Performance metrics, stats and reports that give you Actionable Insights
+>> Deep dive visibility with transaction tracing using APM Insight.
+>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
+>>
+>> !DSPAM:554e4e5450787476022393!
+>>
+>> ------------------------------
+>>
+>> Bitcoin-development mailing list
+>> Bitcoin-development@lists.sourceforge.net
+>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
+>>
+>>
+>> !DSPAM:554e4e5450787476022393!
+>>
+>>
+> --
+> Sent from my Android device with K-9 Mail. Please excuse my brevity.
+>
+> -----BEGIN PGP SIGNATURE-----
+> Version: GnuPG v1.4.10 (GNU/Linux)
+>
+> iEYEARECAAYFAlVPXp0ACgkQjwioWRGe9K1+2ACfViY0D2ksVFe29SwhxbtmNSC3
+> TQAAnRoJLI9wW3DQRPqQ7PorKxelC2S2
+> =Er51
+> -----END PGP SIGNATURE-----
+>
+>
+> ------------------------------------------------------------------------------
+> One dashboard for servers and applications across Physical-Virtual-Cloud
+> Widest out-of-the-box monitoring support with 50+ applications
+> Performance metrics, stats and reports that give you Actionable Insights
+> Deep dive visibility with transaction tracing using APM Insight.
+> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
+> _______________________________________________
+> Bitcoin-development mailing list
+> Bitcoin-development@lists.sourceforge.net
+> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
+>
+>
+
+
+--
+Jeff Garzik
+Bitcoin core developer and open source evangelist
+BitPay, Inc. https://bitpay.com/
+
+--001a113cf46aeefdaa0515bb27a1
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><div><div><div><div><div>This has been frequently explored=
+ on IRC.<br><br></div>My general conclusion is &quot;dollar bills&quot; - p=
+ick highly common denominations of bitcoins.=C2=A0 Aggregate to obtain thes=
+e denominations, but do not aggregate further.<br><br></div>This permits me=
+rge avoidance (privacy++), easy coinjoin where many hide in the noise (priv=
+acy++), wallet dust de-fragmentation, while avoiding the over-aggregation p=
+roblem where you have consolidated down to one output.<br><br></div>Thus a =
+wallet would have several consolidation targets.<br><br></div>Another strat=
+egy is simply doubling outputs.=C2=A0 Say you pay 0.1 BTC to Starbucks.=C2=
+=A0 Add another 0.1 BTC output to yourself, and a final change output.=C2=
+=A0 Who can say which output goes to Starbucks?<br><br></div>There are many=
+ iterations and trade-offs between fragmentation and privacy.<br><br><br><d=
+iv><br><div><br><br><div><br><br><div><br></div></div></div></div></div><di=
+v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, May 10, 2015=
+ at 9:35 AM, Bob McElrath <span dir=3D"ltr">&lt;<a href=3D"mailto:bob_bitco=
+in@mcelrath.org" target=3D"_blank">bob_bitcoin@mcelrath.org</a>&gt;</span> =
+wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
+er-left:1px #ccc solid;padding-left:1ex">This is my biggest headache with p=
+ractical bitcoin usage. I&#39;d love to hear it if<br>
+anyone has any clever solutions to the wallet/utxo locked problem. Spending=
+<br>
+unconfirmed outputs really requires a different security model on the part =
+of<br>
+the receiver than #confirmations, but isn&#39;t inherently bad if the recei=
+ver has a<br>
+better security model and knows how to compute the probability that an<br>
+unconfirmed-spend will get confirmed. Of course the bigger problem is walle=
+t<br>
+software that refuses to spend unconfirmed outputs.<br>
+<br>
+I&#39;ve thought a bit about a fork/merge design: if the change were comput=
+ed by the<br>
+network instead of the submitter, two transactions having the same change<b=
+r>
+address and a common input could be straightforwardly merged or split (in a=
+<br>
+reorg), where with bitcoin currently it would be considered a double-spend.=
+=C2=A0 Of<br>
+course that has big privacy implications since it directly exposes the chan=
+ge<br>
+address, and is a hard fork, but is much closer to what people expect of a<=
+br>
+debit-based &quot;account&quot; in traditional banking.<br>
+<br>
+The fact of the matter is that having numerous sequential debits on an acco=
+unt<br>
+is an extremely common use case, and bitcoin is obtuse in this respect.<br>
+<div><div class=3D"h5"><br>
+On May 9, 2015 1:09:32 PM EDT, Jim Phillips &lt;<a href=3D"mailto:jim@ergop=
+hobia.org">jim@ergophobia.org</a>&gt; wrote:<br>
+&gt;Forgive me if this idea has been suggested before, but I made this<br>
+&gt;suggestion on reddit and I got some feedback recommending I also bring<=
+br>
+&gt;it<br>
+&gt;to this list -- so here goes.<br>
+&gt;<br>
+&gt;I wonder if there isn&#39;t perhaps a simpler way of dealing with UTXO<=
+br>
+&gt;growth.<br>
+&gt;What if, rather than deal with the issue at the protocol level, we deal=
+<br>
+&gt;with it at the source of the problem -- the wallets. Right now, the<br>
+&gt;typical<br>
+&gt;wallet selects only the minimum number of unspent outputs when building=
+<br>
+&gt;a<br>
+&gt;transaction. The goal is to keep the transaction size to a minimum so<b=
+r>
+&gt;that<br>
+&gt;the fee stays low. Consequently, lots of unspent outputs just don&#39;t=
+ get<br>
+&gt;used, and are left lying around until some point in the future.<br>
+&gt;<br>
+&gt;What if we started designing wallets to consolidate unspent outputs?<br=
+>
+&gt;When<br>
+&gt;selecting unspent outputs for a transaction, rather than choosing just<=
+br>
+&gt;the<br>
+&gt;minimum number from a particular address, why not select them ALL? Take=
+<br>
+&gt;all<br>
+&gt;of the UTXOs from a particular address or wallet, send however much<br>
+&gt;needs<br>
+&gt;to be spent to the payee, and send the rest back to the same address or=
+<br>
+&gt;a<br>
+&gt;change address as a single output? Through this method, we should wind<=
+br>
+&gt;up<br>
+&gt;shrinking the UTXO database over time rather than growing it with each<=
+br>
+&gt;transaction. Obviously, as Bitcoin gains wider adoption, the UTXO<br>
+&gt;database<br>
+&gt;will grow, simply because there are 7 billion people in the world, and<=
+br>
+&gt;eventually a good percentage of them will have one or more wallets with=
+<br>
+&gt;spendable bitcoin. But this idea could limit the growth at least.<br>
+&gt;<br>
+&gt;The vast majority of users are running one of a handful of different<br=
+>
+&gt;wallet<br>
+&gt;apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle;<=
+br>
+&gt;Blockchain.info; and maybe a few others. The developers of all these<br=
+>
+&gt;wallets have a vested interest in the continued usefulness of Bitcoin,<=
+br>
+&gt;and<br>
+&gt;so should not be opposed to changing their UTXO selection algorithms to=
+<br>
+&gt;one<br>
+&gt;that reduces the UTXO database instead of growing it.<br>
+&gt;<br>
+&gt;&gt;From the miners perspective, even though these types of transaction=
+s<br>
+&gt;would<br>
+&gt;be larger, the fee could stay low. Miners actually benefit from them in=
+<br>
+&gt;that it reduces the amount of storage they need to dedicate to holding<=
+br>
+&gt;the<br>
+&gt;UTXO. So miners are incentivized to mine these types of transactions<br=
+>
+&gt;with a<br>
+&gt;higher priority despite a low fee.<br>
+&gt;<br>
+&gt;Relays could also get in on the action and enforce this type of<br>
+&gt;behavior by<br>
+&gt;refusing to relay or deprioritizing the relay of transactions that<br>
+&gt;don&#39;t<br>
+&gt;use all of the available UTXOs from the addresses used as inputs.<br>
+&gt;Relays<br>
+&gt;are not only the ones who benefit the most from a reduction of the UTXO=
+<br>
+&gt;database, they&#39;re also in the best position to promote good behavio=
+r.<br>
+&gt;<br>
+&gt;--<br>
+</div></div><span class=3D"">&gt;*James G. Phillips IV*<br>
+&gt;&lt;<a href=3D"https://plus.google.com/u/0/113107039501292625391/posts"=
+ target=3D"_blank">https://plus.google.com/u/0/113107039501292625391/posts<=
+/a>&gt;<br>
+&gt;<br>
+</span>&gt;*&quot;Don&#39;t bunt. Aim out of the ball park. Aim for the com=
+pany of<br>
+&gt;immortals.&quot;<br>
+&gt;-- David Ogilvy*<br>
+&gt;<br>
+&gt;*This message was created with 100% recycled electrons. Please think<br=
+>
+&gt;twice<br>
+&gt;before printing.*<br>
+&gt;<br>
+&gt;<br>
+&gt;!DSPAM:554e4e5450787476022393!<br>
+&gt;<br>
+&gt;<br>
+&gt;-----------------------------------------------------------------------=
+-<br>
+<span class=3D"">&gt;<br>
+&gt;-----------------------------------------------------------------------=
+-------<br>
+&gt;One dashboard for servers and applications across<br>
+&gt;Physical-Virtual-Cloud<br>
+&gt;Widest out-of-the-box monitoring support with 50+ applications<br>
+&gt;Performance metrics, stats and reports that give you Actionable<br>
+&gt;Insights<br>
+&gt;Deep dive visibility with transaction tracing using APM Insight.<br>
+&gt;<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" tar=
+get=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><=
+br>
+&gt;<br>
+</span>&gt;!DSPAM:554e4e5450787476022393!<br>
+&gt;<br>
+&gt;<br>
+&gt;-----------------------------------------------------------------------=
+-<br>
+<span class=3D"">&gt;<br>
+&gt;_______________________________________________<br>
+&gt;Bitcoin-development mailing list<br>
+&gt;<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-de=
+velopment@lists.sourceforge.net</a><br>
+&gt;<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develop=
+ment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoi=
+n-development</a><br>
+&gt;<br>
+&gt;<br>
+</span>&gt;!DSPAM:554e4e5450787476022393!<br>
+<span class=3D"HOEnZb"><font color=3D"#888888"><br>
+--<br>
+Sent from my Android device with K-9 Mail. Please excuse my brevity.<br>
+</font></span><br><div>This is my biggest headache with practical bitcoin u=
+sage. I&#39;d love to hear it if anyone has any clever solutions to the wal=
+let/utxo locked problem. Spending unconfirmed outputs really requires a dif=
+ferent security model on the part of the receiver than #confirmations, but =
+isn&#39;t inherently bad if the receiver has a better security model and kn=
+ows how to compute the probability that an unconfirmed-spend will get confi=
+rmed. Of course the bigger problem is wallet software that refuses to spend=
+ unconfirmed outputs.<br>
+<br>
+I&#39;ve thought a bit about a fork/merge design: if the change were comput=
+ed by the network instead of the submitter, two transactions having the sam=
+e change address could be straightforwardly merged or split (in a reorg). O=
+f course that has big privacy implications and is pretty far from bitcoin&#=
+39;s design, but is much closer to what people expect of a debit-based &quo=
+t;account&quot; in traditional banking.<br>
+<br>
+The fact of the matter is that having numerous sequential debits on an acco=
+unt is an extremely common use case, and bitcoin is obtuse in this respect.=
+<br><br><div class=3D"gmail_quote">On May 9, 2015 1:09:32 PM EDT, Jim Phill=
+ips &lt;<a href=3D"mailto:jim@ergophobia.org" target=3D"_blank">jim@ergopho=
+bia.org</a>&gt; wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0pt=
+ 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+<div dir=3D"ltr"><div>Forgive me if this idea has been suggested before, bu=
+t I made this suggestion on reddit and I got some feedback recommending I a=
+lso bring it to this list -- so here goes.</div><div><br></div><div>I wonde=
+r if there isn&#39;t perhaps a simpler way of dealing with UTXO growth. Wha=
+t if, rather than deal with the issue at the protocol level, we deal with i=
+t at the source of the problem -- the wallets. Right now, the typical walle=
+t selects only the minimum number of unspent outputs when building a transa=
+ction. The goal is to keep the transaction size to a minimum so that the fe=
+e stays low. Consequently, lots of unspent outputs just don&#39;t get used,=
+ and are left lying around until some point in the future.</div><div><br></=
+div><div>What if we started designing wallets to consolidate unspent output=
+s? When selecting unspent outputs for a transaction, rather than choosing j=
+ust the minimum number from a particular address, why not select them ALL? =
+Take all of the UTXOs from a particular address or wallet, send however muc=
+h needs to be spent to the payee, and send the rest back to the same addres=
+s or a change address as a single output? Through this method, we should wi=
+nd up shrinking the UTXO database over time rather than growing it with eac=
+h transaction. Obviously, as Bitcoin gains wider adoption, the UTXO databas=
+e will grow, simply because there are 7 billion people in the world, and ev=
+entually a good percentage of them will have one or more wallets with spend=
+able bitcoin. But this idea could limit the growth at least.</div><div><br>=
+</div><div>The vast majority of users are running one of a handful of diffe=
+rent wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; =
+Circle; Blockchain.info; and maybe a few others. The developers of all thes=
+e wallets have a vested interest in the continued usefulness of Bitcoin, an=
+d so should not be opposed to changing their UTXO selection algorithms to o=
+ne that reduces the UTXO database instead of growing it.</div><div><br></di=
+v><div>From the miners perspective, even though these types of transactions=
+ would be larger, the fee could stay low. Miners actually benefit from them=
+ in that it reduces the amount of storage they need to dedicate to holding =
+the UTXO. So miners are incentivized to mine these types of transactions wi=
+th a higher priority despite a low fee.</div><div><br></div><div>Relays cou=
+ld also get in on the action and enforce this type of behavior by refusing =
+to relay or deprioritizing the relay of transactions that don&#39;t use all=
+ of the available UTXOs from the addresses used as inputs. Relays are not o=
+nly the ones who benefit the most from a reduction of the UTXO database, th=
+ey&#39;re also in the best position to promote good behavior.</div><div><di=
+v><div><br></div><div>--<div><b>James G. Phillips IV</b>=C2=A0<a href=3D"ht=
+tps://plus.google.com/u/0/113107039501292625391/posts" style=3D"font-size:x=
+-small" target=3D"_blank"><img src=3D"https://ssl.gstatic.com/images/icons/=
+gplus-16.png"></a>=C2=A0</div></div><div><font size=3D"1"><i>&quot;Don&#39;=
+t bunt. Aim out of the ball park. Aim for the company of immortals.&quot; -=
+- David Ogilvy<br></i></font><div><font size=3D"1"><br></font></div></div><=
+div><font size=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fugu=
+e/16/leaf.png">=C2=A0<em style=3D"font-family:verdana,geneva,sans-serif;lin=
+e-height:16px;color:green;background-color:rgb(255,255,255)">This message w=
+as created with 100% recycled electrons. Please think twice before printing=
+.</em></font></div></div></div>
+</div>
+
+
+!DSPAM:554e4e5450787476022393!
+<p style=3D"margin-top:2.5em;margin-bottom:1em;border-bottom:1px solid #000=
+"></p><pre><hr><br>One dashboard for servers and applications across Physic=
+al-Virtual-Cloud <br>Widest out-of-the-box monitoring support with 50+ appl=
+ications<br>Performance metrics, stats and reports that give you Actionable=
+ Insights<br>Deep dive visibility with transaction tracing using APM Insigh=
+t.<br><a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" t=
+arget=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a=
+><br><br>!DSPAM:554e4e5450787476022393!<br></pre><p style=3D"margin-top:2.5=
+em;margin-bottom:1em;border-bottom:1px solid #000"></p><pre><hr><br>Bitcoin=
+-development mailing list<br><a href=3D"mailto:Bitcoin-development@lists.so=
+urceforge.net" target=3D"_blank">Bitcoin-development@lists.sourceforge.net<=
+/a><br><a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-deve=
+lopment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bit=
+coin-development</a><br><br><br>!DSPAM:554e4e5450787476022393!<br></pre></b=
+lockquote></div><br>
+-- <br>
+Sent from my Android device with K-9 Mail. Please excuse my brevity.</div><=
+br>-----BEGIN PGP SIGNATURE-----<br>
+Version: GnuPG v1.4.10 (GNU/Linux)<br>
+<br>
+iEYEARECAAYFAlVPXp0ACgkQjwioWRGe9K1+2ACfViY0D2ksVFe29SwhxbtmNSC3<br>
+TQAAnRoJLI9wW3DQRPqQ7PorKxelC2S2<br>
+=3DEr51<br>
+-----END PGP SIGNATURE-----<br>
+<br>-----------------------------------------------------------------------=
+-------<br>
+One dashboard for servers and applications across Physical-Virtual-Cloud<br=
+>
+Widest out-of-the-box monitoring support with 50+ applications<br>
+Performance metrics, stats and reports that give you Actionable Insights<br=
+>
+Deep dive visibility with transaction tracing using APM Insight.<br>
+<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
+=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
+_______________________________________________<br>
+Bitcoin-development mailing list<br>
+<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
+pment@lists.sourceforge.net</a><br>
+<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
+" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
+velopment</a><br>
+<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
+_signature">Jeff Garzik<br>Bitcoin core developer and open source evangelis=
+t<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" targe=
+t=3D"_blank">https://bitpay.com/</a></div>
+</div>
+
+--001a113cf46aeefdaa0515bb27a1--
+
+