Deposit Challenges using only Clarity

[hstove]

Note that * indicates that we are mentioning a separate aspect of sBTC V1, which is not defined here.

tl;dr

Previous specs related to this topic include a voting mechanism for signers to verify and accept blocks. I'm proposing a "clarity-only" mechanism, which doesn't rely on signers at all. This has better guarantees against signer misbehavior, network issues, and other errors.

Intro

When users make a deposit transaction, the "normal" behavior is that their BTC transaction information is sent to a relayer*. Once the relayer picks up the peg-in details, a contract call is made in the sBTC contract*, and the user is minted sBTC. This behavior is the "happy path".

Once a BTC deposit transaction is made, we cannot guarantee that the user will end up with minted sBTC. There are many potential reasons for this, such as:

• The relayer service doesn't properly propagate the deposit information
• The user doesn't successfully send their deposit information to the relayer
• The deposit's fee rate is not high enough

This discussion outlines the behaviors and mechanisms surrounding the scenario where the user isn't automatically minted sBTC.

Deposit Challenges

In the case that a user's deposit does not automatically mint sBTC, the .sBTC contract provides a challenge mechanism, where the user can directly provide their deposit information on-chain. By allowing direct on-chain interaction, users have improved guarantees about liveness.

To issue a challenge, the user can call the challenge function within sBTC. They provide the following information:

• Their BTC transaction, serialized as a buffer
• Information for verifying transaction inclusion:
  • The merkle proof of their BTC transaction within a block
  • The block height in which the BTC transaction was confirmed
• Information for verifying that the correct output was used:
  • Data that can re-construct the correct signer-spendable output, such as their STX recipient principal
  • Data, such as their recovery public key, that allows for verifying the recovery tapleaf.

The challenge function verifies the deposit transaction using Clarity-defined logic. If the challenge is successful, the user receives sBTC. By providing a "Clarity-only" route, any issues around signer connectivity are eliminated.

challenge function

Inside of the challenge function, the .sBTC contract executes the following actions:

1. Verify that the BTC transaction was confirmed
2. Verify that the transaction hasn't already been part of a successful deposit or challenge
   1. Note: this requires state for tracking already-deposited BTC txids within the .sBTC contract
3. Parse the BTC transaction and collect the deposit output
4. Verify the output:
   1. Verify the signer-spendable tap leaf*
   2. Verify the recovery tap leaf*
5. Verify that the transaction was confirmed within X blocks from now
   1. Reasoning and more information described below
6. Verify the fee rate of the transaction
   1. First, get the current sBTC fee rate, which is set by the signers
      1. We need the current fee rate, instead of the rate at the time of deposit, to ensure the signers can economically consolidate the UTXO
   2. Extract the "fee" of the deposit output by comparing the output's value to the amount property of the signer-spendable tap leaf
      1. Note: this requires specifying an amount within this tap leaf
   3. Validate that the fee of the deposit is at least 2x the fee specified by the signers
7. Store the txid as "successful"
8. Mint sBTC to the user

Verifying that the deposit was made within X blocks from now

Inside of every deposit output is a tap leaf containing a recovery script, which allows the user to recover their deposit in the case that their deposit was not successful. Part of this recovery script is a basic time-lock, using $RECOVERY_BLOCKS CHECK_SEQUENCE_VERIFY. The value $RECOVERY_BLOCKS is a fixed value defined by the protocol.

Because users are able to challenge their deposit using only on-chain data, the sBTC protocol must ensure that the challenge was made before the recovery timelock has expired. Without doing that, users can utilize an attack vector where they recover their deposit and still mint sBTC, thus "double spending".

The protocol defines a MAX_CHALLENGE_PERIOD constant, which is the maximum amount of blocks after a deposit that a challenge may occur.

It is important that the protocol defines the constants MAX_CHALLENGE_PERIOD and RECOVERY_BLOCKS to balance two factors:

