Due to the need for finality, RSK consensus does not attempt to recover from an attack that manages to revert the blockchain deep enough to revert a final peg-in or peg-out transaction. If a huge reversal occurs, Powpeg nodes halt any future peg-out, and the malicious actors should not be able to double-spend the peg.
Is this “halt” process described in detail anywhere? How many blocks does the “huge reversal” need to be to trigger this halt? How do the nodes recover from the halt? Any other important info to know about this?
There are two types of “halts”. A consensus halt and a hardware halt.
The consensus halt occurs if the RSK blockchain is reversed past a peg-out, then the bridge contract may decide to re-use the UXTO (because the reversal caused it to become unspent again). This basically makes the peg-oout invalid and all peg-outs depending on change outputs of that transaction invalid too. To recover from this situation, a hard-fork is needed where the UTXO is manually marked as spent, and later someone should donate the missing funds to the bridge to keep the 1:1 peg credible.
The other halt is a hardware one: If the PowHSM confirms a block with 4000 confirmations at the current difficulty (the cumulative difficulty of 4000 blocks), then that block becomes frozen and the PowHSM cannot undo it. Which means that the PowHSM do not withstand a 4000-block reorg.
4000 blocks is approximately 36 hours at the current block rate.
It is highly unlikely that such a reorg can occur, both because it requires so much hashing power but also because it would be visible on the Bitcoin blockchain , and the Armadillo system will detect it sooner than the 4000 block deadline is reached.
4000 RSK blocks measured in cumulative proof-of-work.
Currently it’s still possible to perform a firmware upgrade if the pegnatories accept such a procedure. Firmwares are authenticated, so this can only happen if both all the pegnatories agree and the firmware coders sign it., for the PowHSM device to accept the upgrade.
However this option may not be available in the near future: Some of us have discussed the idea that firmware hashes should be posted onchain and certain community members should sign the hash before the PowHSM accepts switching to this new firmware. This would be an enforced delay to prevent non-community approved changes in PowHSM firmwares.
If this protection is accepted (via RSKIP), then upgrading the firmware won’t be an option anymore. The only and last recourse will be using the emergency multisignature.
The documentation is the code. Better documentation is certainly needed.