[Bug]: Coordinator can delay formal rejection of withdrawal

[djordon]

Bug - Coordinator can delay formal rejection of withdrawal

1. Description

Before signing a stacks transaction rejecting a withdrawal, the signers have 3 main checks:

1. Whether the withdrawal has expired,
2. Whether a sweep transaction fulfilling the withdrawal is in the "mempool", and
3. Whether a sweep transaction (without an output fulfilling the withdrawal) has 6 confirmations since the last time the withdrawal has been considered in a sweep transaction.

The issue is with conditions (2) and (3). The coordinator can disrupt the rejection of the withdrawal request by pretending to "consider" the withdrawal request. In this case, the other signers will reject the attempt, however this attempt still counts as toward the withdrawal being considered in a sweep transaction and being in the "mempool".

2. Technical Details:

There are at least a couple of solutions:

1. Only consider withdrawals that have passed validation when checking the database for whether the withdrawal has been considered or in the mempool.
2. Change the smart contract to be fork aware, so that we can skip check (3) altogether.

I propose we do both. The change in (1) is easy to make, while the change in (3) offers a better user experience since check (3) would be gone and the signers could reject a withdrawal sooner.

2.1 Acceptance Criteria:

• It is not possible for a malicious signer to delay rejection of a withdrawal request by pretending to consider a withdrawal request for inclusion in a sweep transaction.

3. Related Issues and Pull Requests (optional):

• The reason why withdrawals expire is because they can remain unfulfilled indefinitely if accepted and unfulfilled. This was brought up in [Design]: Stalled Withdrawal Requests #620 and [Feature]: Incorrect fee estimation causes sBTC to be locked up indefinitely #746.
• See [Design]: Mitigating de-peg risks during withdrawals #1363 for a brief description of why we consider the "mempool" at all. See feat: check mempool for withdrawal outputs before rejection #1406 (comment) for why we use the database for the bitcoin mempool in this situation.

4. Appendix

Because of #620, the purpose of rejecting withdrawals has drifted from the original design. Originally, withdrawals were only accepted or rejected because of the signers' votes. A withdrawal can be accepted by votes but practically rejected because of the fees are too low.