Oliver Petruzel [ARCHIVE] on Nostr: 📅 Original date posted:2017-05-29 📝 Original message:>>if the community wishes ...
📅 Original date posted:2017-05-29
📝 Original message:>>if the community wishes to adopt (by unanimous consensus) a 2 MB block
size hardfork, this is probably the best way to do it right now... Legacy
Bitcoin transactions are given the witness discount, and a block size limit
of 2 MB is imposed.<<
The above decision may quickly become very controversial. I don't think it's
what most users had/have in mind when they discuss a "2MB+SegWit" solution.
With the current 1MB+SegWit, testing has shown us that normal usage results
in ~2 or 2.1MB blocks.
I think most users will expect a linear increase when Base Size is
increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
With normal usage, the expected results would then be ~4 or 4.2MB blocks.
Am I missing something here, or does Luke's suggested 2MB cap completely
nullify that expected linear increase? If so, why? What's the logic behind
this decision?
I'd love to be armed with a good answer should my colleagues ask me the
same obvious question, so thank you ahead of time!
Respectfully,
Oliver Petruzel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170529/069bfb26/attachment.html>
📝 Original message:>>if the community wishes to adopt (by unanimous consensus) a 2 MB block
size hardfork, this is probably the best way to do it right now... Legacy
Bitcoin transactions are given the witness discount, and a block size limit
of 2 MB is imposed.<<
The above decision may quickly become very controversial. I don't think it's
what most users had/have in mind when they discuss a "2MB+SegWit" solution.
With the current 1MB+SegWit, testing has shown us that normal usage results
in ~2 or 2.1MB blocks.
I think most users will expect a linear increase when Base Size is
increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
With normal usage, the expected results would then be ~4 or 4.2MB blocks.
Am I missing something here, or does Luke's suggested 2MB cap completely
nullify that expected linear increase? If so, why? What's the logic behind
this decision?
I'd love to be armed with a good answer should my colleagues ask me the
same obvious question, so thank you ahead of time!
Respectfully,
Oliver Petruzel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170529/069bfb26/attachment.html>