I personally appreciate the minimal changes, and often encourage development to be done this way - when it needs to be released quickly.  But does this need to be released quickly?

- maybe the proposal should be renamed segwit 8mb and be discussed solely in terms of block weights.

- a high consensus hard fork is probably preferable to a low consensus soft fork, however there is nothing to indicate that segwit as it stands isnt already very high consensus except for a handful of pool operators protecting fee income.  

- miners who currently object to segwit while pretending to like larger blocks will find some excuse to object to this too.

Given the challenges miners seem to have in flipping bits, I expect any fork that requires 95pct hash power to be vaporware.

On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
The hard-fork is conditional to 95% of the hashing power has approved the segwit2mb soft-fork and the segwit soft-fork has been activated (which should occur 2016 blocks after its lock-in time)

Miners signalling they have upgraded by flipping a bit in the nVersion field has little relevance in a hard fork. If 100% of the hash power indicates they are running this proposal, but the nodes don't upgrade, what will happen?

For the record, I actually talk a lot about hard forks with various developers and am very interested in the research that Johnson in particular is pioneering. However, I have failed to understand your point about 95% miner signalling in relation to a hard fork, so I am eagerly awaiting your explanation.

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