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,
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
On Sat, May 9, 2015 at 12:53 PM, Justus Ranvier
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/09/2015 02:02 PM, Andrew wrote:
> > The nice thing about 1 MB is that you can store ALL bitcoin
> > transactions relevant to your lifetime (~100 years) on one 5 TB
> > hard drive (1*
On Sat, May 09, 2015 at 01:36:56AM +0300, Joel Joonatan Kaartinen wrote:
> such a contract is a possibility, but why would big owners give an
> exclusive right to such pools? It seems to me it'd make sense to offer
> those for any miner as long as the get paid a little for it. Especially
> when it'
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
On Sat, May 09, 2015 at 12:42:08AM +, Gregory Maxwell wrote:
> On Sat, May 9, 2015 at 12:00 AM, Damian Gomez wrote:
> > where w represents the weight of the total number of semantical
> > constraints that an idivdual has expressed throught emotivoe packets that I
> > am working on (implementat
On Sat, May 9, 2015 at 12:58 PM, Gavin Andresen
wrote:
> RE: fixing sigop counting, and building in UTXO cost: great idea! One of
> the problems with this debate is it is easy for great ideas get lost in all
> the noise.
>
If the UTXO set cost is built in, UTXO database entries suddenly are wort
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/09/2015 02:02 PM, Andrew wrote:
> The nice thing about 1 MB is that you can store ALL bitcoin
> transactions relevant to your lifetime (~100 years) on one 5 TB
> hard drive (1*6*24*365*100=5256000). Any regular person can run a
> full node and st
The nice thing about 1 MB is that you can store ALL bitcoin transactions
relevant to your lifetime (~100 years) on one 5 TB hard drive
(1*6*24*365*100=5256000). Any regular person can run a full node and store
this 5 TB hard drive easily at their home. With 10 MB blocks you need a 50
TB drive just
RE: fixing sigop counting, and building in UTXO cost: great idea! One of
the problems with this debate is it is easy for great ideas get lost in all
the noise.
RE: a hard upper limit, with a dynamic limit under it:
I like that idea. Can we drill down on the hard upper limit?
There are lots of pe
On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote:
> > That said, if people have strong feelings about this, I would be willing
> > to make OP_CLTV work as follows:
> >
> > 1 OP_CLTV
> >
> > Where the 1 selects absolute mode, and all others act as OP_NOP's. A
> > future relative CLTV co
25 matches
Mail list logo