ð
Original date posted:2015-06-23
ð Original message:To my knowledge so far the main proposals regarding block size changes
are either based on predictions, which traditionally we're not very good
at, or a voting mechanism by a limited set of stakeholders (miners)
whose interests may not be aligned with the rest of the community.
Neither strategy takes into account the most important factor: real-time
changes to the mempool. This is for a valid reason, there is currently
no consensus on the size of the mempool.
So my question is: has anyone considered the pros and cons of creating
consensus around the current (approximate) mempool size?
I propose that, at the expense of some transaction overhead (3 or 4
extra bytes?), each full-node that broadcasts a new transaction can add
a mempool_size field that represents their current view of the mempool.
As blocks are mined with this new data (which may or not be aggregated
in the block header), all nodes can quickly reach consensus on the
current average/median/etc mempool size, and agree on a suitable
periodic blocksize "re-targetting" (similarly to mining difficulty).
Since all full-nodes (not just miners) get to vote with their
transactions the consensus is truly global, and we don't have to change
blocksize blindly in anticipation of an unpredictable future.
Would this not work, and if not, why?
Filipe Farinha
Filipe Farinha [ARCHIVE] /
npub1fvâŠn9kce
2023-06-07 15:40:00
in reply to nevent1qâŠd4fc
Author Public Key
npub1fvqfcygrz35axxejv75jecj9vawekqpp7fnf8evq704nga0xge9q8n9kcePublished at
2023-06-07 15:40:00Event JSON
{
"id": "3d4cb3bb19478529038de8afaef12742039a60ef4307f6956120f3d4f5e24a5b",
"pubkey": "4b009c11031469d31b3267a92ce245675d9b0021f26693e580f3eb3475e6464a",
"created_at": 1686152400,
"kind": 1,
"tags": [
[
"e",
"da690204c39a104e741cadea43f82fd3654af4d0c7aba76b6931ea2e4c6cd412",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "ð
Original date posted:2015-06-23\nð Original message:To my knowledge so far the main proposals regarding block size changes \nare either based on predictions, which traditionally we're not very good \nat, or a voting mechanism by a limited set of stakeholders (miners) \nwhose interests may not be aligned with the rest of the community.\n\nNeither strategy takes into account the most important factor: real-time \nchanges to the mempool. This is for a valid reason, there is currently \nno consensus on the size of the mempool.\n\nSo my question is: has anyone considered the pros and cons of creating \nconsensus around the current (approximate) mempool size?\n\nI propose that, at the expense of some transaction overhead (3 or 4 \nextra bytes?), each full-node that broadcasts a new transaction can add \na mempool_size field that represents their current view of the mempool. \nAs blocks are mined with this new data (which may or not be aggregated \nin the block header), all nodes can quickly reach consensus on the \ncurrent average/median/etc mempool size, and agree on a suitable \nperiodic blocksize \"re-targetting\" (similarly to mining difficulty).\n\nSince all full-nodes (not just miners) get to vote with their \ntransactions the consensus is truly global, and we don't have to change \nblocksize blindly in anticipation of an unpredictable future.\n\nWould this not work, and if not, why?\n\nFilipe Farinha",
"sig": "0a9cfa19da03b819be6f427cf1060d271769a57e054a09be09db58567c49bef4317a14e1b4ad0d008e24103adb44cfb6f7a49bb598814bf89a20a7c323c77691"
}