<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 25, 2013 at 12:54 AM, Peter Todd <span dir="ltr"><<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">Eligius has contracts to do transaction mining, and it's currently 10%</span><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 "a small percentage."</div><div><br></div><div>So: there are multiple layers of reasons why OOB fee payments will not screw up the fee estimation 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 estimates.</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 have very close to zero effect on the fee estimate (because of the distribution 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 are a significant number of zero-fee, low-but-not-zero-priority OOB transactions 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 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.</div>
<div><br></div><div><br></div><div><br></div><div>And all of the above is completely orthogonal to child-pays-for-parent and/or replace-with-higher-fee.<br><br>PS: I would appreciate it if you stop saying things like "<span style="color:rgb(0,0,0);font-family:Verdana,arial,sans-serif;line-height:16.890625px">Regarding the transaction fee estimate code, it's not very well thought out."</span></div>
<div><br></div>-- <br>--<br>Gavin Andresen<br>
</div><div class="gmail_extra"><br></div></div>