Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-02 📝 Original message:On Wednesday, September ...
📅 Original date posted:2015-09-02
📝 Original message:On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
wrote:
> The repo:
https://github.com/jgarzik/bip100What is the purpose of the newly added 1 MB floor? It seems clear from the
current information available that 1 MB is presently too high for the limit,
and it is entirely one-sided to only allow increases when decreases are much
more likely to be needed in the short term.
Must the new size limit votes use 11 bytes of coinbase? Why not just use a
numeric value pushed after height? Since this is a hardfork, I suggest
increasing the coinbase length to allow for 100 bytes *in addition* to the
pushed height and size-vote.
I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32 MB
(or whatever value is deemed appropriate) to make it clear that the limit
remains a part of the consensus protocol and p2p protocol limits are not to
have an effect on consensus rules.
Furthermore, I suggest modifying the voting to require 50% to set the limit
floor. This has the effect of merely coordinating what miners can already
effectively do today by rejecting blocks larger than some collusion-
determined limit.
Thoughts?
Luke
Published at
2023-06-07 17:39:14Event JSON
{
"id": "3c72f9388ff61fccdfac78dd95c1abf05a3942bbedd98f9c60432120b64c0a8b",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686159554,
"kind": 1,
"tags": [
[
"e",
"dd2b88bd76717ea27b192ada88f39a04553ef7af9be5612abef2b24bdb0dc479",
"",
"root"
],
[
"e",
"7b4edbae9cb6d65eaa8f47dfa6d11d81fde0b64bb35bbb59fe83acfe48ff677f",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2015-09-02\n📝 Original message:On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev \nwrote:\n\u003e The repo: https://github.com/jgarzik/bip100\n\nWhat is the purpose of the newly added 1 MB floor? It seems clear from the \ncurrent information available that 1 MB is presently too high for the limit, \nand it is entirely one-sided to only allow increases when decreases are much \nmore likely to be needed in the short term.\n\nMust the new size limit votes use 11 bytes of coinbase? Why not just use a \nnumeric value pushed after height? Since this is a hardfork, I suggest \nincreasing the coinbase length to allow for 100 bytes *in addition* to the \npushed height and size-vote.\n\nI suggest combining 2 \u0026 4 into a single rule lifting the 1 MB limit to 32 MB \n(or whatever value is deemed appropriate) to make it clear that the limit \nremains a part of the consensus protocol and p2p protocol limits are not to \nhave an effect on consensus rules.\n\nFurthermore, I suggest modifying the voting to require 50% to set the limit \nfloor. This has the effect of merely coordinating what miners can already \neffectively do today by rejecting blocks larger than some collusion-\ndetermined limit.\n\nThoughts?\n\nLuke",
"sig": "b0126a81cdf08c56b5050b3fb5f29ab9b5ee6cbda29a6a85f458c95397f5e5495c588b27f3f635e72e9f77919d9a8383f45019b74f6a0545cf31185dcbe93378"
}