Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

[Jeff Garzik <jgarzik@bitpay.com>]

[-- Attachment #1: Type: text/plain, Size: 12181 bytes --]

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/

[-- Attachment #2: Type: text/html, Size: 15471 bytes --]