📅 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>;
Gavin Andresen [ARCHIVE] /
npub1s4…d44kw
2023-06-07 15:07:53
in reply to nevent1q…cev9
Author Public Key
npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:07:53Event JSON
{
"id": "26cbe1f5d231d9857113ded6ad97d7933217901c8786f2969b0af13a74accda1",
"pubkey": "857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4",
"created_at": 1686150473,
"kind": 1,
"tags": [
[
"e",
"82aca9d85d9f8088587f8710d511958183b300f7daa0a8fd33090fc324b509ac",
"",
"root"
],
[
"e",
"f7da0ce1d0ec5fd9fcf482a5be7a775a6a97b9df6b57ca2dc4448296d560ac51",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2013-10-24\n📝 Original message:On Fri, Oct 25, 2013 at 12:54 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e Eligius has contracts to do transaction mining, and it's currently 10%\n\u003e of the hashing power.\n\u003e\n\nYes, and I asked Luke what percentage of that 10% is OOB fee payments, and\nthe answer is \"a small percentage.\"\n\nSo: there are multiple layers of reasons why OOB fee payments will not\nscrew up the fee estimation code:\n\n+ If the transactions are not broadcast, then they have no effect on the\nestimates.\n\n+ If the transactions are broadcast but not relayed because their priority\nand fee are way below current estimates then they will have very close to\nzero effect on the estimates.\n\n+ If the OOB transaction is zero-fee, zero-priority (e.g comes from a\nhigh-tx-volume service and relies on recently spent outputs) it will have\nzero effect on the estimates.\n\n+ If they make up less than about 40% of broadcast transactions they will\nhave very close to zero effect on the fee estimate (because of the\ndistribution of fees and behavior of taking a median)\n\nThe only case where the estimation code is even slightly likely to get\nconfused is estimating the priority needed to get into a block IF there are\na significant number of zero-fee, low-but-not-zero-priority OOB\ntransactions being broadcast.\n\nAnd since priority naturally increases over time, even if that case DOES\noccur the failure is very mild-- it means your free transactions might have\nto build up more priority than the code estimates before successfully\nentering a block. If that gets to be an actual problem, then implementing\nPieter's idea of keeping track of memory pool transactions that are NOT\ngetting mined would fix it. But I don't want to waste time on a theoretical\nproblem when it is very possible miners will decide to stop accepting free\ntransactions alltogether.\n\n\n\nAnd all of the above is completely orthogonal to child-pays-for-parent\nand/or replace-with-higher-fee.\n\nPS: I would appreciate it if you stop saying things like \"Regarding the\ntransaction fee estimate code, it's not very well thought out.\"\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131025/47fc4c53/attachment.html\u003e",
"sig": "ec744ea9f7f85ed5d5d907bf7c2ecc274194c39eada0169ec17fa8f90d3d7238aa979f87dc6dceaff010327a5cc4b47a8257f71a29052fc7c46e1a6010dcabb4"
}