📅 Original date posted:2015-10-28
📝 Original message:Assigning 5% of block space based on bitcoin-days destroyed (BDD) and the other 95% based on fees seems like a rather awkward approach to me. For one thing, it means two code paths in pretty much every procedure dealing with a constrained resource (e.g. mempool, CNB). This makes code harder two write, harder to maintain, and slower to execute. As a result, some people have proposed eliminating BDD priority altogether. I have another idea.
We can create and maintain a conversion rate between BDD and fees to create a composite priority metric. Then we just do compPrio = BDD * conversionRate + txFee.
How do we calculate conversionRate? We want the following equation to be true:
sum(fees) = sum(BDD) * conversionRate * BDDweight
So we sum up the mempool fees, and we sum up the mempool BDD. We get a policy statement from the command line for a relative weight of BDD vs fees (default 0.05), and then conversionRate = (summedFees / summedBDD) * BDDWeight.
As an optimization, rather than scanning over the whole mempool to calculate this, we can just store the sum and add or subtract from it each time a tx enters or leaves the mempool. In order to minimize drift (the BDD for a transaction changes over time), we recalculate the whole thing each time a new block is found.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151027/bb663efd/attachment.sig>;
Jonathan Toomim [ARCHIVE] /
npub1pl…yj0hj
2023-06-07 17:43:57
in reply to nevent1q…yeha
Author Public Key
npub1pl6kcz00s7wgn6syh73dta0qm9sqpmtw4adv8rnm2w9fmynkw45sayj0hjPublished at
2023-06-07 17:43:57Event JSON
{
"id": "3799a7bfd50401bba31a0b17386586d24d528b90ea097da75a738c93b92a7ca8",
"pubkey": "0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569",
"created_at": 1686159837,
"kind": 1,
"tags": [
[
"e",
"93557ab0aef94db809afdc494022874351bbc3b58a89c29ef9856e022ac0eb23",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-10-28\n📝 Original message:Assigning 5% of block space based on bitcoin-days destroyed (BDD) and the other 95% based on fees seems like a rather awkward approach to me. For one thing, it means two code paths in pretty much every procedure dealing with a constrained resource (e.g. mempool, CNB). This makes code harder two write, harder to maintain, and slower to execute. As a result, some people have proposed eliminating BDD priority altogether. I have another idea.\n\nWe can create and maintain a conversion rate between BDD and fees to create a composite priority metric. Then we just do compPrio = BDD * conversionRate + txFee.\n\nHow do we calculate conversionRate? We want the following equation to be true:\n\nsum(fees) = sum(BDD) * conversionRate * BDDweight\n\nSo we sum up the mempool fees, and we sum up the mempool BDD. We get a policy statement from the command line for a relative weight of BDD vs fees (default 0.05), and then conversionRate = (summedFees / summedBDD) * BDDWeight.\n\nAs an optimization, rather than scanning over the whole mempool to calculate this, we can just store the sum and add or subtract from it each time a tx enters or leaves the mempool. In order to minimize drift (the BDD for a transaction changes over time), we recalculate the whole thing each time a new block is found.\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151027/bb663efd/attachment.sig\u003e",
"sig": "c4cd3567e661e7ca0ca9516a39692c0255aad306704932c6a6f1a2818fbb05219a722ad47d52cd0452b3f0841975ac19c70d781d242d1abf341b638ef76ee373"
}