The RSK Emergency Multisig

For many years, it was believed that the federated model was the best method to secure the two-way-peg of a Bitcoin sidechain without requiring a Bitcoin hard or soft fork. All other more decentralized potential solutions required either a Bitcoin soft-fork or the use of a new competing token to collateralize the peg. In early 2020, IOV Labs invited the entire RSK community to hold several online meetings to discuss how to improve the security of the RSK peg to Bitcoin. The ideas that emerged in those meetings laid the foundation of a tremendous core development effort to create the Powpeg in the following months and whose first fruits saw the light in December 2020, when the first PowHSMs were shipped. The Powpeg goal was to remove any human control of the private keys comprising the Federation multisig. Pegnatories would no longer be able to manually sign anything, extract the private keys, or even backup them in encrypted form. The PowHSM were build using an HSM device (hosting a Secure Element) that protects the private keys and follows RSK consensus on when to sign with them. Maximum security!

Designing the PowHSMs

In the early discussions, it was agreed that we wanted to be able to expand the number of pegnatories to hundreds using Schnorr signatures (very soon to be activated in Taproot), and for that we needed the HSMs to be cheap off-the-shelf programmable devices. Yet the PowHSMs would need to provide maximum security protecting the private keys from side-channel attacks. We decided that the ST31 family of Secure Element chips (CC EAL5+ certified) provided all these benefits. Everything seemed fine until we analyzed the risks.

The Risks

In those meetings, some cautioning voices were heard. One of them was a security expert from Coinspect that warned of several potential risks including firmware bugs, flash memory failures, other board component failures, and censorship or seizure of the devices. Here, we briefly describe each one.

Firmware Bugs

The Powpeg follows consensus using a low-footprint C code library that parses RSK blocks. However, this code differs from the Java-based reference node (rskj). If for any reason a mined block failed consensus by the HSM but it was accepted by the RSK network, then all PowHSM devices could become simultaneously (and potentially irreparably) bricked. All pegged funds would become inaccessible.

Flash Memory Failure

Another RSK community member, who had worked in embedded systems before, expressed concerns that the PowHSM devices would be writing the internal Flash memory frequently, and the ST31 manufacturer guarantees only 500K successful write-cycles. Afterwards, the device could cease to work or fail unexpectedly. If the PowHSM updated a Flash sector on each block header processed, the device would have a lifetime of only only 175 days! To be safe, the firmware was designed to process blocks in batches. Still, if the failure probability raises sharply after 500K cycles, there is a risk that all devices burn out at the same time, as they all perform exactly the same pattern of writes operations. A concurrent failure of the majority of devices would prevent performing a Powpeg membership change, which is a time-delayed subprotocol commanded by the RSK Bridge smart-contract. Even if the manufacturer guarantees a certain number of write-cycles, we can’t trust these figures blindly, as components vary depending on the production batch.

Board Failure

Another risk identified in the meetings was that the devices would be under a stress uncommon in the most frequent uses of the chip (i.e. credit card purchases or hardware wallets), so the reliability of the ST31 chip and remaining components in the circuit board would not be battle-tested. What if some component failed? What if devices could not be repaired? Was if the main ST31 chip burned as a consequence of a badly filtered power circuit?

Censorship and Seizure

Finally, in a Powpeg, the pegnatories have almost no power over the bitcoin funds. However, if the majority of pegnatories decided to (or were forced to) turn off their PowHSM devices, then the bitcoins will be locked forever. Whoever keeps the devices offline could demand a ransom for bringing them back online. If they are held by a malicious government, they could demand the censorship of certain users before enabling peg-outs again.

The Agreement

To address all these objections, the community agreed that the simplest solution was to introduce an emergency backup multisignature that would only be activated in case of an unforeseen catastrophe. To make sure the multisig wasn’t activated by mistake, the RSK community decided to put a time-lock lasting at least one year, renewed periodically. That would give enough time for the RSK community to solve any consensus or malfunction issue.
The community reaffirmed this conservative choice of a one-year time-lock after witnessing a failure in the emergency multisignature in the Liquid blockchain, which was accidentally activated in June 2020 due to a bug, and because it used a short time-lock of barely a two weeks. That is why, starting from the Iris network upgrade, the RSK bridge address scriptPub contains a subscript that represents this time-locked emergency signature. This construction is specified in RSKIP201. The time-lock expires after one year of complete inactivity of the UTXO, and UTXOs are periodically renewed, extending the time-lock. The renewal protocol is defined in RSKIP207.

