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
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
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:
nLockTime 1 OP_CLTV
Where the 1 selects absolute mode, and all others act as OP_NOP's. A
future relative CLTV could
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
On Sat, May 09, 2015 at 12:42:08AM +, Gregory Maxwell wrote:
On Sat, May 9, 2015 at 12:00 AM, Damian Gomez dgomez1...@gmail.com 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 Sat, May 9, 2015 at 12:58 PM, Gavin Andresen gavinandre...@gmail.com
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
-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 store
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's
On Sat, May 9, 2015 at 12:53 PM, Justus Ranvier justusranv...@riseup.net
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
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
23 matches
Mail list logo
