From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: <20150510133525.GD6182@mcelrath.org> From: Jeff Garzik Date: Sun, 10 May 2015 10:33:56 -0400 Message-ID: To: Bob McElrath , Jim Phillips 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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* > > > > > >*"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 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* >> >> >> *"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
This has been frequently explored= on IRC.

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.

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.

Thus a = wallet would have several consolidation targets.

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?

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 p= ractical 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 recei= ver 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 walle= t
software that refuses to spend unconfirmed outputs.

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 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.= =C2=A0 Of
course that has big privacy implications since it directly exposes the chan= ge
address, and is a hard fork, but is much closer to what people expect of a<= br> debit-based "account" in traditional banking.

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.

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<= br> >it
>to this list -- so here goes.
>
>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, 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<= br> >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<= br> >up
>shrinking the UTXO database over time rather than growing it with each<= br> >transaction. Obviously, as Bitcoin gains wider adoption, the UTXO
>database
>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=
>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;<= br> >Blockchain.info; and maybe a few others. The developers of all these >wallets have a vested interest in the continued usefulness of Bitcoin,<= br> >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 transaction= s
>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<= br> >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 behavio= r.
>
>--
>*James G. Phillips IV*
><https://plus.google.com/u/0/113107039501292625391/posts<= /a>>
>
>*"Don't bunt. Aim out of the ball park. Aim for the com= pany 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<= br> >
>!DSPAM:554e4e5450787476022393!
>
>
>-----------------------------------------------------------------------= -
>
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-de= velopment@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoi= n-development
>
>
>!DSPAM:554e4e5450787476022393!

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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.

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.

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

On May 9, 2015 1:09:32 PM EDT, Jim Phill= ips <jim@ergopho= bia.org> wrote:
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.

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.

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.

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

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.

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.

--
James G. Phillips IV=C2=A0=C2=A0
"Don'= t bunt. Aim out of the ball park. Aim for the company of immortals." -= - David Ogilvy

<= div>=C2=A0This message w= as created with 100% recycled electrons. Please think twice before printing= .
!DSPAM:554e4e5450787476022393!

http://ad.doubleclick.net/ddm/clk/290420510;117567292;y

!DSPAM:554e4e5450787476022393!


Bitcoin=
-development mailing list
Bitcoin-development@lists.sourceforge.net<=
/a>
https://lists.sourceforge.net/lists/listinfo/bit=
coin-development


!DSPAM:554e4e5450787476022393!

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
<= br>-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAlVPXp0ACgkQjwioWRGe9K1+2ACfViY0D2ksVFe29SwhxbtmNSC3
TQAAnRoJLI9wW3DQRPqQ7PorKxelC2S2
=3DEr51
-----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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




--
Jeff Garzik
Bitcoin core developer and open source evangelis= t
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--001a113cf46aeefdaa0515bb27a1--