Re: [Bitcoin-development] Making fee estimation better

[Gavin Andresen <gavinandresen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2959 bytes --]