2
1
Recently(as of May 24, 2017) segwit2mb HF has been proposed. A core developer has reported that another deployment of segwit via bip 109 on bit 4 would require code duplication. Although the above link comes with some justification, I fail to understand the reasoning.
What will be consequences if we simply change the block threshold(95% of 2016) to 80% of 2016 and give it out as a new binary? Is there a network split risk?
1
If the miners activate segwit by signaling readiness for segwit on bit 4 (further called segwit4) immediately, all nodes that follow the current activation procedure (signaling on bit 1) would ignore this activation. Regular segwit enabled nodes would interpret transactions and blocks created with segwit according to the old rules. After segwit4 activated they would still consider segwit transactions to be not allowed yet, and thus with the first segwit4 transaction appearing on the network, ban the relaying nodes for forwarding invalid transactions. At this point, this would split the network between miners and all nodes that are segwit1-enabled.
Activating two different versions of segwit on the network would trigger untested interactions between nodes, as several parts of the relay code logic is dependend on the signaling bit. Only interactions between segwit-enabled and segwit-unaware nodes were tested extensively, so one should expect new code and new test cases to be necessary to avoid a netsplit with segwit1-enabled nodes.
This would perhaps not matter terribly much, since according to Garzik on Twitter the blocksize increase would be activated at the same time as SegWit4, so any old type nodes would be hard forked off the network anyway as blocks created by the new chain would appear invalid to them.
Update: Apparently, there are at least three opinions out there about the activation order of segwit, and the hardfork since Consensus, so I'm waiting what it'll be.
1
As far I understand the argument by G Maxwell concentrates on code path duplication and avoiding combinatorial testing. Most of the current segwit code in 0.13.1+ is already active and is been used even for not segwit code, so there is very little chance of a dead code turning up after segwit activation.
So for segwit4 we have three options:
As you suggested, completely drop support for segwit1 and just search, replace bit1 by bit4 and 95% by 80%. The problem with this is that if later segwit1 catches suppport, we are hardforked out of the network and then we have to downgrade our node to avoid forking out. Note that this is probable since majority of network is already on segwit1 support. A fact which is also used by BIP148 to force segwit activation.
Retain support for segwit1 and add segwit4. With this we are not forked out, but has issues with code duplication and testing.
Wait for segwit1 to expire and then do search/replace. This is safer option suggested to avoid problems with 1. and 2.
Can you elaborate(with respect to Option 1) as to why would the network HF after segwit1 activates? What transactions would be invalid in 1 network while valid in other one? – sanket1729 – 2017-05-26T09:20:55.310
Blocks having segwit transactions willl be rejected by our node. This will work how it is working right now, the code is the same and we haven't reached segwit activation. Other majority nodes on segwit1 will accept segwit blocks – dark knight – 2017-05-26T09:35:42.317
Concerning option one, the agreement suggested that SegWit would immediately be rolled out with bit 4. However, first the code would need to be written. You liken this to a search&replace, however also the code for the hard fork needs to be integrated as that is supposed to be locked in as well. Second, the miners would need to upgrade to the code. But finally, also a sufficient amount of nodes would have to update to the code, as otherwise the network would split and before a majority enforces segwit4, it would be unsafe to use. – Murch – 2017-05-26T19:36:28.313
Concerning option two, it would probably be the easiest to go with BIP91. But even then, to adhere to the Silbert agreement, hardfork code would need to be integrated with segwit first. Option three would push capacity increases back another six months at least. However, fees are already going the roof today. – Murch – 2017-05-26T19:39:01.540