SIP: Nakamoto sBTC #156
SIP: Nakamoto sBTC #156
Conversation
sips/sip-025/sip-025-sbtc.md
Outdated
| This SIP proposes that the total amount of sBTC accepted into this system is | ||
| capped by a limit in the `.sbtc` contract. The `.sbtc` contract will refuse to | ||
| admit a peg-in if it would exceed this limit. This limit can be increased (but | ||
| not decreased) by Stacker vote, and it would start at a default value of 100 BTC. |
There was a problem hiding this comment.
What's the process to change this limit by stacker vote?
There was a problem hiding this comment.
Any further context on the 100 BTC limit? As in why not 1000 or 10000 or 10?
There was a problem hiding this comment.
It's up to the implementation of .sbtc. This SIP does not call for a specific means.
100 BTC is just over 1% of 70% of the TVL in PoX as of today. We could safely bump it to about 7,500 BTC before the wallet would become worth more than 70% of the locked STX. I'm open to alternatives and compelling arguments; my rationale for a small number is to give us some time to see how well it behaves on mainnet without incurring too much risk up front. I'm not really worried about 70% of the stackers stealing the BTC; I'm worried about someone finding and exploiting a bug that lets them clean out the sBTC peg wallet without needing the stackers' permission.
sips/sip-025/sip-025-sbtc.md
Outdated
| ## Withdraw | ||
|
|
||
| Withdrawing is the act of redeeming sBTC for BTC (Figure 2). | ||
| To redeem sBTC for BTC, the user first sends a Stacks trnsaction to `.sbtc` |
There was a problem hiding this comment.
The current Alpha Romeo 0.1 developer release has implemented the withdrawal as a btc transaction. I suggest to add the btc withdrawal tx as a second option?
There was a problem hiding this comment.
Sure, this can be done.
sips/sip-025/sip-025-sbtc.md
Outdated
|
|
||
| SIP Number: 022 | ||
|
|
||
| Title: A Trustless 2-way Bitcoin Peg for Stacks |
There was a problem hiding this comment.
| Title: A Trustless 2-way Bitcoin Peg for Stacks | |
| Title: A Trust-minimized 2-way Bitcoin Peg for Stacks |
The term "trust-minimized" seems to be preferred for describing the trust model in a succinct way, as discussed here. If accepted, will need to update this term elsewhere in the SIP as well.
cc @muneeb-ali
| The user must send a minimal amount of BTC from their PoX reward address to one | ||
| of the following Bitcoin addresses: |
There was a problem hiding this comment.
Are the BTC sent to these addresses considered unspendable?
There was a problem hiding this comment.
Well, if they are spendable, you're more than welcome to claim them yourself ;)
There was a problem hiding this comment.
@jcnelson I will take that as a "yes"? The problem with these unspendable "burn addresses" is that they pollute the UTXO set with UTXOs that can never be spent, so they just bloat the UTXO set forever for no good reason. We have a better solution for burning BTC, it is by specifying an OP_RETURN output in a transaction and assigning an amount of BTC to be spent in this output. The BTC is then provably burnt but it does not bloat the UTXO set. (This is the difference between "the simple way" and "the meaningful way" defined here)
There was a problem hiding this comment.
@jcnelson is this part still relevant with the intent of putting the burned BTC from the prepare phase into the wallet's warchest?
|
|
||
| ## LBTC | ||
|
|
||
| This is a closed membership system. Over 50 members of Liquid Federation manage multi-sig |
There was a problem hiding this comment.
The Liquid multisig is an 11-of-15 multisig. Source
sips/sip-025/sip-025-sbtc.md
Outdated
| ## wBTC | ||
|
|
||
| This is a closed membership system. It is made up of | ||
| 50+ merchants and custodians with keys to the wBTC | ||
| multi-sig contract on Ethereum. End users purchase wBTC directly from | ||
| authorized merchants, and often the experience is fast. However, wBTC deposits and | ||
| withdrawals can only be performed by authorized merchants and custodians. |
There was a problem hiding this comment.
| ## wBTC | |
| This is a closed membership system. It is made up of | |
| 50+ merchants and custodians with keys to the wBTC | |
| multi-sig contract on Ethereum. End users purchase wBTC directly from | |
| authorized merchants, and often the experience is fast. However, wBTC deposits and | |
| withdrawals can only be performed by authorized merchants and custodians. | |
| ## WBTC | |
| This is a closed membership system. It is made up of | |
| 50+ merchants and custodians with keys to the WBTC | |
| multi-sig contract on Ethereum. End users purchase WBTC directly from | |
| authorized merchants, and often the experience is fast. However, WBTC deposits and | |
| withdrawals can only be performed by authorized merchants and custodians. |
It is stylized WBTC as seen on their website: https://wbtc.network/
Might be worth noting that although the merchants manage issuance and redemption, all BTC backing WBTC is held by a single company (BitGo).
| transactions have been fulfilled, and once the current set of Stackers possess | ||
| enough BTC to cover all outstanding sBTC tokens. | ||
|
|
||
| # Related Work |
There was a problem hiding this comment.
Should add a section about Nomic, which is the most similar related work imo.
sips/sip-025/sip-025-sbtc.md
Outdated
| ## LBTC | ||
|
|
||
| This is a closed membership system. Over 50 members of Liquid Federation manage multi-sig | ||
| contract. Only federation members can process withdraws. |
There was a problem hiding this comment.
| contract. Only federation members can process withdraws. | |
| contract. Only federation members can process withdrawals. |
typo fix
sips/sip-025/sip-025-sbtc.md
Outdated
|
|
||
| The deposit Bitcoin transaction contains the following data: | ||
|
|
||
| * An `OP_RETURN` data output, which contains the account address to which sBTC |
There was a problem hiding this comment.
Where should the specification for this go? Currently, the Alpha Romeo DR 0.1 has some specs: https://github.com/stacks-network/sbtc/blob/f4130c63ec5680921617ac4b910d72ffb4072eb5/sbtc-core/src/operations/op_return/deposit.rs#L4
There was a problem hiding this comment.
They'd go into an appendix
| BTC") and the BTC itself. At a high level, these systems seek to provide two | ||
| primitive operations: | ||
|
|
||
| * "Deposit": a BTC holder rids themselves of their BTC, and in doing so, |
There was a problem hiding this comment.
While I agree in the "deposit" & "withdraw" nomenclature, it'd be helpful to mention that the former can be thought of as "peg-in" & the latter as a "peg-out" in this definition section.
Especially since the term "peg" is used throughout.
There was a problem hiding this comment.
We're trying not to use the word "peg"
There was a problem hiding this comment.
We use the word "peg" in practice, so while it isn't technically the best word, its a practical word. I'm generally pro-practical.
| backed 1:1 by BTC sent to a wallet controlled by a large fraction of Stackers, | ||
| as measured by the fraction of locked STX they represent. Each time BTC is | ||
| sent to this wallet (a deposit operation), an equal number of sBTC are | ||
| automatically minted to an address of the sender's choosing. Stackers respond |
There was a problem hiding this comment.
More accurate to say "automatically inserted for processing" vs. "automatically minted"?
The current form makes it sound faultless & guaranteed.
There was a problem hiding this comment.
This paragraph is describing the happy path of the system
| Stackers can authorize the deposit, and only via a 70%+ majority vote. | ||
|
|
||
| Once stackers generate the authorization transaction, they make it available to | ||
| miners via their StackerDB instance, and require the current miner to include it |
There was a problem hiding this comment.
A bit unclear on what this means? Doesn't StackerDB only hold list tuples of signer slots?
sips/sip-025/sip-025-sbtc.md
Outdated
| * An `OP_RETURN` data output, which contains the account address to which sBTC | ||
| should be minted | ||
|
|
||
| * A payment to the sBTC sBTC wallet maintained by the current Stackers. This |
sips/sip-025/sip-025-sbtc.md
Outdated
| should be minted | ||
|
|
||
| * A payment to the sBTC sBTC wallet maintained by the current Stackers. This | ||
| payment UTXO is the hash of a script that has two spending fulfillment |
There was a problem hiding this comment.
Could we specific / link the exact formatting of this script? I believe I've seen some nice visuals around.
sips/sip-025/sip-025-sbtc.md
Outdated
| cycle has passed. | ||
|
|
||
| The payment must be above a `.sbtc`-defined threshold, in satoshis. This | ||
| _minimum deposit_ value is used to prevent users from spamming the system with |
There was a problem hiding this comment.
Was hoping you could tell me :) I was thinking the .sbtc contract would stipulate it via a Stacker mandate, but we'll want to pick an initial value.
sips/sip-025/sip-025-sbtc.md
Outdated
| The act of fulfilling a deposit with an affirmative vote is effectively a promise | ||
| made by Stackers to users to ensure that the sBTC minted wll remain fully backed | ||
| by the BTC the user submitted. This BTC may only be spent to fulfill withdraws, | ||
| or to process a wallet hand-off at the end of a reward cycle. Either way, the |
There was a problem hiding this comment.
Might it be worth defining reward cycle earlier as a tentative two-week period? If someone is reading without stacking/PoX experience it might not be clear how long a "reward cycle" is.
There was a problem hiding this comment.
It's all explained in SIP-007, which I think it's safe to assume the reader is familiar with at this point.
There was a problem hiding this comment.
Not sure if that is a safe assumption given not all of us understand it either, should add it to the glossary in the next PR. Making a note.
|
General question on depositing to a contract (from @friedger in the sBTC Builders call 17/10/23). Can the sbtc.clar contract, on receiving a deposit to a contract principal, and assuming the contract implements a trait that defines a callback, then sbtc.clar provides calls the contract and passing on the parameters of the deposit? |
|
General question on triggering withdrawals on layer 2 (the sBTC Builders call 17/10/23). - see https://github.com/stacks-network/sbtc/pull/253 Could a contract initiate a withdrawal on a users behalf? Say in response to an off chain data point changing via some oracle? |
|
It might be desirable to require that a user can only perform N successful withdraw requests if they perform N deposits. Then, at least they've paid for the transaction fees up front. |
|
|
||
| ## Glossary | ||
|
|
||
| | Term | Definition | |
There was a problem hiding this comment.
Add Reward cycle with a link to SIP-007 as requested in #156 (comment)
| redemption transaction would be marked as cancelled, and the user's sBTC | ||
| unlocks. The user will need to try the request again. | ||
|
|
||
| ### Transfer Fees |
There was a problem hiding this comment.
I chose the word peg for a lot of this section for lack of a better word, though I understand that we want to avoid that term. comment link
- Why
- Can someone suggest better wording?
| BTC") and the BTC itself. At a high level, these systems seek to provide two | ||
| primitive operations: | ||
|
|
||
| * "Deposit": a BTC holder rids themselves of their BTC, and in doing so, |
There was a problem hiding this comment.
We use the word "peg" in practice, so while it isn't technically the best word, its a practical word. I'm generally pro-practical.
| This proposal only describes Normal mode, and leaves Recovery mode to be described | ||
| in a future SIP. | ||
|
|
||
| This proposal, if ratified, would be executed by at least two hard forks: one |
There was a problem hiding this comment.
Add a specification Maintenance mode to encompass the need for manual recovery and is addressed later in the document with the details in https://github.com/stacks-network/sbtc/discussions/346 as mitigation strategies.
Maintenance mode is the temporary placeholder for Recovery mode prior to implementation.
| The following sections describe the Normal mode of operation. Recovery mode is | ||
| left for future work, but is summarized in a separate section after Normal mode. | ||
|
|
||
| ## Deposit |
There was a problem hiding this comment.
@FriendsFerdinand I wrote this section with a mostly complete understanding of OP_DROP but am missing some details. Please suggest adjustments when you can.
I've based this section on these discussions:
| or to process a DKG wallet hand-off. Either way, the user's BTC will be spent by | ||
| Stackers before they can reclaim it via the spending fulfillment script. | ||
|
|
||
| ***TODO: https://github.com/stacks-network/sbtc/issues/349: Create Deposit Procedure Diagram*** |
There was a problem hiding this comment.
@FriendsFerdinand can you address this ticket?
| 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 in the `.sbtc` data space (the height at which this Bitcoin transaction was included, not at which it was verified in the Clarity contract) | ||
|
|
||
| #### `.sbtc` Contract Function |
There was a problem hiding this comment.
Do we need these details in the SIP?
| the following mitigation strategies. | ||
|
|
||
| 1. During the prepare phase, the traditionally burned bitcoin will instead be placed into the peg wallet. See [SIP-001][SIP-001-LINK] | ||
| 2. The protocol will maintain a warchest that can receive donations and be siphoned from if the wallet budget for transfer fees runs dry. |
There was a problem hiding this comment.
This should be altered to make it clear that the "warchest" is just a concept that maps to "the amount of BTC in the peg wallet that's not accounted for in the sBTC system"
There was a problem hiding this comment.
How about a term that doesn't have "war" connotations? Like "treasury" or "surplus" or something like that.
|
|
||
| ## Capital Limits | ||
|
|
||
| **No capital limit will be imposed on the system.** Instead, the protocol will rely |
There was a problem hiding this comment.
@andreserrano This will likely stay the same through future iterations, so please make any alterations.
|
|
||
| Stackers set the required satoshis/vbyte transaction fee rate in the `.sbtc` | ||
| contract data space, so users can discover it at any time. Stackers update this | ||
| fee rate via a collectively-signed contract-call transactionto `.sbtc`, which |
| The Stackers write the aggregate public key and BTC redeem script | ||
| through an on-chain vote. The new Stackers submit their votes as zero-fee Stacks | ||
| transactions, which they share with existing Stackers so they can compel miners | ||
| include them in blocks (and should this fail for any reason, Stackers can also send |
This SIP supersedes the old SIP-021. It describes the sBTC system as implemented on top of Nakamoto v1.