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/