sBTC Design - Challenging Signers to Address Unaddressed Deposits

[AshtonStephens]

We've altered the sBTC design such that signers will not automatically take in deposits. This is to design the challenge behavior of the signers.

• What data is needed for a deposit challenge?

[AshtonStephens]

@jcnelson could you add some details here?

[AshtonStephens]

This feature is strictly required.

Similar to what the commit reveal design was before. The question is: how do we throttle a malicious challenger. We would need to make sure the user is not wasting the signers time, so the fee needs to be high enough to make that bad.

A reasonable way to handle this might be with a fixed fee.

1. How do we prevent the challenging from being a malicious DDOS
2. What information needs to be included in this challenge?

[AshtonStephens]

We should ask @xoloki to get to the bottom of this.

[jferrant]

We will need the stacks node to be able to parse the submitted info sufficiently to filter out challenges appropriately. It should automatically ignore ones that have already been fulfilled, i.e. not add them to the queue of pending deposits if it is malformed or associated with an already fulfilled challenge. Note that in the case of it being considered but not fulfilled, it is up to signers to record this info on chain. If they choose not to and the challenge is issued, the stacks node WILL add it to the queue of pending deposits and the signers MUST submit a transaction to the chain to prove it has been considered (either by submitting already stored result or rerunning the signing round) lest they be penalized for failing to perform their duties.

I am not 100% sure but I think the challenge must include the merkle root, the witness script, the internal public key to spend the script path, and the merkle path to the script?

See stacks-network/sbtc#44 for further context?

[jcnelson]

I was thinking the challenge flow would work as follows:

1. User submits a Stacks transaction to .sbtc that points to the transaction with the TXO they want Stackers to spend. The contract-call contains
   • the Merkle proof linking the transaction to the Bitcoin chain
   • the index into the TXOs that the user is challenging
   • the tapleaf scripts and other metadata that correspond to the TXO's taproot address
   • the OP_DROP payload
2. Every Bitcoin block, the Stacks node does the following:
   1. Queries the .sbtc contract for the list of pending challenges
   2. Checks the following. If any of these criteria are false, then the challenge is ignored
      • The TXO is a taproot scriptPubKey
      • The TXO has never been consolidated before
      • The TXO's BTC amount is higher than the minimum peg-in
      • The tapleaf scripts, OP_DROP payload, and other metadata correspond to the taproot address' hash
   3. If the above checks pass, then the node marks the challenge as valid
3. The signers query the Stacks node once per Bitcoin block for the list of validated challenges, and proceed to consolidate them (just as they would has they obtained this information from the reveal service)

---

All the while, at each Bitcoin block, the stacks node will clear out any validated pending challenges whose TXOs either get consolidated, or for which stackers submit a "no-quorum" Stacks transaction or a "no" Stacks transaction. Any of the above outcomes clears the validated pending challenge. PoX payouts continue as long as no validated pending challenge remains unanswered for more than XXX Bitcoin blocks.