From: luke@dashjr.org

On Sunday, March 12, 2017 3:50:27 PM shaolinfry via bitcoin-dev wrote:

> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017

> inclusive if (pindex->GetMedianTimePast() >= 1538352000 &&

> pindex->GetMedianTimePast() <= 1510704000 &&

> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {

> if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) ==

> VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params,

> Consensus::DEPLOYMENT_SEGWIT)) != 0) {

> return state.DoS(2, error("ConnectBlock(): relayed block must

> signal for segwit, please upgrade"), REJECT_INVALID,

> "bad-no-segwit");

> }

> }

I don't think this is actually BIP 9 compatible. Once activated, the bit loses

its meaning and should not be set. So you need to check that it hasn't locked-

in already...

I believe that is handled.

time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()

Signalling is only required from October 1st until the BIP9 timeout, or, until segwit is activated. The bit becomes free after activation/timeout as per BIP9. Also, the default behaviour of BIP9 in Bitcoin Core is to signal through the LOCKED_IN period - it would be trivial to add a condition to not require mandatory signalling during LOCKED_IN but since miners signal by default during this period, I figured I would leave it.

I thought about 5% tolerance. but I don't think it makes sense since miners will already have plenty of warning this is coming up and the intent of the mandatory signalling period is quite clear. It also seems a bit weird to say "it's mandatory but not for 5%". If miners are required to signal, they need to signal. It also adds unnecessary complexity to an otherwise simple patch.

That said, I have no strong feelings either way on both counts, but I chose to present the simplest option first.

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