📅 Original date posted:2017-03-30
📝 Original message:Den 30 mars 2017 11:34 skrev "Natanael" <natanael.l at gmail.com>:
Block size dependent difficulty scaling. Hardfork required.
Larger blocks means greater difficulty - but it doesn't scale linearly,
rather a little less than linearly. That means miners can take a penalty in
difficulty to claim a greater number of high fee transactions in the same
amount of time (effectively increasing "block size bitrate"), increasing
their profits. When such profitable fees aren't available, they have to
reduce block size.
In other words, the users literally pay miners to increase block size (or
don't pay, which reduces it).
This can be simplified if we do get a fee pool (less hardfork code, more
softfork code), except that the effect will be partially reduced by the
mining subsidy until it approximately reaches parity with average total
fees.
We don't need to alter difficulty calculation.
Instead we alter the percentage of the fees that the miner gets to claim VS
what he have to donate to the pool based on the size of the block he
generated.
Larger block = smaller percentage of fees. This is another way to pay for
blocksize. The effect of this is that on average, miners that generate
smaller blocks takes a share of what otherwise would be part of the mining
profits of those generating larger blocks.
We would need to keep pieces of the section from above on expected
blocksize calculation. Because the closer you are to the expected
blocksize, the more you keep. And thus we need to adjust it according to
usage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/051be6af/attachment.html>;
Natanael [ARCHIVE] /
npub179…lpmjt
2023-06-07 17:58:32
in reply to nevent1q…jfjg
Author Public Key
npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtPublished at
2023-06-07 17:58:32Event JSON
{
"id": "508a256c43ce8fbf65668b53212419bbb4913cfaf93132b7b6a2ae976d070466",
"pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018",
"created_at": 1686160712,
"kind": 1,
"tags": [
[
"e",
"4f5cc115e4c69b7e46c2ce410bcf3bce353d9771e5f344aee3442cd26791714e",
"",
"root"
],
[
"e",
"0d958c8252a8ad58613d51d5032b2df5b1bb695d4f5b3f1d68bd39fdd89afcc0",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2017-03-30\n📝 Original message:Den 30 mars 2017 11:34 skrev \"Natanael\" \u003cnatanael.l at gmail.com\u003e:\n\nBlock size dependent difficulty scaling. Hardfork required.\n\nLarger blocks means greater difficulty - but it doesn't scale linearly,\nrather a little less than linearly. That means miners can take a penalty in\ndifficulty to claim a greater number of high fee transactions in the same\namount of time (effectively increasing \"block size bitrate\"), increasing\ntheir profits. When such profitable fees aren't available, they have to\nreduce block size.\n\nIn other words, the users literally pay miners to increase block size (or\ndon't pay, which reduces it).\n\n\nThis can be simplified if we do get a fee pool (less hardfork code, more\nsoftfork code), except that the effect will be partially reduced by the\nmining subsidy until it approximately reaches parity with average total\nfees.\n\nWe don't need to alter difficulty calculation.\nInstead we alter the percentage of the fees that the miner gets to claim VS\nwhat he have to donate to the pool based on the size of the block he\ngenerated.\nLarger block = smaller percentage of fees. This is another way to pay for\nblocksize. The effect of this is that on average, miners that generate\nsmaller blocks takes a share of what otherwise would be part of the mining\nprofits of those generating larger blocks.\n\nWe would need to keep pieces of the section from above on expected\nblocksize calculation. Because the closer you are to the expected\nblocksize, the more you keep. And thus we need to adjust it according to\nusage.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/051be6af/attachment.html\u003e",
"sig": "044ce88c406afbf0beb964b9eecc550231ffb3ea6f3357e5648131aaaeadb9b05da89ecd3cb0723b0d647577377822598a09f382fe05b18cfc2d08048ea63fd7"
}