[Bitcoin-segwit2x] segwit2x rc Version 1.14.4 released

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>