Gavin Andresen [ARCHIVE] on Nostr: 📅 Original date posted:2013-10-24 📝 Original message:On Fri, Oct 25, 2013 at ...
📅 Original date posted:2013-10-24
📝 Original message:On Fri, Oct 25, 2013 at 12:54 AM, Peter Todd <pete at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131025/47fc4c53/attachment.html>;
📝 Original message:On Fri, Oct 25, 2013 at 12:54 AM, Peter Todd <pete at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131025/47fc4c53/attachment.html>;