Bitcoin core 0.13.1 Timeline

[BlackJacky]

Folks,

I have a question on the timeline because Im not getting it properly.

Bitcoin core is writing:

Miners will be able to signal that they are willing and able to enforce segwit starting at the beginning of the first 2,016-block retarget period on or after 15 November 2016 (UTC).

If 95% of blocks within any retarget period signal support for segwit, it locks-in.


That means on the 15th November Miner are able to signal if they accept 0.13.1 which needs a 95% acceptance within 2016 blocks.

Bitcoin core is further writing:

After another 2,016-block (roughly two week) retarget period, segwit will activate, allowing miners to produce blocks containing segwit transactions on Bitcoin’s mainnet.

I dont understand why another 2016 block period is needed. I thought after the first 2016 blocks 0.13.1 is activated. What is happening in the second period?

Thanks guys!!!

[Carlton Banks]

It's just a short time to allow people to upgrade to some Segwit compatible wallet software. Could be as little as 10 days if miners are expanding the hashrate during those 2016 blocks.

[franky1]

ok
imagine november 15th first checked period was blockheight 440,000
its not a fixed intervals of
440,000 - 442,016
442,017 - 444,032
444,032 - 446,048

instead its any previous 2016 blocks directly before the current newest block, as of the start date..

so say the start date was block 440,000 it would look backwards all the way to 437,984
which obviously no one was flagging before 440,000 so it wont lock in.
~ 10 minutes later (440,001) would look back to 437,985

but because flagging only begins at lets say 440,000 the earliest chance could be
442,016 looking back to 440,000(start of December back to mid November)
442,017 looking back to 440,001
442,018 looking back to 440,002
442,019 looking back to 440,003
442,020 looking back to 440,004
442,021 looking back to 440,005
442,022 looking back to 440,006
442,023 looking back to 440,007
442,024 looking back to 440,008

and so on. and so on
if it does achieve 95%, then once its locked in. a further ~2 week period waiting time is allowed before its 'live' and active.
if it does not achieve 95% anytime before this time next year, it defined as not viable and the attempts are given up


note:
i picked 440,000 as a number .. but stupidly devs chose to use a unix timestamp as the start point (i laughed)
when counting blocks a rational thing would be to use a blockheight as a starting point. afterall timestamps are useless in most cases

[BlackJacky]

Thank you so much franky1!!!! I got it

Does that also mean, that the first block with a higher transaction number (with segwit) can be mined after 4032 blocks or actually at block 4033?

[BlackJacky]

One more...why is the blockchain always cheching the previous blocks? Is it not possible that it is checking immediately that 2016 blocks have been with version 0.13.1?

[franky1]

One more...why is the blockchain always cheching the previous blocks? Is it not possible that it is checking immediately that 2016 blocks have been with version 0.13.1?

both things you ask are the same thing.
when a block is created it immediately checks the previous 2016 blocks preceding that block to see if 1915 are flagging for segwit.
like i said. it doesnt wait 2016 blocks and then back checks.. then wait 2016 blocks and back checks.
EG
not start at 440000 and wait aimlessly for 442016 to then check all blocks back to 440,000
not wait till 442017 and wait aimlessly for 444032 to then check all blocks back to 442016
it checks 2016 blocks preceding the one its currently at.
start at 440000 check back to 437,984
check at 440001 back to 437,985

as for the other question.
say the start was 440,000 (15th november)
if right that moment everyone was flagging.. the lockin period would be 442016. and the waiting period would end 444032. meaning the first segwit transaction allowed into a block would be 444033
but that ofcourse is IF it got 95% nearly instantly on the 15th and held that 95% for the 2weeks to lockin for the start of december.

even segwit devs are warning to not rush:
https://bitcoincore.org/en/2016/10/28/segwit-costs/

Risks related to soft-fork deployment

A soft-fork is any change to Bitcoin consensus rules that invalidates some set of previously valid transaction. A poorly handled soft-fork can cause a number of problems in the Bitcoin ecosystem, and, because segwit makes the additional witness data critical to establishing Bitcoin’s distributed consensus, a poorly handled upgrade could cause the system to fail in additional ways. The primary potential failure modes include:

