- We now are witnessing this... COOP vs LukeJr COOP, vs BIP148 vs BIP149 vs BIP91 ... how many are there?:

https://xkcd.com/927

- If some miners and exchanges collude to enact a rapid 2MB+Segwit hard fork coin... and calling it "bitcoin" on major exchanges this could swiftly fragment the network.

- If this fork fails to contain an ASICBOOST defense, then this is essentially an example of core failing to appropriately respond to the CVE security vulnerability in time.

- A swift BIP148 release in core seems necessary to defend against this. I am no longer in favor of adding a BIP148 option with default "false".. I think it should be merged in...enabled, and released ASAP to defend against these attacks.

On Mon, May 29, 2017 at 7:49 PM, Oliver Petruzel via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

>>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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev