NOTE : If you want to read about basics of Bitcoin Improvement proposals and its need you can refer to this article : https://techandsecurity.net/how-are-changes-made-to-bitcoin-understanding-bitcoin-improvement-proposals-bips Even if you have not read that tha paragraph below will help you move on !
Every proposal in bitcoin has to be followed through a proposed procedure and as there is no central authority its the miners who work on that procedure ! To bring any change a BIP (Bitcoin Improvement Proposal) is proposed and to bring that change we do follow some procedure (which again most probably would be some BIP proposed in past). Its a completely decentralised blockchain and new BIP codes keep getting added to it (ones activated) and ones they are added bitcoin blockchan do follow those codes (as now they are part of the system). BIPs are used for adding new features or information to bitcoin and act as a communcation medium for sharing ideas among different nodes of bitcoin. BIP can be used for pointing a technical issue in degisn or working or suggested some new ways etc. Here the main focus is to show you the beaty of BIPs in bitcoin that is how one proposal gets accepted by using another proposal. Read thoroughly !
The main purpose of this article is to show you that updates in a decentralised blockchain have always been a problem. If you do not get something do comment below. Read thoroughly as it will help you understand a lot concetps related to functioning of blockchain and how updates are made in well established decentralised blockchains! The article doesn’t focus on segwit and segwit2x ( the changes they brought to bitcoin) it rather focuses on their Improvement proposals which will help your learn how a decentralised blockchain is handled in real world when some changes are to be made !
Segwit (BIP 141) was deployed on 27th october 2016 ( with the release of bitcoin Core verion 0.31.1 )
Segwit was to be activated via BIP 9 – a proposal that could be used to deploy multiple soft forks ( with backward compatibility).
You know well miners keep mining new blocks and the chances of mining any block are dependend on your hash power (probability of your mining the next block is your hash power devided by the total hash power on the network). Every proposal of bitcoin has some voting method – miners of blocks are supposed to vote for a favour of a change or update. Here for segwit 26 voting periods were proposed. Each period had 2016 blocks in it. Now the average time for mining one block is 10 minutes so it leads to 2016 * 10 minutes means 14 days ( you can calcualte yourself (2016 *10)/(24*60) ). The required voting is 95% during any voting period. Let me explain it in more simple way. Say the voting started from any block on 27th october 2016 so if 95% of the next 2016 blocks ( that is 1916 blocks ) would vot for the change ( that is they wanted segwit to be implemented ) then the segit aka BIP 141 will move in LOCKED_IN stage. If 95% voting could not be reached than the next period starts which again has 2016 blocks. So total 26 periods means nearly an year time was proposed for voting ( 14 days * 26 = 364 days) . Now if you are confused about how blocks would count as a vote then its pretty simple. Say you were a miner and you mine a block and you want to vote for the segwit implementation. You had to set sets bit 1 in the nVersion field of the block you mined. Those bit 1 “flags” are what are counted by BIP 9 when calcualting the voters. If any voting period achieved 95% voting than 2016 blocks after that period the status of segwit would be ACTIVE. Say suppose 16th time frame or period of voting (out of the 26 total periods) would achieve 95% voting then after 14 days of end of that period (16th period) Segwit would be ACTIVE in bitcoin.
Read carefully guys : bitcoin doesn’t have a centralised voting system ! the voting in bitcoin here is done via the blocks that are being mined. And this is something you will note in all major BIP.
Now the issue arose that despite of waiting so much the required voting percentage could not be reached. It was during 17th time period or time frame of bitcoin that the community became a bit irritated with segwit implementation via BIP 9. Some better way was needed to make this change. But bitcoin isn’t a centralised system. Its all about a mathematical algorithm that is being run by many nodes accross the world and it follows its laws. So community was to implement segwit by BIP 9 but use some trick to reach the goal. Several proposals were made and let discuss the two that were accepted by majority of community : UASF and Segwit2x proposals .
Note : Each period had 2016 blocks or 14 days of activity. So 26 periods means 1 year. Now even if in one year the required percentage could not be reached ( i mean none of the time period or time frame got 95% voting) the proposal of segwit could be redeployed with a new bit ( say some other bit that bit 1) because ones in actual sense its the bit that expires not the proposal. Also unless bit 1 assignment had expired no other bit could be assigned for same proposal. So if you thinking that we could move to say some other BIP and use some other bit for proposing segwit that won’t happen ( 1 proposal has 1 corresponding bit meant to be voted at one time). The same proposal can’t be deployed under more than 1 bit at a time.
Now if you read the above note carefully you would be clear that we could not deploy some other bit to same proposal ( but could go for some other proposals and implement them using some other bits , yeah other proposals i said). So goal was to go for some alternative that could complete the above proposal ( segwit had to be implemented with the BIP 9 as it was getting too late and waiting for 26 periods to end wasn’s a good idea ).
UASF chain (BIP 148) :
User Activated Soft Fork ( BIP 148 ) was to approach segwit implementation by making a 100 % 1 bit signaling chain (for segwit). Simply speaking on August 1 , 2017 all the blocks who want to support this proposal will start orphaning blocks that are not signalining bit 1 for segwit. Means chain will split. So there will be two chains now : a chain of blocks having all blocks signaling bit 1 and the other chain. So one chain would be having 100% blocks with each block signaling 1 bit for segwit proposal. The other chain would be having mix of two types of blocks ( the one signaling bit 1 and the one not doing that). What matters is that the chain having all the blocks as 1 bit signaling blocks can activate segwit now ( as more than 95% blocks in fact 100% are voting for the segwit).
NOTE : Suppose were a miner in this situation who were a supporter of segwit implementation. One chain accepts only blocks having 1 bit signals while the other accepts both kind of blocks. Now say there is a condition when the other chain (having both types of blocks) has a block with no 1 bit signal in it ( of course it has to happen because it accepts both types) while the chain supporting segwit has the last block with 1 bit ( of course as all blocks in this chain have 1 bit) my inputs for making the next block ( for generating required difficulty hash) would be the one of the 1 bit signaling block (last block of the chain i am supporting) and won’t fit the other chain. VIsualise what i said carefully. Some of you may develop a mentality as one chain is accepting both kind of blocks so its proof of work will always be greater and it will be longer and more powerful chain . No ! Visualise the things carefully. Every block needs some inputs which it derives from the last block ( blocks can’t fir the way you think). If majority would support this chain having only blocks with 1 bit signal would win even in net proof of work. Just visualise !
This approach was nearly same as the above UASF approach except a few differences. It also would orphan blocks not signaling bit 1 but prior to that it needs some other condition to be fulfilled.
Well it would start on 21st july. Just like miners were voting for segwit by using bit 1 here they will support segwit2x using bit 4. In order for Segwit2x to activate it requires that at least 80% of blocks over a short 336 block period signal bit 4. So like for segwit we had periods of 2016 blocks here we have periods of 336 blocks ( and 80% voting requirement rather than 95% ). On 1st august there had to be UASF (as described above) so this proposal would go till 1 august (if not completed i mean if any period did not get required percentage voting). So if you make a bit calculations you will not that there would be 3 periods during which required percentage could be gathered. If required percentage (80% is achieved) then it will be LOCKED_IN and will be ACTIVATED after 336 blocks ( there is a gap of 1 time period and meanwhile all miners can be notified). So ones ACTIVATED , segwit2x would follow exactly same thing as UASF code that is woudl start orphaning the blocks that were not signaling for segwit.
Note : As segwit2x was made by supporters of ‘New York Agreement’ (sometimes both are denoted by same names) the supporters of segwit2x would also include ‘NYA’ in the coinbase of any block that they mine and this was just to show their support ( and has nothing to do with actual voting signaling).
The second step of the New York Agreement was a hard fork to double Bitcoin’s “base block size” aka segwit2x hard fork. Segwit2x had a scheduled hard fork date set to occur about 90 days ( 12,960 blocks ) after Segwit activates on Bitcoin. Doesn’t matter how segwit would be implemented the miners would make a try implementing segwit2x after 12960 blocks (after segwit implementation). That is they would try to make a block of size more than 1 mb (which needs a lot of transactions). Also note that the the segwit2x code would reject a block with size less than 1 mb .
Above pic shows segwit2x code to reject the block 12,960 after Segwit activates if it is less than or equal to the legacy (1 MB) block size.
This block above 1mb would also be called “magic block”. And this is a must as to create a hard fork ( splitting a chain not compatible with the present chain) we would need a block more than 1 mb (visualise yourself how would the supporters of segwit2x differ this block from others if it would be less than 1 mb how would the chain split ? ).
Image above shows segwit 2x timeline
Now lets compare the two approaches :
Segwit2x approach was be a bit better approach as having 80% support shows clearly that majority people were ready for the change ! Which also meant that ehaven if these supporters would go for a split their chain would have more proof of work ( more hashpower implied to it) that the other competitive chain. So it was a better approach ! Also UASF would lead to soft fork and if the percentage power of this chain would be more than 50% ( which of course would be as 80% supporters already) than it won’t lead to split. If you got a bit confused here than wait for my post on hard and soft forks.