Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-27 📝 Original message:On Friday, January 27, ...
📅 Original date posted:2017-01-27
📝 Original message:On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote:
> Comment on #1. You're dropping the blocksize limit to 300KB and only
> reaching the limit that we have in place today 7 years later?
The limit only drops all the way to 300k if it activates before 2017 April.
Considering that this requires the consensus of a hardfork, followed by a
release in software, and then actual activation by miners using BIP9, I think
it's extremely unlikely to activate by then.
But more importantly: such a drop would probably be good for the network in
the long-term. As explained in the Rationale section, 300k is necessary to
maintain our *current* IBD (first-time node sync) costs even with
technological improvements (which appear to be slowing lately).
> We're already at capacity today, surely you're not serious with this
> proposal?
We are only at capacity because the space is available below actual costs,
and/or because efficient alternatives are not yet widely supported. A
reduction of block size will likely squeeze out spam, and perhaps some
unsustainable microtransaction use, but the volume which actually *benefits
from* the blockchain's security should continue along fine. Furthermore, once
Lightning is widely implemented as well-tested, at least microtransactions are
likely to gain a huge improvement in efficiency, reducing legitimate usage of
block sizes well below 300k naturally - that is frankly when I first expect
this proposal to be seriously considered for activation (which is independent
from the consensus to include support for it in nodes).
> When you promised code for a hard forking block size increase in the HK
> agreement I don't believe that a decrease first was made apparent. While
> not technically in violation of the letter of the agreement, I think this
> is a pretty obviously not in the spirit of it.
I did not mention the HK "roundtable", because this is indeed not in the
spirit of what we set out to do, and do not wish this to be interpreted as
some kind of slap in the face of the honest participants of that discussion.
This proposal is, however, the best I am currently able to honestly recommend
that meets the hard criteria outlined at Hong Kong a year ago. (Continued work
on the MMHF/SHF concept may eventually deliver a better solution, but it is
not yet ready.)
Luke
Published at
2023-06-07 17:55:48Event JSON
{
"id": "44b319ffe26e1565f478d47d9740b2f703f1c91ba126cd916cb946d9455ce319",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160548,
"kind": 1,
"tags": [
[
"e",
"b64df2ffa5964ebc2c2494c8a737d0410a8afb40f32e18bcfc4123842c995495",
"",
"root"
],
[
"e",
"7506a7e980c4a66ab0bb03b6f492bc76b91be800e461ef9d7e421657bb774808",
"",
"reply"
],
[
"p",
"fa69268781de33f116b423cab175d976820851d6b074d0873c920c6983eb4713"
]
],
"content": "📅 Original date posted:2017-01-27\n📝 Original message:On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote:\n\u003e Comment on #1. You're dropping the blocksize limit to 300KB and only\n\u003e reaching the limit that we have in place today 7 years later?\n\nThe limit only drops all the way to 300k if it activates before 2017 April. \nConsidering that this requires the consensus of a hardfork, followed by a \nrelease in software, and then actual activation by miners using BIP9, I think \nit's extremely unlikely to activate by then.\n\nBut more importantly: such a drop would probably be good for the network in \nthe long-term. As explained in the Rationale section, 300k is necessary to \nmaintain our *current* IBD (first-time node sync) costs even with \ntechnological improvements (which appear to be slowing lately).\n\n\u003e We're already at capacity today, surely you're not serious with this\n\u003e proposal?\n\nWe are only at capacity because the space is available below actual costs, \nand/or because efficient alternatives are not yet widely supported. A \nreduction of block size will likely squeeze out spam, and perhaps some \nunsustainable microtransaction use, but the volume which actually *benefits \nfrom* the blockchain's security should continue along fine. Furthermore, once \nLightning is widely implemented as well-tested, at least microtransactions are \nlikely to gain a huge improvement in efficiency, reducing legitimate usage of \nblock sizes well below 300k naturally - that is frankly when I first expect \nthis proposal to be seriously considered for activation (which is independent \nfrom the consensus to include support for it in nodes).\n\n\u003e When you promised code for a hard forking block size increase in the HK\n\u003e agreement I don't believe that a decrease first was made apparent. While\n\u003e not technically in violation of the letter of the agreement, I think this\n\u003e is a pretty obviously not in the spirit of it.\n\nI did not mention the HK \"roundtable\", because this is indeed not in the \nspirit of what we set out to do, and do not wish this to be interpreted as \nsome kind of slap in the face of the honest participants of that discussion.\n\nThis proposal is, however, the best I am currently able to honestly recommend \nthat meets the hard criteria outlined at Hong Kong a year ago. (Continued work \non the MMHF/SHF concept may eventually deliver a better solution, but it is \nnot yet ready.)\n\nLuke",
"sig": "c402ae4799aad9eb37aa94abd9808494d59bc303efda8cafad724e575e7bae5039ef823e71014b32e71544929958825f0bb96c0a714257de36b74b4a7f6eb596"
}