praxeology_guy [ARCHIVE] on Nostr: 📅 Original date posted:2017-03-26 📝 Original message:"Activation of segwit is ...

📅 Original date posted:2017-03-26
📝 Original message:"Activation of segwit is defined by BIP9. After 15 Nov 2016 and before 15 Nov 2017 UTC, if in a full retarget cycle at least 1916 out of 2016 blocks is signaling readiness, segwit will be activated in the retarget cycle after the next one"

Just change BIP9 and the code to say "if in a full retarget cycle at least 1 out of 2016 blocks" and call it done. Or something very similar to this that effectively does the exact same thing. :) Wasting too much time on this. 15 Nov 2017 is plenty of time to be ready for SegWit, and if a participant is not ready by then they are either unreasonably lazy, a manipulator, or manipluted, and we don't need them.

If non-upgrading miners refuse to build on segwit blocks, or build on malicious invalid segwit blocks, then so be it. We fork. We have spent enough time trying to convince people who don't think for themselves... if they are still manipulated now then its time for us to give up on helping them see the light and instead let them learn the hard way.

Cheers,
Praxeology Guy

-------- Original Message --------
Subject: Re: [bitcoin-dev] Flag day activation of segwit
Local Time: March 13, 2017 5:18 PM
UTC Time: March 13, 2017 10:18 PM
From: bitcoin-dev at lists.linuxfoundation.org
To: shaolinfry <shaolinfry at protonmail.ch>, Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>

>time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled()
This has a different start time from the first post.
>if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 ...

Thanks,
--Nick

On Mon, Mar 13, 2017 at 4:36 AM, shaolinfry via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
From: luke at 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 at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/44bc5edb/attachment.html>;