fork monitor
On block 298000 (approximately February 3rd) the Sia blockchain will fork to stablish a funding mechanism for the
Sia Foundation (
read more here
). This is a non-contentious fork, as no
mining pool or other entity has claimed the will to maintain the old blockchain. No "new coins" or "airdrops for holders" will result
from this fork. Nevertheless, this tool will track in real time the outcome of this fork and milestone in the Sia history.
This monitor consist in two Sia nodes: one using the latest Sia software that will follow the fork and another one using an older
version and so synced to the legacy blockchain that will not accept the fork. Once the fork height is reached, color-coded boxes will be added
representing blocks and different circumstances. The monitor checks both blockchains detecting if
one of them stalls and gets abandoned, if both are being kept mined, or if blockchain rearrangements are happening between both chains.
The following scenarios represent these different possibilities, and how you can interpret the data in the box above.
Scenario 0: no split (transitory situation):
Even after the fork height is reached, it is possible that both blockhains keep adding the same blocks, keeping the fork ongoing and not completed. This is because for the actual fork to happen, a transaction incompatible with the old software needs to get added to the main chain. An example could be the Sia Foundation transferring its subsidy to a new address: the Sia 1.5.4 clients would accept it as valid, but the old ones would not, as those coins do not exist in the rules of the legacy chain. This situation can last minutes, hours or even days, until the incompatibility takes place. The monitor will represent both chains adding blocks simultaneously.
Scenario 1: the legacy blockchain gets abandoned:
If no mining pool uses the old Sia client, after the split the old blockchain will not get any new additional block. This will induce the legacy chain to stall and be efectively abandoned. This is the most likely scenario, as no entity has declared it will support the legacy chain, so coins mined for it will be worthless. The monitor will represent this with the legacy chain not adding blocks (empty boxes) and a pause icon, while the main chain keeps adding them (full colorless boxes).
Scenario 2: both chains are mined:
No mining pool or entity has declared they will support the legacy chain. But if a mining pool accidentally fails to update their Sia software on time, they will mine blocks for the legacy blockchain, inducing a network split. The split block will be represented with an "Y", and the divergent blocks in the shortest chain (presumably the legacy) will be shown as yellow boxes. This scenario represents no danger, but it could create inconveniences for regular users that fail to update on time, as they will be synced to a wrong blockchain and will need to sync again to get unstuck.
Scenario 3: rearrangements and wipeouts (hypothetical):
If a) a split happens, b) the code of the fork does not have replay and wipeout protections, and c) the legacy blockchain adds blocks faster than the main one, blocks from the main chain could be replaced with blocks from the legacy chain. This would happen because blocks from the upgraded chain are not compatible with the legacy chain, but not viceversa: if the legacy chain is longer, software clients from the upgraded client will drop their blocks and accept the legacy blocks. This is called a blockchain reorganization ("reorg") and specifically a wipeout in the context of a fork. This is a dangerous situation if the reorg is several blocks depth, as transactions can get removed, creating accountability issues to exchanges, mining pools and others. The reorganized blocks will be represented in this monitor as red boxes on the main chain.
This last scenario is not possible during this fork, as the Sia team purposely added protections to the fork that protect both sides of it from block shuffling. Additionally, all the known mining pools have confirmed their intention to upgrade in time for the fork. Nevertheless, this information is presented here for educational purposes and this tool will verify no reorgs take place. In case of wipeouts, additional confirmation can be collected from the consensus.log files of online Sia clients and from other external tools (SiaStats for example operates another independent internal tool monitoring regularly blockchain reorgs).
The following scenarios represent these different possibilities, and how you can interpret the data in the box above.
Scenario 0: no split (transitory situation):
Even after the fork height is reached, it is possible that both blockhains keep adding the same blocks, keeping the fork ongoing and not completed. This is because for the actual fork to happen, a transaction incompatible with the old software needs to get added to the main chain. An example could be the Sia Foundation transferring its subsidy to a new address: the Sia 1.5.4 clients would accept it as valid, but the old ones would not, as those coins do not exist in the rules of the legacy chain. This situation can last minutes, hours or even days, until the incompatibility takes place. The monitor will represent both chains adding blocks simultaneously.
Scenario 1: the legacy blockchain gets abandoned:
If no mining pool uses the old Sia client, after the split the old blockchain will not get any new additional block. This will induce the legacy chain to stall and be efectively abandoned. This is the most likely scenario, as no entity has declared it will support the legacy chain, so coins mined for it will be worthless. The monitor will represent this with the legacy chain not adding blocks (empty boxes) and a pause icon, while the main chain keeps adding them (full colorless boxes).
Scenario 2: both chains are mined:
No mining pool or entity has declared they will support the legacy chain. But if a mining pool accidentally fails to update their Sia software on time, they will mine blocks for the legacy blockchain, inducing a network split. The split block will be represented with an "Y", and the divergent blocks in the shortest chain (presumably the legacy) will be shown as yellow boxes. This scenario represents no danger, but it could create inconveniences for regular users that fail to update on time, as they will be synced to a wrong blockchain and will need to sync again to get unstuck.
Scenario 3: rearrangements and wipeouts (hypothetical):
If a) a split happens, b) the code of the fork does not have replay and wipeout protections, and c) the legacy blockchain adds blocks faster than the main one, blocks from the main chain could be replaced with blocks from the legacy chain. This would happen because blocks from the upgraded chain are not compatible with the legacy chain, but not viceversa: if the legacy chain is longer, software clients from the upgraded client will drop their blocks and accept the legacy blocks. This is called a blockchain reorganization ("reorg") and specifically a wipeout in the context of a fork. This is a dangerous situation if the reorg is several blocks depth, as transactions can get removed, creating accountability issues to exchanges, mining pools and others. The reorganized blocks will be represented in this monitor as red boxes on the main chain.
This last scenario is not possible during this fork, as the Sia team purposely added protections to the fork that protect both sides of it from block shuffling. Additionally, all the known mining pools have confirmed their intention to upgrade in time for the fork. Nevertheless, this information is presented here for educational purposes and this tool will verify no reorgs take place. In case of wipeouts, additional confirmation can be collected from the consensus.log files of online Sia clients and from other external tools (SiaStats for example operates another independent internal tool monitoring regularly blockchain reorgs).
