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
with an
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 can't pay
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 aggravating
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
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 last
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 payment
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
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.
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,
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
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
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
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
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
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 very
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,
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
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
On Sat, May 9, 2015 at 1:45 PM, Peter Todd p...@petertodd.org 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;
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
On Sat, May 9, 2015 at 2:00 PM, Andreas Schildbach andr...@schildbach.de
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
On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille pieter.wui...@gmail.com
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
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 j...@ergophobia.org wrote:On Sat, May 9, 2015 at 2:06 PM, Pieter Wuille pieter.wuille@gmail.com wrote:Its
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
On Sat, May 9, 2015 at 2:25 PM, Raystonn rayst...@hotmail.com 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
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
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
On Sat, May 9, 2015 at 2:43 PM, Raystonn rayst...@hotmail.com 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
28 matches
Mail list logo
