sBTC Signer Transaction: A single BTC transaction for deposit, withdrawal and handoff

[netrome]

Purpose

This discussion explores the possibility of having a single type of BTC transaction for sBTC which supports deposits, withdrawals and handoff.

Intro

Currently, the sBTC deposit and withdrawal flows both result in BTC transactions signed by the sBTC signers. The current formulation suggests that each "Deposit accept" or "Withdrawal accept" transaction is a separate Bitcoin transaction. This is great from a conceptual standpoint, but practically speaking it is unfeasible since this would severely limit the amount of sBTC operations Signers could perform per block due to Bitcoin's ancestor limit.

In addition to deposits and withdrawal, each set of signers will have to perform a handoff transaction every reward cycle to hand over custody of the sBTC UTXO to a new set of signers.

Proposal

This proposal defines the sBTC Signer Transaction. A single bitcoin transaction capable of accepting any number $N_d$ of deposits, any number $N_w$ of withdrawals and may hand over the sBTC UTXO to a new set of signers.

This transaction is accompanied by a new function call in the .sbtc contract called sbtc-batch-processed. This function is equivalent to separately calling deposit-accept, deposit-reject, withdrawal-accept and withdrawal-reject for all processed deposits and withdrawals separately. In addition, this function also acknowledges if this transaction hands over the sBTC UTXO to a new signer set.

sBTC Signer Transaction format

The envisioned format for the sBTC Signer Transaction is outlined below.

Inputs

• Input $1$: The previous sBTC UTXO.
• Input $2$ to $N_d+1$: Deposit UTXOs.
• Input $N_d+2$ and onward: Donations.
  • Allowing Signers to add extra balance to the sBTC wallet to cover missing fees.

Outputs

• Output $1$: An OP_RETURN output with the following data (layout in next section).
  • op: sBTC opcode. Proposal B.
  • N_d: Number of deposits.
  • signer_bitmap: Bitmap of signer votes, or empty if the number of signers exceeds the available memory in which case this information must be submitted through a smart contract call to the sbtc-batch-processed function in the .sbtc contract.
• Output $2$: New sBTC UTXO.
  • This UTXO should exceed or be equal to the total supply of sBTC after accounting for all deposits and withdrawals accepted in this transaction.
• Output $3$ to $N_w+2$: Withdrawal fulfillment UTXOs.

OP_RETURN data layout:

 0     2  3    5                           80
|------|--|----|---------------------------|
 magic  op  N_d       signer_bitmap 

Discussion topics

• Does the following transaction format contain all necessary features of the previous sBTC transactions.
• Do we foresee any risks with this approach?
• Do we need any other data embedded on Bitcoin?

[setzeus]

There are (currently) hard limits in the clarity-bitcoin contract that make it hard to parse/confirm more than 8 inputs & 8 outputs for a single transaction.

[netrome]

Hmm okay, then with the Bitcoin ancestor limit we'd be able to handle 8x25=200 deposits and 200 withdrawals per bitcoin block with this design. Which is better than not having any batching giving us the previous constraints of n_deposits + n_withdrawals + handoff <= 25 per block, but it's not impressive numbers.