[UPDATED]: The OFFICIAL SegWit2x Lock-in Thread

[Minecache]

What's the latest news? Are we gud to go?

[joebrook]

Has anyone been following core devs response to this?  Are we gonna see btc1 merged into core?  Do I need to update my node (I think not since I'm not mining with it)?

this is what i understand and for that i say we don't need a merge for now:

BTC1 or SegWit2x has 3 parts:
1. signalling bit 4 (BIP91) and then if it was locked in, reject any blocks that are not signalling. since this was nearly all of the blocks and also because of 2 is happening right now, i don't see why we even need this.
2. signalling bit 1 (BIP141) which is happening now again with almost all of the miners. and this is already in bitcoin core and nodes are seeing this part already. again no need to merge anything.
3. (this is why i said not for now) the 2 MB hard fork part. and that is not happening for a couple of months and until that day and until we know how much of hash power is really going for it and a lot of other things, there is no need to merge anything.

All though the first step has been concluded, There is still the second part to go, which is above the 60% right now, When is the deadline for signaling bit 1 to complete and what does it have to do with August 1. Can u please explain to me.

[BitcoinNewsMagazine]

It looks like SegWit BIP141 will be active about this August 23. The 2 MB hard fork is contingent on a majority of miners switching from Core to the btc1 client.

[nibor]

So Segwit lockin is looking 99% sure now so that decision is made. Next decision is the 2Meg hardfork in mid November.

95%++ of miners were signalling that they agreed with the approach of segwit then 2m hardfork. But now that the segwit part has been concluded they seem to have stopped signalling for the hardfork! Which is very odd - as if this was what they wanted they could have just signalled for segwit originally and not had this whole segwit2 lockin process....

A hardfork with 95% miner support would have been very safe - but now we have no idea what they are going to do! Currently only 25% are signalling for the hardfork with bigger blocks! If that is the case we are stuck at 1M....

But what is even more strange is that 85% of the miners are still including /NYA/ in their coinbase - which is a non-binding indication that they support 2M blocks?

All I can think is that they switched back to the bitcoin core code as feel it is more reliable for the segwit activation? And will switch back to BTC1 soon after.

But all they are creating is doubt with will stop exchanges/payment processors/users switching to btc1 - and we need 100% to migrate by Nov for the hardfork to be as smooth as the bip91 cut in was.

[-ck]

But now that the segwit part has been concluded they seem to have stopped signalling for the hardfork! Which is very odd - as if this was what they wanted they could have just signalled for segwit originally and not had this whole segwit2 lockin process....

That's not correct. There is no signal for the hard fork, only the NYA comment in the coinbase that they're committed to doing so. The hard fork is assumed to already be locked in based on the signalling that's already happened. Of course that doesn't mean that they'll go ahead with it unless they all use btc1 compatible clients...

[Herbert2020]

Has anyone been following core devs response to this?  Are we gonna see btc1 merged into core?  Do I need to update my node (I think not since I'm not mining with it)?

this is what i understand and for that i say we don't need a merge for now:

BTC1 or SegWit2x has 3 parts:
1. signalling bit 4 (BIP91) and then if it was locked in, reject any blocks that are not signalling. since this was nearly all of the blocks and also because of 2 is happening right now, i don't see why we even need this.
2. signalling bit 1 (BIP141) which is happening now again with almost all of the miners. and this is already in bitcoin core and nodes are seeing this part already. again no need to merge anything.
3. (this is why i said not for now) the 2 MB hard fork part. and that is not happening for a couple of months and until that day and until we know how much of hash power is really going for it and a lot of other things, there is no need to merge anything.

All though the first step has been concluded, There is still the second part to go, which is above the 60% right now, When is the deadline for signaling bit 1 to complete and what does it have to do with August 1. Can u please explain to me.

there are a couple of things that i am currently confused about too.
BIP91 was supposed to reject blocks. but i am not sure which blocks, blocks that didn't signal with version bit 4 (which BIP91 uses) or blocks that didn't signal with version bit 1 (which BIP141 uses).
it is activated nonetheless and is supposed to reject blocks!! if someone could clarify which one would be great.
my guess is version bit 1 since most miners dropped bit 4 already and are on 1

as for BIP141 and the version bit 1 they are already signalling with 100% support see this: https://www.xbt.eu so there is nothing to reject anyways.
as i always said bitcoin is too big and too expensive to split. 12.5BTC+fees is nearly 35000$. signalling against majority (this 100%) means you miss that much money when your block is rejected.

[nibor]

But now that the segwit part has been concluded they seem to have stopped signalling for the hardfork! Which is very odd - as if this was what they wanted they could have just signalled for segwit originally and not had this whole segwit2 lockin process....

That's not correct. There is no signal for the hard fork, only the NYA comment in the coinbase that they're committed to doing so. The hard fork is assumed to already be locked in based on the signalling that's already happened. Of course that doesn't mean that they'll go ahead with it unless they all use btc1 compatible clients...

OK - yes that makes sense then - although continuing to signal would be "nice".

Anyone checked in the codebase what happens if you upgrade from Core->BTC1 in say Oct and do not re-download the blockchain? In that case how would the upgraded BTC1 client know that bit 4 had locked in?

[nibor]

Has anyone been following core devs response to this?  Are we gonna see btc1 merged into core?  Do I need to update my node (I think not since I'm not mining with it)?

this is what i understand and for that i say we don't need a merge for now:

BTC1 or SegWit2x has 3 parts:
1. signalling bit 4 (BIP91) and then if it was locked in, reject any blocks that are not signalling. since this was nearly all of the blocks and also because of 2 is happening right now, i don't see why we even need this.
2. signalling bit 1 (BIP141) which is happening now again with almost all of the miners. and this is already in bitcoin core and nodes are seeing this part already. again no need to merge anything.
3. (this is why i said not for now) the 2 MB hard fork part. and that is not happening for a couple of months and until that day and until we know how much of hash power is really going for it and a lot of other things, there is no need to merge anything.

All though the first step has been concluded, There is still the second part to go, which is above the 60% right now, When is the deadline for signaling bit 1 to complete and what does it have to do with August 1. Can u please explain to me.

Was bit 1 that would be rejected.
And the fact that everyone is signalling with bit 1 shows that any blocks that are not signalling with bit 1 ARE being rejected (anyone seen any - none in the orphan list on blockchain.org) - although if blockchain.org was running btc1 they would be invalid rather than orphans.

[Siren]

SEGWIT LOCK-IN PERIOD:
Lock-in in this period? No
483 blocks before current lock-in period ends. Still 959 blocks needed for a lock-in.
62.4% SegWit blocks mined in this lock-in period.

https://www.xbt.eu/

Can someone explain what going on? I thought its already locked in but why the website says "NO"?

[krishnapramod]

SEGWIT LOCK-IN PERIOD:
Lock-in in this period? No
483 blocks before current lock-in period ends. Still 959 blocks needed for a lock-in.
62.4% SegWit blocks mined in this lock-in period.

https://www.xbt.eu/

Can someone explain what going on? I thought its already locked in but why the website says "NO"?

BIP91 was locked in and activated not Segwit (BIP141).

BIP91 was an alternative to activate Segwit by lowering the signalling threshold to 80% from 95% of BIP141 (Segwit)

Right now Segwit wouldn't get locked in this period because 959 blocks are required while only 483 blocks are left and the percentage is 62.4%, 95% is required.

After this there are seven more activation periods, http://segwit.co/

https://coin.dance/blocks

[Andre_Goldman]

why exactly is it called "lock-in" phase ?

[krishnapramod]

why exactly is it called "lock-in" phase ?

Lock-in can be called an intent period, an intent to activate a future event. The intent gets locked-in.

If I am right then there is lock-in period, grace period, and then activation.

BIP141 (Segwit) requires 95% (1916 from 2016 blocks) of hashpower to get locked-in.

After locked-in it's two weeks grace period.

After grace period it's activation.

Segwit is expected to be locked-in by August 10 and be activated by August 23.

[TierNolan]

why exactly is it called "lock-in" phase ?

What locked-in (and activated) was BIP91.  That is an agreement for all miners to vote for segwit (and also the 2MB HF in November).

Now that BIP91 is active, 100% of miners must vote SW.  This means that SW is guaranteed to lock-in and then activate.  It hasn't yet though.  The vote takes 2 weeks and when the vote passes, SW will be considered locked-in.  It will activate 2 weeks later.

[KellyCoin]

Thanks guys for clearing this up. I was also a bit confused and the last few replies has really helped.

[soul-impact]

why exactly is it called "lock-in" phase ?

What locked-in (and activated) was BIP91.  That is an agreement for all miners to vote for segwit (and also the 2MB HF in November).

Now that BIP91 is active, 100% of miners must vote SW.  This means that SW is guaranteed to lock-in and then activate.  It hasn't yet though.  The vote takes 2 weeks and when the vote passes, SW will be considered locked-in.  It will activate 2 weeks later.

This is a good way for them to ensure the success of hardfork, segwit will definitely be enabled however, I suppose there are some people disagree, so 100% is a wrong number.

[dunfida]

why exactly is it called "lock-in" phase ?

What locked-in (and activated) was BIP91.  That is an agreement for all miners to vote for segwit (and also the 2MB HF in November).

Now that BIP91 is active, 100% of miners must vote SW.  This means that SW is guaranteed to lock-in and then activate.  It hasn't yet though.  The vote takes 2 weeks and when the vote passes, SW will be considered locked-in.  It will activate 2 weeks later.

This is a good way for them to ensure the success of hardfork, segwit will definitely be enabled however, I suppose there are some people disagree, so 100% is a wrong number.

100% is really a wrong number because if there would be perfect number then there would be no voting at all on the very first place and instead of making some negotiations or polls they would directly go the same thing since they are all agreed on the same stuff. Theres always a side who would really reject on such actions. I will say 99.99% would be better

[BTCLovingDude]

why exactly is it called "lock-in" phase ?

What locked-in (and activated) was BIP91.  That is an agreement for all miners to vote for segwit (and also the 2MB HF in November).

Now that BIP91 is active, 100% of miners must vote SW.  This means that SW is guaranteed to lock-in and then activate.  It hasn't yet though.  The vote takes 2 weeks and when the vote passes, SW will be considered locked-in.  It will activate 2 weeks later.

This is a good way for them to ensure the success of hardfork, segwit will definitely be enabled however, I suppose there are some people disagree, so 100% is a wrong number.

first of all SegWit is a soft fork not a hard fork (unless you are talking about something else) and currently the 100% signal is for SegWit soft fork.
and it is not a wrong number, why would you even say that
oh and by the way this signalling has so little with the 2 MB hard fork which is scheduled for later!

-snip-
100% is really a wrong number because if there would be perfect number then there would be no voting at all on the very first place and instead of making some negotiations or polls they would directly go the same thing since they are all agreed on the same stuff. Theres always a side who would really reject on such actions. I will say 99.99% would be better

correct me if i am wrong but if you don't signal for SegWit at this point (which is the locked in phase of BIP91) your block will be orphaned. so there shouldn't be anything else than 100%

[TierNolan]

This is a good way for them to ensure the success of hardfork, segwit will definitely be enabled however, I suppose there are some people disagree, so 100% is a wrong number.

No, it's 100% now.  Miners agreed a new rule which says that if you produce a block which doesn't vote for SW, then it counts as invalid.  Miners who produce non-SW blocks are throwing their hashing power away.  Their blocks will not be part of the chain.  This means that the chain will show a 100% vote for SW from now until it locks in.

[OmegaStarScream]

It clearly won't be activated during this period but 100% on the next one If miners continue signalling it. I just want to know, each activation period is 2016 blocks, how much time is that? like in days or weeks.

[TierNolan]

like in days or weeks.

It's 2 weeks (2016 blocks * 10 mins = 2 weeks). It is often slightly faster, if the hash rate is rising.