sBTC Design - Liveness and Peg Wallet Failure Mitigation

[AshtonStephens]

This is a research discussion post that details the procedure that will need to occur in the event of either of the two scenarios:

1. signer liveness failure: fewer than 70% of signers by weight are responding to deposit / withdrawal requests.
2. funds run out to pay for peg wallet transfer fees: the event that there are not enough funds to pay for a necessary peg wallet handoff fees prior to the implementation of Recovery mode proposed in SIP-025 as future work.

In the current SIP-025 proposal, the stacks blockchain will halt when too few signers by weight are responding to peg-in/peg-out requests or in the event that the peg wallet has too few Satoshis to fund wallet handoff fees.

[jcnelson]

1. This represents a quorum failure. Recall that signers don't need to agree on a deposit or withdrawal in order to prove that a quorum are online. Instead, it's sufficient to create a transaction signed by individual stackers' keys (instead of signed by WSTS) which indicates the participating stackers' votes for/against the operation. If these individual signatures account for over 70% of the stacked STX, then the system remains live but the deposit/withdrawal does not happen. However, a quorum failure would be irrecoverable, because then blocks couldn't even be produced.

2. The mitigation we discussed on the design call was to require Stackers to immediately consolidate outstanding deposit UTXOs with the wallet UTXO as part of the deposit's completion (see the diagram here). Then, the act of transferring the wallet funds to the next reward cycle's Stackers is the act of spending a single UTXO with O(1) outputs (e.g. an OP_RETURN and the new wallet UTXO). This transaction would be smaller than a block-commit, so it would have a good chance of getting mined if miners themselves are able to send block-commits (if they can't do so due to prohibitive fees, then a failure to transfer the wallet funds would be immaterial). But, in the event that this transaction's fee cannot be made high enough (e.g. the "war chest" is too little), the Stackers can sign this transaction with SIGHASH_ANYONECANPAY (see here) in order to permit someone else to spend additional UTXOs to fund the requisite transaction fee. In this failure mode, Stackers would create and publish this transaction to their StackerDB, and someone would have to manually download the transaction, attach their UTXOs, sign them, and broadcast the Bitcoin transaction. However, once downloaded, this is something you can do with most Bitcoin wallets.

[AshtonStephens]

Off the edge of the map; but we considered including an unwind script which would require that all BTC in the peg wallet have a backdoor to allow trusted principles to unwind. That is peculiar

We should analyze:

1. What is the overall scenario that requires this and is that necessary / assumptions
2. What would the unwind look like.
3. What are the concerns about the trusted third party.

Not included in this SIP due to perceived risk

[AshtonStephens]

This should be part of a larger discussion and will be more involved if stacks get more market.

Sufficient to say that this is possible IF we can get manual 70% ability to agree to unwind.

We could implement some kind of timelock and upgrade the system so that people keep some X number of previous keys. This is out of scope for V1. Consider implementing w/ Recovery mode.