[Feature]: ☂ Validate withdrawal requests as part of bitcoin validation

[djordon]

Feature - Validate withdrawal requests as part of bitcoin validation

1. Description

This is a subtask of #286 and aligns with #782.

There are a bunch of properties that need to be checked when validating withdrawal requests as part of bitcoin validation. Finish the functions that check these properties during validation.

1.1 Context & Purpose

The flow for validating withdrawals is to create a report struct containing the key pieces of information about a withdrawal request. They include:

1. The double spend check. Check whether the qualified request ID is in the bitcoin_withdrawals_outputs table, and that any of the associated txids are confirmed on the canonical bitcoin blockchain. Fail the withdrawal request if such a transaction was found.
2. The request exists. Check whether the associated withdrawal request transaction is confirmed on the canonical stacks blockchain. Fail the withdrawal request if it is not on the canonical stacks blockchain.
3. The request is final. Check that we’ve seen six new bitcoin blocks since observing the bitcoin anchor block associated with the Stacks block confirming the withdrawal request transaction. Fail the withdrawal request if we’ve observed less than 6 bitcoin blocks since the anchor block.
4. The request is collectively approved. Check if the request has enough votes. Fail the withdrawal request if we do not have enough votes.
5. The request is approved locally. Check if you have approved the request. Fail the withdrawal request if we did not approve the withdrawal.
6. Within fee bounds. The assessed fees will be within the constraints of the max-fee. Fail the withdrawal request if the assessed fee was greater than the max-fee.
7. The request has not expired. Check if less than X bitcoin blocks have been confirmed since the anchor block confirming the withdrawal request transaction. Fail the withdrawal request if we’ve observed X or more bitcoin blocks since the observing the associated anchor block.
8. The withdrawal amount is valid. Check that the withdrawal amount is greater than some dust amount. This is checked in the smart contract as well, but we should check it too. Fail the withdrawal request if the withdrawal amount would validate some bitcoin enforced minimum dust amount.
9. The withdrawal amount is within the cap. Check that the withdrawal amount is less than or equal to the withdrawal cap. Perhaps there is a per-bitcoin withdrawal amount cap as well. Fail the withdrawal request if the withdrawal amount if greater than the withdrawal cap.
   I think that that's it. All other things are implicitly handled by the design laid out in [Design]: Signing bitcoin transactions #782.

2. Technical Details:

2.1 Acceptance Criteria:

• Add functions for validating the withdrawal requests as part of bitcoin validation.

3. Related Issues and Pull Requests (optional):

• relates to [Feature]: Validate bitcoin transaction sign requests #286.
• relates to [Design]: Signing bitcoin transactions #782.

4. Appendix

Withdrawals are handled in the same flow described in section 3 of #782, which means the coordinator sends the request IDs, both deposit and withdrawal request IDs, and each signer is responsible for constructing the sighash that they will or won’t sign.

The two anchors that prevents double spending is the fact that the signers must spend the outstanding UTXO, and the signers have a record of all inputs and outputs included in prior sweep transactions, along with the associated request data in their databases. What happens is the following:

1. The coordinator sends a BitcoinPreSignRequest to all signers to begin validation. This is necessary in order to sweep any funds.
2. The signers run validation on the deposit and withdrawal requests identified in theBitcoinPreSignRequest. They write nothing into their databases if:
   1. There is a network or hardware error (such as when the signer cannot connect to their database).
   2. The pre-validation checks fail, which means the request itself is invalid (perhaps it contains duplicates or no requests at all).
   3. They do not have a record of one or more deposit or withdrawal requests.
   4. The sum of deposit requests amounts would collectively exceed the max supply cap of sBTC. This behavior should probably change where the signers write stuff to their databases but note that the associated sighashes have failed validation.
3. If the above conditions in (2) aren’t triggered, then the signers write rows to the bitcoin_txs_sighashes and bitcoin_withdrawals_outputs tables.

When the coordinator asks for a signature, they check whether the associated sighash passed validation and sign for it if it passed.

For withdrawals, check whether the qualified request ID is in the bitcoin_withdrawals_outputs table. There could be many rows for the same qualified request ID, because of RBF. The double spend check is to see if any of the associated txids are confirmed on the canonical bitcoin blockchain. If the above check is true then the bitcoin transaction must fail validation.

Suppose a BitcoinPreSignRequest fails the 4 conditions above for one signer, but passes for the others (and passes validation generally). Then the one signer will not know that the funds were swept out, and they may try to sweep out the funds themselves when they are the coordinator. However, the other signers will reject any attempt to construct such a transaction, since they know about the original sweep.