A major factor in mitigating the impact of any bugs is that segwit is implemented as a soft-fork. This means:
Users of Bitcoin can simply avoid newly introduced features until they are personally confident they are implemented correctly, without losing any functionality.

so dont expect everyone to wave their flags straight away on november 15th to get a lockin by the start of december and running by christmas.. expect it to be usable by spring 2017ish as a rational 'early' timescale.

any sooner shows its a rush job which can cause issues where people have not actually tried it before waving their flags.
much like kids telling their friends they have an iphone before actually turning it on to see how it works. and then some kids crying because they have issues. the smart plan is always to try something before waving it around

[BlackJacky]

yeah, now I got it even more. Makes absolutely sense! Thank you very much for your detailed explanation

[achow101]

instead its any previous 2016 blocks directly before the current newest block, as of the start date..

Technically not any previous 2016 blocks but rather the previous difficulty retarget period which is 2016 blocks.

i picked 440,000 as a number .. but stupidly devs chose to use a unix timestamp as the start point (i laughed)
when counting blocks a rational thing would be to use a blockheight as a starting point. afterall timestamps are useless in most cases

The timestamps are a bit weird but it still makes some sense given the blocks contain a timestamp and that predicting what block number will be exactly one year from now is pretty hard to do because of block time variation. Although I do agree that having a set block height start time would be better.

[franky1]

instead its any previous 2016 blocks directly before the current newest block, as of the start date..

Technically not any previous 2016 blocks but rather the previous difficulty retarget period which is 2016 blocks.

but the next difficulty is predicted in under 8 days (5th) then estimated at 14 days after that (19th)
so if they are going to measure it as of the 5thnov-19thnov.. and then the 19thnov-3rdDec
then thats another flawed moment

EG you might aswell rule out 15th-19th due to it only having 4 days of flags
possibly rule out 19th-3rd, due to smart people running live tests on main net (rpc/wallet/relay)
meaning only real sensible slot would be 3rdDec-17thDec

but here is the other reason why doing (my random demo numbers)
440,000 - 442,016
442,017 - 444,032
444,032 - 446,048
and so on
is worse than doing
442,016 looking back to 440,000
442,017 looking back to 440,001
442,018 looking back to 440,002
and so on

because imagine it reached 95% on block 441,000
in the first case the slot of 440,000-442,016 would be classed as half full(still opposed much like 15th-19th). because only a week would have have the flag not the 2 weeks
then miners would need to continue that 95% for the whole of 442,017-444,032 meaning 3 weeks. just to have 95% for a full 2 weeks because the first week didnt count.

in the second case it would be checking 443,016 back to 441,000 and lock it in.. (a week sooner thank first case)

the other bad thing is.. by using slots as oppose to constant checks.
a opposer just needs to push their hashpower to get 102 blocks solved.. then they can turn off their rigs for the rest of the fortnight knowing it would be another slot opposed due to 102 nonsegwit flagged blocks in the slot period..

where as if it was a back checking at every block of the previous 2016 blocks. those opposing will need to be constantly running extra hash power all the time to get 8 blocks a day to keep it below the threshold requirement.

EG
first case. double hashpower. mine 16 blocks a day. then turn rigs off after a week and relax knowing its opposed even with a week to go.
second case mine 8 blocks a day but constantly need to run it everyday.

infact if the slots were
19thNov-3rdDec
3rdDec-17thDec
17thDec-31stDec
31stDec-14thJan

an opposer can run extra hash from 26thNov-10thDec. and oppose 2 slots. where people got excited 19thNov-26thNov. and then boom disappointed all the way through to the 17thDec

an opposer can run extra hash from 24thDec-7thJan. and oppose 2 slots. where people got excited 17thDec-24thDec. and then boom disapointed all the way through to the 14thJan

where as checking each block for previous 2016 blocks means an opposer needs to stay constant and not drop hashpower.

this is the same tactic a sybil attacker can do on user nodes if there was a user consensus needed.. not required to run 24/7, just needed to run at strategic times if the measures were done in slots. as oppose to constant checks

but hey.. lets brush it under the carpet. and treat devs as gods.

atleast this drama should be over soon and we can then concentrate on actual onchain scaling now that segwit is deemed fully coded and perfect. so now they can start on stuff not related to segwit because thats all complete