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."