diff options
author | Jeff Garzik <jgarzik@bitpay.com> | 2015-05-10 10:33:56 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-10 14:34:25 +0000 |
commit | 05b06465da43e0c9a4aed02e4d5436f34eacd378 (patch) | |
tree | 8823488f3c5be10b98444bbc65ab9b42f8aff5fc | |
parent | 25f3629ab7938ac1ebff9c7ef6cb09232c47f1e4 (diff) | |
download | pi-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/a41488a9cb355eca5989b3bd6ab10459bdbbe4 | 689 |
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 "dollar bills" - 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"><<a href=3D"mailto:bob_bitco= +in@mcelrath.org" target=3D"_blank">bob_bitcoin@mcelrath.org</a>></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'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'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'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 "account" 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 <<a href=3D"mailto:jim@ergop= +hobia.org">jim@ergophobia.org</a>> 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<br> +>to this list -- so here goes.<br> +><br> +>I wonder if there isn't perhaps a simpler way of dealing with UTXO<= +br> +>growth.<br> +>What if, rather than deal with the issue at the protocol level, we deal= +<br> +>with it at the source of the problem -- the wallets. Right now, the<br> +>typical<br> +>wallet selects only the minimum number of unspent outputs when building= +<br> +>a<br> +>transaction. The goal is to keep the transaction size to a minimum so<b= +r> +>that<br> +>the fee stays low. Consequently, lots of unspent outputs just don't= + get<br> +>used, and are left lying around until some point in the future.<br> +><br> +>What if we started designing wallets to consolidate unspent outputs?<br= +> +>When<br> +>selecting unspent outputs for a transaction, rather than choosing just<= +br> +>the<br> +>minimum number from a particular address, why not select them ALL? Take= +<br> +>all<br> +>of the UTXOs from a particular address or wallet, send however much<br> +>needs<br> +>to be spent to the payee, and send the rest back to the same address or= +<br> +>a<br> +>change address as a single output? Through this method, we should wind<= +br> +>up<br> +>shrinking the UTXO database over time rather than growing it with each<= +br> +>transaction. Obviously, as Bitcoin gains wider adoption, the UTXO<br> +>database<br> +>will grow, simply because there are 7 billion people in the world, and<= +br> +>eventually a good percentage of them will have one or more wallets with= +<br> +>spendable bitcoin. But this idea could limit the growth at least.<br> +><br> +>The vast majority of users are running one of a handful of different<br= +> +>wallet<br> +>apps: Core, Electrum; Armory; Mycelium; Breadwallet; Coinbase; Circle;<= +br> +>Blockchain.info; and maybe a few others. The developers of all these<br= +> +>wallets have a vested interest in the continued usefulness of Bitcoin,<= +br> +>and<br> +>so should not be opposed to changing their UTXO selection algorithms to= +<br> +>one<br> +>that reduces the UTXO database instead of growing it.<br> +><br> +>>From the miners perspective, even though these types of transaction= +s<br> +>would<br> +>be larger, the fee could stay low. Miners actually benefit from them in= +<br> +>that it reduces the amount of storage they need to dedicate to holding<= +br> +>the<br> +>UTXO. So miners are incentivized to mine these types of transactions<br= +> +>with a<br> +>higher priority despite a low fee.<br> +><br> +>Relays could also get in on the action and enforce this type of<br> +>behavior by<br> +>refusing to relay or deprioritizing the relay of transactions that<br> +>don't<br> +>use all of the available UTXOs from the addresses used as inputs.<br> +>Relays<br> +>are not only the ones who benefit the most from a reduction of the UTXO= +<br> +>database, they're also in the best position to promote good behavio= +r.<br> +><br> +>--<br> +</div></div><span class=3D"">>*James G. Phillips IV*<br> +><<a href=3D"https://plus.google.com/u/0/113107039501292625391/posts"= + target=3D"_blank">https://plus.google.com/u/0/113107039501292625391/posts<= +/a>><br> +><br> +</span>>*"Don't bunt. Aim out of the ball park. Aim for the com= +pany of<br> +>immortals."<br> +>-- David Ogilvy*<br> +><br> +>*This message was created with 100% recycled electrons. Please think<br= +> +>twice<br> +>before printing.*<br> +><br> +><br> +>!DSPAM:554e4e5450787476022393!<br> +><br> +><br> +>-----------------------------------------------------------------------= +-<br> +<span class=3D"">><br> +>-----------------------------------------------------------------------= +-------<br> +>One dashboard for servers and applications across<br> +>Physical-Virtual-Cloud<br> +>Widest out-of-the-box monitoring support with 50+ applications<br> +>Performance metrics, stats and reports that give you Actionable<br> +>Insights<br> +>Deep dive visibility with transaction tracing using APM Insight.<br> +><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> +><br> +</span>>!DSPAM:554e4e5450787476022393!<br> +><br> +><br> +>-----------------------------------------------------------------------= +-<br> +<span class=3D"">><br> +>_______________________________________________<br> +>Bitcoin-development mailing list<br> +><a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-de= +velopment@lists.sourceforge.net</a><br> +><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> +><br> +><br> +</span>>!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'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'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'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" 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 <<a href=3D"mailto:jim@ergophobia.org" target=3D"_blank">jim@ergopho= +bia.org</a>> 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'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'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'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'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>"Don'= +t bunt. Aim out of the ball park. Aim for the company of immortals." -= +- 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-- + + |