• MAX_CHALLENGE_PERIOD cannot be too low (such as 1 block), so that users have time to challenge
• MAX_CHALLENGE_PERIOD is not too close to RECOVERY_BLOCKS, so that signers have time to redeem challenged deposits

To be more specific on the meaning of these two constants:

• RECOVERY_BLOCKS is a constant used in conjunction with CHECK_SEQUENCE_VERIFY to define a relative amount of blocks after confirmation that the output can be spend. For example, if RECOVERY_BLOCKS is 100, the script is spendable 100 blocks after confirmation.
• MAX_CHALLENGE_PERIOD defines the maximum amount of blocks, relative to the confirmation of the deposit, during which the deposit can be challenged. For example, with a value of 50, the user has 50 blocks to confirm a challenge transaction on Stacks.

Discussion topics

• Verifying challenge deposits on-chain is a relatively expensive operation, especially compared to a mechanism where signers vote on challenges. At the same time, the increased cost and complexity in Clarity greatly reduces the complexity needed for signers to validate and vote on challenges. What other complexity trade-offs are there?
• While going through this document, it brought my attention to a few things that are not defined in previous docs:
  • The sbtc_payload in a deposit's output needs to include an amount, so that we can compare amount to output.value and verify fees. This is probably already considered, but I didn't see it in the docs.
  • The protocol "fee" determined by signers shouldn't be a sats/vByte value, and instead should be a fixed fee amount (in Sats). This is because the signers only need to care about the relative cost of redeeming a single deposit UTXO. Caring about the overall fee rate of the transaction adds complexity and is less accurate in determining the economics of redeeming the UTXO.
• What are some appropriate values for RECOVERY_BLOCKS and MAX_CHALLENGE_PERIOD. My ideas are:
  • Because signers already need to be redeeming UTXOs every block, my thought is that the difference between these two values should be a small amount, such as ~5-10 blocks.
  • MAX_CHALLENGE_PERIOD should be pretty high (perhaps up to 1-2 days), because this provides users enough time to realize and submit challenges.
  • In sum, my vote is:
    • RECOVERY_BLOCKS: 2 days, or 288 blocks
    • MAX_CHALLENGE_PERIOD: 275 blocks

[netrome]

Note: Before sBTC was dropped, there seemed to be a general idea floating around that Signers would accept deposits in a consolidation transaction with an OP_RETURN to trigger sBTC mints. This design would eliminate the need for the RECOVERY_BLOCKS and MAX_CHALLENGE_PERIOD.

The best historic references I have for this design are Jude's comment in the Revealer API discussion and Fernando's comment in the sBTC SIP working doc:

I believe that nodes will only be able to execute a mint contract call if they have a valid signature. The node will check for this at every new Bitcoin block. However, I would be interested in knowing how we handle the situation where a valid Schnorr proof is sent for a deposit that occurred in a past block.

I have tried to clarify these ideas in the Deposit and Withdrawal flows discussion, which should hopefully shed some light in how I interpret that we envision these user flows to look.

[hstove]

A higher-level question being addressed here, which may not be a requirement of v1, is whether we care about providing a fallback for a user if their BTC deposit is consumed without having minted sBTC.

Once a deposit TX is confirmed, and the details are revealed, the signers can consume their deposit UTXO immediately. This discussion does introduce an ability for a deposit to mint sBTC without the UTXO being consumed by the signers. So, we have two opposing problems:

Either:

• A deposit UTXO can be consumed without having sBTC minted
• A deposit can result in minted sBTC without the signers consuming the UTXO

Unless I'm mistaken, you can't have both. This discussion is saying "If you make a valid deposit, and you reveal that information in a short enough amount of time, then it's on the signers to consume it".

[netrome]

Nice formulation. I believe you are mistaken here though. The way I see it, consuming the deposit UTXO in a "deposit accept" transaction (or the sBTC Signer transaction) would always result in sBTC being minted, because the nodes would be forced by consensus to mint sBTC whenever a Bitcoin block contains this data.

In a non-consensus breaking version where the Signers explicitly call mint after consuming the deposit UTXO, I agree with your described tradeoff.