Multi-Phased Fork (Spork) - Revision history

TheSin: TheSin moved page Multi-Phased Fork ("Spork") to Multi-Phased Fork (Spork)

2018-01-16T21:44:00Z

TheSin moved page Multi-Phased Fork ("Spork") to Multi-Phased Fork (Spork)

TheSin: TheSin moved page Spork to Multi-Phased Fork ("Spork")

2018-01-16T21:42:50Z

TheSin moved page Spork to Multi-Phased Fork ("Spork")

TheSin at 21:30, 16 January 2018

2018-01-16T21:30:04Z

TheSin: Created page with "In response to unforeseen issues with the rollout of the major "RC3" update in June 2014, the Dash development team created a mechanism by which updated code is released to th..."

2018-01-16T21:29:35Z

Created page with "In response to unforeseen issues with the rollout of the major "RC3" update in June 2014, the Dash development team created a mechanism by which updated code is released to th..."

New page

In response to unforeseen issues with the rollout of the major "RC3" update in June 2014, the Dash development team created a mechanism by which updated code is released to the network, but not immediately made active (“enforced”). This innovation allows for far smoother transitions than in the traditional hard fork paradigm, as well as the collection of test data in the live network environment. This process was originally to be called "soft forking" but the community affectionately dubbed it "the spork" and the name stuck!

New features or versions of Dash undergo extensive testing on testnet before they are released to the main network. When a new feature or version of Dash is released on mainnet, communication is sent out to users informing them of the change and the need for them to update their clients. Those who update their clients run the new code, but it is not activated until a sufficient percentage of network participants (usually 80%) reach consensus on running it. In the event of errors occurring with the new code, the client’s blocks are not rejected by the network and unintended forks are avoided. Data about the error can then be collected and forwarded to the development team. Once the development team is satisfied with the new code’s stability in the mainnet environment – and once acceptable network consensus is attained – enforcement of the updated code can be activated remotely by multiple members of the core development team signing a network message together with their respective private keys. Should problems arise, the code can be deactivated in the same manner, without the need for a network-wide rollback or client update. For technical details on individual sporks, see [[Understanding_Sporks here]].

<youtube width="560" height="315">rp-ebgbgK-M</youtube>

← Older revision	Revision as of 21:44, 16 January 2018
(No difference)

← Older revision	Revision as of 21:42, 16 January 2018
(No difference)

@@ Line 1: / Line 1: @@
 In response to unforeseen issues with the rollout of the major "RC3" update in June 2014, the Dash development team created a mechanism by which updated code is released to the network, but not immediately made active (“enforced”). This innovation allows for far smoother transitions than in the traditional hard fork paradigm, as well as the collection of test data in the live network environment. This process was originally to be called "soft forking" but the community affectionately dubbed it "the spork" and the name stuck!
-New features or versions of Dash undergo extensive testing on testnet before they are released to the main network. When a new feature or version of Dash is released on mainnet, communication is sent out to users informing them of the change and the need for them to update their clients. Those who update their clients run the new code, but it is not activated until a sufficient percentage of network participants (usually 80%) reach consensus on running it. In the event of errors occurring with the new code, the client’s blocks are not rejected by the network and unintended forks are avoided. Data about the error can then be collected and forwarded to the development team. Once the development team is satisfied with the new code’s stability in the mainnet environment – and once acceptable network consensus is attained – enforcement of the updated code can be activated remotely by multiple members of the core development team signing a network message together with their respective private keys. Should problems arise, the code can be deactivated in the same manner, without the need for a network-wide rollback or client update. For technical details on individual sporks, see [[Understanding_Sporks here]].
+New features or versions of Dash undergo extensive testing on testnet before they are released to the main network. When a new feature or version of Dash is released on mainnet, communication is sent out to users informing them of the change and the need for them to update their clients. Those who update their clients run the new code, but it is not activated until a sufficient percentage of network participants (usually 80%) reach consensus on running it. In the event of errors occurring with the new code, the client’s blocks are not rejected by the network and unintended forks are avoided. Data about the error can then be collected and forwarded to the development team. Once the development team is satisfied with the new code’s stability in the mainnet environment – and once acceptable network consensus is attained – enforcement of the updated code can be activated remotely by multiple members of the core development team signing a network message together with their respective private keys. Should problems arise, the code can be deactivated in the same manner, without the need for a network-wide rollback or client update. For technical details on individual sporks, see [[Understanding_Sporks]].
 <youtube width="560" height="315">rp-ebgbgK-M</youtube>