From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YrBWa-0000E6-DL for bitcoin-development@lists.sourceforge.net; Sat, 09 May 2015 20:39:04 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.173 as permitted sender) client-ip=209.85.217.173; envelope-from=pieter.wuille@gmail.com; helo=mail-lb0-f173.google.com; Received: from mail-lb0-f173.google.com ([209.85.217.173]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YrBWZ-0005MG-3N for bitcoin-development@lists.sourceforge.net; Sat, 09 May 2015 20:39:04 +0000 Received: by lbcga7 with SMTP id ga7so72655730lbc.1 for ; Sat, 09 May 2015 13:38:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.87.164 with SMTP id az4mr2875802lab.123.1431203936812; Sat, 09 May 2015 13:38:56 -0700 (PDT) Received: by 10.112.19.7 with HTTP; Sat, 9 May 2015 13:38:56 -0700 (PDT) Received: by 10.112.19.7 with HTTP; Sat, 9 May 2015 13:38:56 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 May 2015 13:38:56 -0700 Message-ID: From: Pieter Wuille To: Raystonn Content-Type: multipart/alternative; boundary=001a11c354c24144a60515ac22bd X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YrBWZ-0005MG-3N Cc: Bitcoin Dev , Andreas Schildbach Subject: Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 20:39:04 -0000 --001a11c354c24144a60515ac22bd Content-Type: text/plain; charset=ISO-8859-1 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 Bitcoin adoption. As a DoS prevention mechanism, there is a requirement that these free transactions are of sufficient priority (computed as BTC-days-destroyed per byte), essentially requiring these transactions to consume another scarce resource, even if not money. * Coinbase transaction outputs can, as a consensus rule, only be spent after 100 confirmations. This is to prevent random reorganisations from invalidating transactions that spend young coinbase transactions (which can't move to the new chain). In addition, wallets also select more confirmed outputs first to consume, for the same reason. On May 9, 2015 1:20 PM, "Raystonn" wrote: > 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 least the amount spent should be removed as a factor, or fees are > unlikely to ever be paid by those who can afford them. We can reassess the > role age plays later. One change at a time is better. > On 9 May 2015 12:52 pm, Jim Phillips wrote: > > 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 use based on the number of UTXOs it contains (more being > preferable) and how old those UTXOs are (in order to reduce the fee)? > > 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. > > Before starting this thread, I had completely forgotten that age was even > a factor in determining which UTXOs to use. Frankly, I can't think of any > reason why miners care how old a particular UTXO is when determining what > fees to charge. I'm sure there is one, I just don't know what it is. I just > tossed it in there as homage to Andreas who pointed out to me that it was > still part of the selection criteria. > > --001a11c354c24144a60515ac22bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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 s= pace aside for transactions which do not pay sufficient fee. This is mostly= an altruistic way of encouraging Bitcoin adoption. As a DoS prevention mec= hanism, there is a requirement that these free transactions are of sufficie= nt priority (computed as BTC-days-destroyed per byte), essentially requirin= g these transactions to consume another scarce resource, even if not money.=
* Coinbase transaction outputs can, as a consensus rule, only be spent afte= r 100 confirmations. This is to prevent random reorganisations from invalid= ating transactions that spend young coinbase transactions (which can't = move to the new chain). In addition, wallets also select more confirmed out= puts first to consume, for the same reason.

On May 9, 2015 1:20 PM, "Raystonn" <= ;raystonn@hotmail.com> wrote= :

Tha= t policy is included in Bitcoin Core.=A0 Miners use it because it is the de= fault.=A0 The policy was likely intended to help real transactions get thro= ugh in the face of spam.=A0 But it favors those with more bitcoin, as the p= riority is determined by amount spent multiplied by age of UTXOs.=A0 At the= very least the amount spent should be removed as a factor, or fees are unl= ikely to ever be paid by those who can afford them.=A0 We can reassess the = role age plays later.=A0 One change at a time is better.

On 9 May 2015 12:52 pm, Jim Phillips <jim@ergophobia.org>= wrote:
On Sat, May 9, 2015 at 2:43 PM, Raystonn <raystonn@hotmail.com= > wrote:
How about this as a happy medium default policy: Ra= ther than select UTXOs based solely on age and limiting the size of the tra= nsaction, we select as many UTXOs as possible from as few addresses as poss= ible, prioritizing which addresses to use based on the number of UTXOs it c= ontains (more being preferable) and how old those UTXOs are (in order to re= duce the fee)?=A0

If selecting older UTXO= s 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.=A0 Such policy ne= eds to be defended or removed.=A0 It doesn't support privacy or a reduc= tion in UTXOs.

Before starting this thread, I had comp= letely forgotten that age was even a factor in determining which UTXOs to u= se. Frankly, I can't think of any reason why miners care how old a part= icular UTXO is when determining what fees to charge. I'm sure there is = one, I just don't know what it is. I just tossed it in there as homage = to Andreas who pointed out to me that it was still part of the selection cr= iteria.
--001a11c354c24144a60515ac22bd--