Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.177 as permitted sender)
	client-ip=209.85.212.177; envelope-from=gavinandresen@gmail.com;
	helo=mail-wi0-f177.google.com; 
MIME-Version: 1.0
In-Reply-To: <20131024145447.GA19949@savin>
References: <20131024143043.GA12658@savin>
	<CANEZrP100Lg_1LcFMKx1yWrGTSFb5GZmLmXNbZjPGaiEgOeuwA@mail.gmail.com>
	<20131024144358.GA17142@savin>
	<CANEZrP1TfM+wYbGjUk3+8JJZs6cKZXdb57xGMc=hDr9dQjMMZA@mail.gmail.com>
	<20131024145447.GA19949@savin>
Date: Fri, 25 Oct 2013 06:39:34 +1000
Message-ID: <CABsx9T0T0v=HnRRr6BLKNQOFMBJWrhF4G4SOCJ9DidGJBB8Eow@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c34854afd87304e982a12d
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Making fee estimation better
Precedence: list

--001a11c34854afd87304e982a12d
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Oct 25, 2013 at 12:54 AM, Peter Todd <pete@petertodd.org> wrote:

> Eligius has contracts to do transaction mining, and it's currently 10%
> of the hashing power.
>

Yes, and I asked Luke what percentage of that 10% is OOB fee payments, and
the answer is "a small percentage."

So: there are multiple layers of reasons why OOB fee payments will not
screw up the fee estimation code:

+ If the transactions are not broadcast, then they have no effect on the
estimates.

+ If the transactions are broadcast but not relayed because their priority
and fee are way below current estimates then they will have very close to
zero effect on the estimates.

+ If the OOB transaction is zero-fee, zero-priority (e.g comes from a
high-tx-volume service and relies on recently spent outputs) it will have
zero effect on the estimates.

+ If they make up less than about 40% of broadcast transactions they will
have very close to zero effect on the fee estimate (because of the
distribution of fees and behavior of taking a median)

The only case where the estimation code is even slightly likely to get
confused is estimating the priority needed to get into a block IF there are
a significant number of zero-fee, low-but-not-zero-priority OOB
transactions being broadcast.

And since priority naturally increases over time, even if that case DOES
occur the failure is very mild-- it means your free transactions might have
to build up more priority than the code estimates before successfully
entering a block.  If that gets to be an actual problem, then implementing
Pieter's idea of keeping track of memory pool transactions that are NOT
getting mined would fix it. But I don't want to waste time on a theoretical
problem when it is very possible miners will decide to stop accepting free
transactions alltogether.



And all of the above is completely orthogonal to child-pays-for-parent
and/or replace-with-higher-fee.

PS: I would appreciate it if you stop saying things like "Regarding the
transaction fee estimate code, it's not very well thought out."

-- 
--
Gavin Andresen

--001a11c34854afd87304e982a12d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Oct 25, 2013 at 12:54 AM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(34,34,34)">Elig=
ius has contracts to do transaction mining, and it&#39;s currently 10%</spa=
n><br>
</div>
of the hashing power.<br></blockquote><div><br></div><div>Yes, and I asked =
Luke what percentage of that 10% is OOB fee payments, and the answer is &qu=
ot;a small percentage.&quot;</div><div><br></div><div>So: there are multipl=
e layers of reasons why OOB fee payments will not screw up the fee estimati=
on code:</div>
<div><br></div><div>+ If the transactions are not broadcast, then they have=
 no effect on the estimates.</div><div><br></div><div>+ If the transactions=
 are broadcast but not relayed because their priority and fee are way below=
 current estimates then they will have very close to zero effect on the est=
imates.</div>
<div><br></div><div>+ If the OOB transaction is zero-fee, zero-priority (e.=
g comes from a high-tx-volume service and relies on recently spent outputs)=
 it will have zero effect on the estimates.<br></div><div><br></div><div>
+ If they make up less than about 40% of broadcast transactions they will h=
ave very close to zero effect on the fee estimate (because of the distribut=
ion of fees and behavior of taking a median)</div></div><div><br></div>
<div>The only case where the estimation code is even slightly likely to get=
 confused is estimating the priority needed to get into a block IF there ar=
e a significant number of zero-fee, low-but-not-zero-priority OOB transacti=
ons being broadcast.</div>
<div><br></div><div>And since priority naturally increases over time, even =
if that case DOES occur the failure is very mild-- it means your free trans=
actions might have to build up more priority than the code estimates before=
 successfully entering a block. =A0If that gets to be an actual problem, th=
en implementing Pieter&#39;s idea of keeping track of memory pool transacti=
ons that are NOT getting mined would fix it. But I don&#39;t want to waste =
time on a theoretical problem when it is very possible miners will decide t=
o stop accepting free transactions alltogether.</div>
<div><br></div><div><br></div><div><br></div><div>And all of the above is c=
ompletely orthogonal to child-pays-for-parent and/or replace-with-higher-fe=
e.<br><br>PS: I would appreciate it if you stop saying things like &quot;<s=
pan style=3D"color:rgb(0,0,0);font-family:Verdana,arial,sans-serif;line-hei=
ght:16.890625px">Regarding the transaction fee estimate code, it&#39;s not =
very well thought out.&quot;</span></div>
<div><br></div>-- <br>--<br>Gavin Andresen<br>
</div><div class=3D"gmail_extra"><br></div></div>

--001a11c34854afd87304e982a12d--