path: root/17/4c2a97b25423ef9e877c3f4d1f0f322749bef9

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pieter.wuille@gmail.com>) id 1YrA4s-0001F5-HK
	for bitcoin-development@lists.sourceforge.net;
	Sat, 09 May 2015 19:06:22 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.177 as permitted sender)
	client-ip=209.85.217.177; envelope-from=pieter.wuille@gmail.com;
	helo=mail-lb0-f177.google.com; 
Received: from mail-lb0-f177.google.com ([209.85.217.177])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YrA4q-0006Ge-Gh
	for bitcoin-development@lists.sourceforge.net;
	Sat, 09 May 2015 19:06:22 +0000
Received: by lbbuc2 with SMTP id uc2so71846306lbb.2
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 09 May 2015 12:06:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.203.162 with SMTP id kr2mr2689749lac.68.1431198374027;
	Sat, 09 May 2015 12:06:14 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Sat, 9 May 2015 12:06:13 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Sat, 9 May 2015 12:06:13 -0700 (PDT)
In-Reply-To: <millgi$3uv$1@ger.gmane.org>
References: <CANe1mWzBy8-C+CWfwaOLxJ2wokjy8ytQUh2TkRY_Ummn1BpPzw@mail.gmail.com>
	<millgi$3uv$1@ger.gmane.org>
Date: Sat, 9 May 2015 12:06:13 -0700
Message-ID: <CAPg+sBiNLtDNqHML1n7UJC_hYtYCOjBuYNh-bZT8msVh9UKFUg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=001a11346326afe90b0515aad653
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(pieter.wuille[at]gmail.com)
	-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
X-Headers-End: 1YrA4q-0006Ge-Gh
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: Sat, 09 May 2015 19:06:22 -0000

--001a11346326afe90b0515aad653
Content-Type: text/plain; charset=ISO-8859-1

It's a very complex trade-off, which is hard to optimize for all use cases.
Using more UTXOs requires larger transactions, and thus more fees in
general. In addition, it results in more linkage between coins/addresses
used, so lower privacy.

The only way you can guarantee an economical reason to keep the UTXO set
small is by actually having a consensus rule that punishes increasing its
size.
On May 9, 2015 12:02 PM, "Andreas Schildbach" <andreas@schildbach.de> wrote:

> Actually your assumption is wrong. Bitcoin Wallet (and I think most, if
> not all, other bitcoinj based wallets) picks UTXO by age, in order to
> maximize priority. So it keeps the number of UTXOs low, though not as
> low as if it would always pick *all* UTXOs.
>
>
> On 05/09/2015 07:09 PM, Jim Phillips 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./
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>

--001a11346326afe90b0515aad653
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">It&#39;s a very complex trade-off, which is hard to optimize=
 for all use cases. Using more UTXOs requires larger transactions, and thus=
 more fees in general. In addition, it results in more linkage between coin=
s/addresses used, so lower privacy.</p>
<p dir=3D"ltr">The only way you can guarantee an economical reason to keep =
the UTXO set small is by actually having a consensus rule that punishes inc=
reasing its size.</p>
<div class=3D"gmail_quote">On May 9, 2015 12:02 PM, &quot;Andreas Schildbac=
h&quot; &lt;<a href=3D"mailto:andreas@schildbach.de">andreas@schildbach.de<=
/a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Actua=
lly your assumption is wrong. Bitcoin Wallet (and I think most, if<br>
not all, other bitcoinj based wallets) picks UTXO by age, in order to<br>
maximize priority. So it keeps the number of UTXOs low, though not as<br>
low as if it would always pick *all* UTXOs.<br>
<br>
<br>
On 05/09/2015 07:09 PM, Jim Phillips 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 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. What if, rather than deal with the issue at the protocol level=
,<br>
&gt; we deal with it at the source of the problem -- the wallets. Right now=
,<br>
&gt; the typical wallet selects only the minimum number of unspent outputs<=
br>
&gt; when building a transaction. The goal is to keep the transaction size =
to<br>
&gt; a minimum so that the fee stays low. Consequently, lots of unspent<br>
&gt; outputs just don&#39;t get used, and are left lying around until some =
point<br>
&gt; in the future.<br>
&gt;<br>
&gt; What if we started designing wallets to consolidate unspent outputs?<b=
r>
&gt; When selecting unspent outputs for a transaction, rather than choosing=
<br>
&gt; just the minimum number from a particular address, why not select them=
<br>
&gt; ALL? Take all of the UTXOs from a particular address or wallet, send<b=
r>
&gt; however much needs to be spent to the payee, and send the rest back to=
<br>
&gt; the same address or a change address as a single output? Through this<=
br>
&gt; method, we should wind up shrinking the UTXO database over time rather=
<br>
&gt; than growing it with each transaction. Obviously, as Bitcoin gains wid=
er<br>
&gt; adoption, the UTXO database will grow, simply because there are 7<br>
&gt; billion people in the world, and eventually a good percentage of them<=
br>
&gt; will have one or more wallets with spendable bitcoin. But this idea<br=
>
&gt; could limit the growth at least.<br>
&gt;<br>
&gt; The vast majority of users are running one of a handful of different<b=
r>
&gt; wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase;<=
br>
&gt; Circle; Blockchain.info; and maybe a few others. The developers of all=
<br>
&gt; these wallets have a vested interest in the continued usefulness of<br=
>
&gt; Bitcoin, and so should not be opposed to changing their UTXO selection=
<br>
&gt; algorithms to one that reduces the UTXO database instead of growing it=
.<br>
&gt;<br>
&gt; From the miners perspective, even though these types of transactions<b=
r>
&gt; would be larger, the fee could stay low. Miners actually benefit from<=
br>
&gt; them in that it reduces the amount of storage they need to dedicate to=
<br>
&gt; holding the UTXO. So miners are incentivized to mine these types of<br=
>
&gt; transactions with a higher priority despite a low fee.<br>
&gt;<br>
&gt; Relays could also get in on the action and enforce this type of behavi=
or<br>
&gt; by refusing to relay or deprioritizing the relay of transactions that<=
br>
&gt; don&#39;t use all of the available UTXOs from the addresses used as in=
puts.<br>
&gt; Relays are not only the ones who benefit the most from a reduction of<=
br>
&gt; the UTXO database, they&#39;re also in the best position to promote go=
od<br>
&gt; behavior.<br>
&gt;<br>
&gt; --<br>
&gt; *James G. Phillips<br>
&gt; IV* &lt;<a href=3D"https://plus.google.com/u/0/113107039501292625391/p=
osts" target=3D"_blank">https://plus.google.com/u/0/113107039501292625391/p=
osts</a>&gt;<br>
&gt; /&quot;Don&#39;t bunt. Aim out of the ball park. Aim for the company o=
f<br>
&gt; immortals.&quot; -- David Ogilvy<br>
&gt; /<br>
&gt;<br>
&gt;=A0 /This message was created with 100% recycled electrons. Please thin=
k<br>
&gt; twice before printing./<br>
&gt;<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt; One dashboard for servers and applications across Physical-Virtual-Clo=
ud<br>
&gt; Widest out-of-the-box monitoring support with 50+ applications<br>
&gt; Performance metrics, stats and reports that give you Actionable Insigh=
ts<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" ta=
rget=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a>=
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
&gt;<br>
<br>
<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>
</blockquote></div>

--001a11346326afe90b0515aad653--