path: root/42/a41488a9cb355eca5989b3bd6ab10459bdbbe4

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--