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

On 05/25/2015 11:05 PM, Peter Todd wrote: > On Mon, May 25, 2015 at 10:29:26PM +0200, Andreas Schildbach wrote: >>> I see this behavior all the time. I am using the latest release, as far as >>> I know. Version 4.30. >>> >>> The same behavior occurs in the Testnet3 variant of the app. Go in there

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

CPFP also solves it just fine. -- 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

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

On Mon, May 25, 2015 at 08:44:18PM +0200, Mike Hearn wrote: > Wallets are incentivised to do a better job with defragmentation already, > as if you have lots of tiny UTXOs then your fees end up being huge when > trying to make a payment. > > The reason they largely don't is just one of manpower. N

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

On Mon, May 25, 2015 at 1:29 PM, Andreas Schildbach wrote: > Yes, that's the issue. Because you're connecting only to one node, you > don't get any instant confirmations -- due to a Bitcoin protocol > limitation you can only get them from nodes you don't post the tx to. Is it really wise to call

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

> > If it matters, I configure the app to connect only to my own trusted > Bitcoin node, so I only ever have one active connection at most. Ah, I see, non default configuration. Because the Bitcoin network can and does change in backwards incompatible ways, the app wants to see that the transacti

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

On Mon, May 25, 2015 at 10:29:26PM +0200, Andreas Schildbach wrote: > > I see this behavior all the time. I am using the latest release, as far as > > I know. Version 4.30. > > > > The same behavior occurs in the Testnet3 variant of the app. Go in there > > with an empty wallet and receive one p

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

On 05/25/2015 10:03 PM, Matt Whitlock wrote: > On Monday, 25 May 2015, at 8:41 pm, Mike Hearn wrote: >>> some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you >>> can only spend confirmed UTXOs. I can't tell you how aggravating it is to >>> have to tell a friend, "Oh, oops, I c

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

On Monday, 25 May 2015, at 8:41 pm, Mike Hearn wrote: > > some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you > > can only spend confirmed UTXOs. I can't tell you how aggravating it is to > > have to tell a friend, "Oh, oops, I can't pay you yet. I have to wait for > > the la

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

Wallets are incentivised to do a better job with defragmentation already, as if you have lots of tiny UTXOs then your fees end up being huge when trying to make a payment. The reason they largely don't is just one of manpower. Nobody is working on it. As a wallet developer myself, one way I'd lik

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

> > some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you > can only spend confirmed UTXOs. I can't tell you how aggravating it is to > have to tell a friend, "Oh, oops, I can't pay you yet. I have to wait for > the last transaction I did to confirm first." All the more aggrava

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

Having thousands of utxos floating around for a single address is clearly a bad thing - it creates a lot of memory load on bitcoin nodes. However, having only one utxo for an address is also a bad thing, for concurrent operations. Having "several" utxos available to spend is good for parallelism,

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

That's a lot of work, a lot of extra utxo's, and a lot of blockchain spam, just so I can do a convoluted form of arithmetic on my balance. If a tx contained an explicit miner fee and a change address, but did not compute the change, letting the network compute it (and therefore merge transactions

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

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

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

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 th

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

I feel your pain. I've had the same thing happen to me in the past. And I agree it's more likely to occur with my proposed scheme but I think with HD wallets there will still be UTXOs left unspent after most transactions since, for privacy sake it's looking for the smallest set of addresses that ca

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

Minimizing the number of UTXOs in a wallet is sometimes not in the best interests of the user. In fact, quite often I've wished for a configuration option like "Try to maintain _[number]_ UTXOs in the wallet." This is because I often want to make multiple spends from my wallet within one block,

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

Makes sense.. So with that said, I'd propose the following criteria for selecting UTXOs: 1. Select the smallest possible set of addresses that can be linked in order to come up with enough BTC to send to the payee. 2. Given multiple possible sets, select the one that has the largest number of UTXO

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

Miners do not care about the age of a UTXO entry, apart for two exceptions. It is also economically irrelevant. * There is a free transaction policy, which sets a small portion of block space aside for transactions which do not pay sufficient fee. This is mostly an altruistic way of encouraging Bit

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

That policy is included in Bitcoin Core.  Miners use it because it is the default.  The policy was likely intended to help real transactions get through in the face of spam.  But it favors those with more bitcoin, as the priority is determined by amount spent multiplied by age of UTXOs.  At the ver

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

On Sat, May 9, 2015 at 2:43 PM, Raystonn wrote: > How about this as a happy medium default policy: Rather than select UTXOs >> based solely on age and limiting the size of the transaction, we select as >> many UTXOs as possible from as few addresses as possible, prioritizing >> which addresses to

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

If selecting older UTXOs gives higher priority for a lesser (or at least not greater) fee, that is an incentive for a rational user to use the older UTXOs.  Such policy needs to be defended or removed.  It doesn't support privacy or a reduction in UTXOs. On 9 May 2015 12:33 pm, Jim Phillips wrote:

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

I think potential fee subsidies for cleaning up UTXO (and/or penalties for creating more UTXO than you burn) are worth thinking about. As Gavin's post ( gavinandresen.ninja/utxo-uhoh ) indicates, UTXO cost is far higher than block storage, so charging differently for the in/out mismatches shoul

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

On Sat, May 9, 2015 at 2:25 PM, Raystonn wrote: > Lack of privacy is viral. We shouldn't encourage policy in most wallets > that discourages privacy. It adversely affects privacy across the entire > network. > How about this as a happy medium default policy: Rather than select UTXOs based solel

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

On Sat, May 9, 2015 at 2:12 PM, Patrick Mccorry (PGR) < patrick.mcco...@newcastle.ac.uk> wrote: > Not necessarily. If you want to ensure privacy, you could limit the > selection of UTXOs to a single address, and even go so far as to send > change back to that same address. This wouldn't be as ef

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

Lack of privacy is viral.  We shouldn't encourage policy in most wallets that discourages privacy.  It adversely affects privacy across the entire network. On 9 May 2015 12:17 pm, Jim Phillips wrote:On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille wrote:It's a very complex

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

On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille wrote: > It's a very complex trade-off, which is hard to optimize for all use > cases. Using more UTXOs requires larger transactions, and thus more fees in > general. > Unless the miner determines that the reduction in UTXO storage requirements is wor

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

On Sat, May 9, 2015 at 2:00 PM, Andreas Schildbach wrote: > Actually your assumption is wrong. Bitcoin Wallet (and I think most, if > not all, other bitcoinj based wallets) picks UTXO by age, in order to > maximize priority. So it keeps the number of UTXOs low, though not as > low as if it would

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

It's a very complex trade-off, which is hard to optimize for all use cases. Using more UTXOs requires larger transactions, and thus more fees in general. In addition, it results in more linkage between coins/addresses used, so lower privacy. The only way you can guarantee an economical reason to k

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

On Sat, May 9, 2015 at 1:45 PM, Peter Todd wrote: > On Sat, May 09, 2015 at 12:09:32PM -0500, Jim Phillips wrote: > > 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 m

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

Actually your assumption is wrong. Bitcoin Wallet (and I think most, if not all, other bitcoinj based wallets) picks UTXO by age, in order to maximize priority. So it keeps the number of UTXOs low, though not as low as if it would always pick *all* UTXOs. On 05/09/2015 07:09 PM, Jim Phillips wrot

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

On Sat, May 09, 2015 at 12:09:32PM -0500, Jim Phillips wrote: > 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

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

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 prot