diff options
| author | Pieter Wuille <pieter.wuille@gmail.com> | 2015-05-09 12:06:13 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-09 19:06:22 +0000 |
| commit | 44f6e36e13e84aee1107d4d02c8fa40c8cbb35c1 (patch) | |
| tree | 478b0a9a2b3b15eef31e9df1513f9b6a47dca489 | |
| parent | e77730e89319a832d094d8fa653029f9e9743d95 (diff) | |
| download | pi-bitcoindev-44f6e36e13e84aee1107d4d02c8fa40c8cbb35c1.tar.gz pi-bitcoindev-44f6e36e13e84aee1107d4d02c8fa40c8cbb35c1.zip | |
Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database
| -rw-r--r-- | 17/4c2a97b25423ef9e877c3f4d1f0f322749bef9 | 332 |
1 files changed, 332 insertions, 0 deletions
diff --git a/17/4c2a97b25423ef9e877c3f4d1f0f322749bef9 b/17/4c2a97b25423ef9e877c3f4d1f0f322749bef9 new file mode 100644 index 000000000..597f4d4ff --- /dev/null +++ b/17/4c2a97b25423ef9e877c3f4d1f0f322749bef9 @@ -0,0 +1,332 @@ +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-- + + |