The BIP has been updated.

Changes:
- The technical spec has been improved: now the block size increase is specified in terms of weight and not in terms of bytes.
- The increase in the maximum block sigops after HF has been documented.
- Comments added about the worst case block size.

Happy weekend! And don't forget to start signaling something before block 475776 !  It's just 90 blocks away.
Bit 1 or 4,1 or whatever you wish, but please signal something.

To the moon!


On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
> I think anything less than 1 year after release of tested code by some
> implementation would be irresponsible for any hardfork, even a very
> simple one.

Good news!

Code to support 2x (the hard fork part of the proposal) has been out and
tested for much longer than that.

Not true. It's different code on top of segwit. The first attempt in btc1 (very recent) didn't even increased the size (because it changed the meaningless "base size" without touching the weight limit. As for the current code, I don't think it has been properly tested today, let alone "for mucj longer than 1 year.
Anyway, I said, one year from tested release. Segwitx2 hasn't been released, has it? If so, too late to discuss a bip imo, the bip may end up being different from what has been released due to feedback (unless it is ignored again, of course).



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