sBTC Design - Implementation of Commit Reveal

[AshtonStephens]

This is a research discussion post meant to be edited with research notes surrounding commit reveal.

This research is about how it should be implemented and various considerations surrounding how it would be implemented and what it might look like.

[AshtonStephens]

Currently under investigation by @FriendsFerdinand

[FriendsFerdinand]

The next comment could be added to the SIP in the Two-Phase Deposit section

[FriendsFerdinand]

Commit-Reveal deposit

Users may not be able to send a Bitcoin transction with an OP_RETURN output. For example, this is difficult to do or is unsupported in some Bitcoin wallets, especially custodial wallets. In this case, the user can send a Bitcoin to a slightly modified Bitcoin address that contains the account address to which sBTC should be minted. Because this data and its presence would be indistinguishable from any other P2TR output, it is necessary to reveal its presence to the Stackers. It is revealed through a Stacks contract call that verifies the existence of such an ouput and its validity.

The procedure would go like this:

1. User sends Bitcoin to the generated address with the following script spending paths:

Path A: The sbtc payload is embedded in the script that sends the Bitcoin to the signer's pubkey

<sbtc_payload> DROP <signers_pubkey> CHECKSIG

Path B: The Refund path (same as the other Deposit method)

<block-height> CHECKLOCKTIMEVERIFY DROP <user_pubkey> CHECKSIG

2. Data needed to verify the commitment in the transaction

(submit-commitment(
  (burn-height uint)
  (tx (buff 4096))
  (header (buff 80))
  (tx-index uint)
  (tree-depth uint)
  (txproof (list 14 (buff 32)))
  (signers-pubkey (buff 33))
  (principal-buff (buff 151))
  (refund-pubkey (buff 33))
  (version (buff 1))
  (output-index uint)
)

Parameters for verifying a transaction	Description
burn-height	Block height in which the Bitcoin transaction is included
tx	Raw Bitcoin transaction data
header	Bitcoin block header of the commitment Bitcoin transaction
tx-index	Index at which the Bitcoin transaction is found in a Bitcoin block
tree-depth	Depth of the merkle tree where the Bitcoin transaction is included
txproof	Merkle proof of inclusion of the Bitcoin transaction
output-index	Index of the output that is being verified for a commitment

sBTC-related data	Description
principal-buff	Address to which the sBTC is to be minted in buffer format
signers-pubkey	Public key of the signers in compressed format
refund-pubkey	Public key to be used in the refund path (x-only)
version	Version of the script
output-index	Index of the output that is being verified for a commitment

This contract call performs the following:

1. Verifies that the Bitcoin transaction is included in the bitcoin block of burn-height height
2. Verifies the inclusion of the 2 script paths tap leaves in the output (the root is generated from the 2 tap leaves)
3. Records the existence of the Transaction ID, the amount sent and the time at which it was committed (the height at which this Bitcoin transaction was included, not at which it was verified in the Clarity contract)

sbtc payload format

< magic bytes | opcode | data >

The magic bytes are

X2 for Stacks mainnet
T2 for Stacks testnet

Opcode: <

Recipient address: Either a standard or a contract principal encoded as a Clarity value as defined in SIP-005. In the implementation, the contract length has a maximum length of 40 bytes.

Conditions

1. Only transactions with outputs above a certain amount can be accepted (stackers vote on the treshold amount)

[radicleart]

Should (refund-pubkey (buff 33)) be (refund-pubkey (buff 32)) if the refund pub key is x-only?

[radicleart]

Amazing work !

Does condition 2 imply there can't be a change output in the commit transaction ?

[FriendsFerdinand]

Should (refund-pubkey (buff 33)) be (refund-pubkey (buff 32)) if the refund pub key is x-only?
We need the compressed format because we're going to convert it into its point representation (to get the Y we need the parity bit) to perform the necessary arithmetic.

Does condition 2 imply there can't be a change output in the commit transaction ?

There can be as many output as needed, but my original idea was that we could only use 1 deposit output.

Though, now that I think about it, we'll have to be able to claim multiple deposit outputs from 1 transaction. I'l have to come up with a solution.

[FriendsFerdinand]

Add to the specifications that:

1. Stackers will not be searching the Bitcoin UTXO set for Commit-Reveal deposits.
2. Stackers will only be aware of a Commit-Reveal deposit after its existence is confirmed through a Stacks contract call in the .sbtc contract. Anyone is free to perform this verification contract call, the stackers nor the user are obligated to make this contract call.
3. Stackers will authorize (or not) the use of a UTXO for a deposit transaction only after it has been already included to the list of UTXOs in the .sbtc contract like any other OP_RETURN deposit request.

[radicleart]

General question: the bitcoin sits in the commit transaction output either until it gets spent by the signers during peg wallet handover or until its reclaimed ? Ie the signers don't need to spend it to the current peg wallet ?

[FriendsFerdinand]

Correct, there is only 1 Bitcoin commit transaction. The signers don't need to spend it to the current peg wallet for it to be minted into sBTC. It just sits in the commit transaction.