[Bitcoin-segwit2x] segwit2x rc Version 1.14.4 released

[Peter Todd]

On Mon, Jul 17, 2017 at 10:42:49PM -0400, Jeff Garzik via Bitcoin-segwit2x wrote:

> 3. Sergio Lerner has been working on a segwit2x BIP (specification):
> https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawiki
>  Understand that this is in draft form and may see minor revisions.

That "specification" is woefully underspecified, and as we see below indicates
your team does not have a clear idea how your software actually works. It needs
significantly more than "minor revisions"

I suggest BIP65, BIP112, BIP113, etc. as good examples of well-specified BIPs
to work from.

> 4b. The activation sequence is bit-4 -> bit-1 -> time passes -> 2M
> hard fork.  There is the valid criticism that, in the (IMO unlikely)
> event of "bit-1->time passes", without bit-4 activation per NYA
> agreement, that the btc1 node would still activate the 2M hard fork
> after 144*90 blocks.  It seems both prudent, in the spirit of the NYA
> agreement, and addressing an edge case to ensure that bit-4 activation
> did indeed occur, before triggering the 2M after 144*90 blocks.
> Usefully, we have time to polish this.

You need to update your comment on pull-req #58 stating that "If SegWit is
purely Bit-1 then it won't trigger.", making it clear that you were mistaken
about how the btc1 software actually worked; this has caused some confusion
among journalists and the like.

Secondly, bit-4 is already used by BIP91, which is simply a soft-fork to
activate segwit at 80% threshold rather than 95% - notably most miners
signalling bit-4 are obviously not running the btc1 software, and there are a
number of other implementations of BIP91 in existence. In short, bit-4 no
longer means "segwit2x hard-fork"

While BIP9 bits can be reused, it's not a good idea to reuse them so quickly,
so you should pick a new bit if you are going to propose a new set of hard-fork
conditions. Equally, if you stick to the existing conditions, you will likely
soon be able to implement them as a block-height+known block hash flag day.

Of course, the fact that this hasn't been nailed down even *after* you've
released production software - and the fact that you and the rest of the btc1
team didn't even understand how that software actually activates and needed
outside review to find out - is by itself a clear sign that this process is
being dangerously rushed, and does not have a competent team working on it.

There is every reason to scrap the 90-day lead time segwit2x hard-fork, enjoy
the capacity improvement given by segwit activation, and come back later with a
better proposal with replay protection, and a better understanding of how the
increased load will affect the network after watching the effects of segwit2x's
blocksize increase.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170717/d90e92eb/attachment-0001.sig>