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'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, "Andreas Schildbac= h" <<a href=3D"mailto:andreas@schildbach.de">andreas@schildbach.de<= /a>> 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> > Forgive me if this idea has been suggested before, but I made this<br> > suggestion on reddit and I got some feedback recommending I also bring= <br> > it to this list -- so here goes.<br> ><br> > I wonder if there isn't perhaps a simpler way of dealing with UTXO= <br> > growth. What if, rather than deal with the issue at the protocol level= ,<br> > we deal with it at the source of the problem -- the wallets. Right now= ,<br> > the typical wallet selects only the minimum number of unspent outputs<= br> > when building a transaction. The goal is to keep the transaction size = to<br> > a minimum so that the fee stays low. Consequently, lots of unspent<br> > outputs just don't get used, and are left lying around until some = point<br> > in the future.<br> ><br> > What if we started designing wallets to consolidate unspent outputs?<b= r> > When selecting unspent outputs for a transaction, rather than choosing= <br> > just the minimum number from a particular address, why not select them= <br> > ALL? Take all of the UTXOs from a particular address or wallet, send<b= r> > however much needs to be spent to the payee, and send the rest back to= <br> > the same address or a change address as a single output? Through this<= br> > method, we should wind up shrinking the UTXO database over time rather= <br> > than growing it with each transaction. Obviously, as Bitcoin gains wid= er<br> > adoption, the UTXO database will grow, simply because there are 7<br> > billion people in the world, and eventually a good percentage of them<= br> > will have one or more wallets with spendable bitcoin. But this idea<br= > > could limit the growth at least.<br> ><br> > The vast majority of users are running one of a handful of different<b= r> > wallet apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase;<= br> > Circle; Blockchain.info; and maybe a few others. The developers of all= <br> > these wallets have a vested interest in the continued usefulness of<br= > > Bitcoin, and so should not be opposed to changing their UTXO selection= <br> > algorithms to one that reduces the UTXO database instead of growing it= .<br> ><br> > From the miners perspective, even though these types of transactions<b= r> > would be larger, the fee could stay low. Miners actually benefit from<= br> > them in that it reduces the amount of storage they need to dedicate to= <br> > holding the UTXO. So miners are incentivized to mine these types of<br= > > transactions with a higher priority despite a low fee.<br> ><br> > Relays could also get in on the action and enforce this type of behavi= or<br> > by refusing to relay or deprioritizing the relay of transactions that<= br> > don't use all of the available UTXOs from the addresses used as in= puts.<br> > Relays are not only the ones who benefit the most from a reduction of<= br> > the UTXO database, they're also in the best position to promote go= od<br> > behavior.<br> ><br> > --<br> > *James G. Phillips<br> > IV* <<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>><br> > /"Don't bunt. Aim out of the ball park. Aim for the company o= f<br> > immortals." -- David Ogilvy<br> > /<br> ><br> >=A0 /This message was created with 100% recycled electrons. Please thin= k<br> > twice before printing./<br> ><br> ><br> > ----------------------------------------------------------------------= --------<br> > One dashboard for servers and applications across Physical-Virtual-Clo= ud<br> > Widest out-of-the-box monitoring support with 50+ applications<br> > Performance metrics, stats and reports that give you Actionable Insigh= ts<br> > Deep dive visibility with transaction tracing using APM Insight.<br> > <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> ><br> ><br> ><br> > _______________________________________________<br> > Bitcoin-development mailing list<br> > <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d= evelopment@lists.sourceforge.net</a><br> > <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> ><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--