The Private Keys

The RSK community doesn’t like single point of failures, so the emergency multisig would be kept secure by a threshold of signatories. But the more signatories participate in an emergency multisig, the higher the effort the community has to do to verify the signatory well-intentions and authenticate signatories’ public keys. Also the more emergency signatories are added, the more expensive each peg-out transaction becomes. Therefore the RSK community decided to offer keys to a few but renowned community participants:

• 1 key to IOV Labs, based on its proven past commitment to the expansion and security of the RSK platform
• 1 key to the leader of the RSK core development team.
• 1 key to a renowned Bitcoin core developer or contributor.

Since the Iris network upgrade was delayed, and RSK saw enormous growth in community projects in 2021, it was decided to extend the multisig with one more signatory, and one key was offered to a renowned contributor of the mostly used community projects. According to transaction statistics, the two most popular dapps on RSK are Sovryn and Money on Chain. Both projects were invited to hold a key and Money on Chain accepted the fourth key. What originally was a 2 out of 3 multisig, became a 3 out of 4 multisig. Currently, Jameson Lopp, the CTO of Casa, has agreed to be the signatory representing Bitcoin and has already provided a public key signed by a Keybase key, which authenticated it. Adrian Eidelman, the leader of the RSK core development team and Money on Chain, also agreed.

The Future

While the decision to include the emergency multisignature was made by the RSK community and reaffirmed on a number of occasions, the RSK improvement process can be used to deactivate or improve this feature in the future. A better solution may become available or the risks identified may be mitigated by other means. Several potential Bitcoin soft-forks could increase the security of RSK reducing the need for the emergency multisig. Here I propose several improvement paths to explore.

MAST: the number of signatories in the emergency multisig can be increased using MAST in Taproot to keep peg-outs cheap. This reduces the risk of hijacking the majority of PowHSMs.

Emergency Powpeg: A fully backup Powpeg with 12 additional PowHSMs can be created (but kept inactive). This reduces the risk of a malicious attempt to force the time-lock to expire to reduce the security of the peg.

Virtual Outputs: Bitcoin could implement virtual outputs (VUTXOs). These are succinct aggregated outputs whose members can be spent using Merkle paths. VUTXOs can be implemented using transactions with covenants. A virtual output contains a covenant to expand a Merkle tree node/output into two additional tree nodes or outputs. VUTXOs could enable the creation of periodic snapshots of RSK user balances in a single succinct time-locked script path in the Powpeg address, so that bitcoins can be distributed automatically to their rightful owners in case of catastrophe.

Schnorr Signatures: Taproot activation enables short Schnorr threshold signatures, so the number of pegnatories can grow to hundreds, mitigating censorship concerns. It only requires that signatures are constructed by PowHSMs in two rounds.

Multiple HSMs: The risks that motivated the use of the emergency multisig could be reduced if, for example, each pegnatory runs two HSMs created by two different manufacturers. The main drawback is that this solution would take a high additional development effort.

Conclusion

The RSK community values the security of user funds above any other feature. To evolve the Federation into the Powpeg, the community proposed the addition of an emergency multisig to protect RSK from some perceived risks at the time the decision was made. Consensus took a long time, but it was achieved by accepting the combo Powpeg + emergency multisig. However, some RSK users have now expressed their willingness to re-evaluate this trade-off and improve the multisig security in new ways. Rushing to make changes is not a characteristic of the RSK community, and broad consensus must be reached again for any important change. The Iris network upgrade is around the corner, and the new release has been audited by a third party, and it is being tested in an alpha testnet. I’m sure that in the following network upgrades we’ll have the chance to improve the emergency multisig.

At the same time, new alternative two-way pegs created by particular groups in the RSK community may be based on different designs, take some risks and adopt completely different censorship/security trade-offs. That is ok as long as users are fully informed of the security model adopted. However, the RSK native peg needs to provide the highest security assurance, and that means taking a conservative approach.

You can read more information about the Powpeg here and here.