Feedback for Mini sBTC

Community
#1

Stacks 2.1 is coming in March. This is happening at an inflection point regarding how the world sees Stacks, which is happening at the same time that many are learning about our community and even joining it. With the Nakamoto release and Subnets coming, it is a great time to be a Stacker.

With that said, we need the Stacks community to learn about a new innovative output of sBTC, the highly anticipated trustless, two-way Bitcoin peg that makes it possible to have native Bitcoin in Clarity smart contracts.

Jude Nelson of the Stacks Foundation has created a 12 page document summarizing what he called “Mini sBTC,” which could be implemented as soon as Stacks 2.1 is live in March, from a technical standpoint.

In summary, the current sBTC SIP proposes changes that are consensus-breaking to ensure miners and stackers are aligned with the safety and liveness of the peg as well as the blockchain. With this said, clever engineering efforts from the world-class talent in the Stacks ecosystem can deploy a “mini sBTC” without breaking consensus rules and get early feedback on the sBTC design!

This document outlines the design and potential work breakdown of this “mini sBTC” that implements sBTC incentives to test them before a SIP-021 hard fork. Click here to access and read it.

Stackers, we need your feedback on mini sBTC as soon as possible. We are looking for feedback to be voiced here by Friday, February 24th, 2023. Share this with a fellow Stacker you know, read the document from Jude Nelson, and share your thoughts! This is our time to make Stacks the best place to build on Bitcoin, and between sBTC and Stacks 2.1, we can truly change everything.

Lastly, for all things sBTC, be sure to sign up for the weekly newsletter by Andre Serrano!

WAGMI

4 Likes
#2

Thank you for sharing! Excited to see a lightweight solution to allow builders to start planning!

I do have questions.

  1. Could you explain further a Delegate’s responsibilities in the decentralized stacking pool? Is this similar to the delegated stacker’s operations in standard pool operations? Additionally, in this decentralized pool, is the STX ever in direct custody of the delegate?
  2. Who would be considered an ‘honest actor’ for monitoring the state of the peg? Would this imply an open federation?
  3. I think I read there could be multiple systems for sBTC. How would that work from an implementation perspective for prospective partners?
  4. Lastly, how is the system impacted if Stackers choose not to be signers?

Much appreciated,
Rena

1 Like
#3

Thanks Jude & core devs for the innovation!
Just a quick question, does the capped vs uncapped affect this design? i.e. does this mini sBTC design have collateralization consideration as per Making sBTC ready for DeFi prime time discussion? Or is it not in this version and will come later?

1 Like
#4

Hi Rena,

Yes, it’s very similar. Stackers volunteer to maintain a peg by delegating their STX to the .sbtc contract, which then takes care of stacking their STX. The key difference is that instead of there being a designated pool operator, the .sbtc contract will stack STX based on the state of Bitcoin transactions relayed to it through a Clarity Bitcoin library. Specifically, the act of relaying Bitcoin transactions to the .sbtc contract updates the .sbtc contract’s view of Bitcoin so it can take appropriate actions. Anyone can relay these transactions, so in effect the community itself is the pool operator.

The delegation happens through the usual PoX delegation logic. The Stacker’s STX never leave their wallet.

The .sbtc contract would allow anyone to submit a Bitcoin transaction and Merkle proof to it in order to prove that a certain peg operation has happened. As long as there’s at least one honest person somewhere who can do this, then .sbtc’s state will reflect all of the Bitcoin peg transactions. In practice, I expect the Stackers and sBTC users to do this. Ecosystem entities could also set up dedicated services for this, which anyone could run.

In the SIP-021 sBTC design doc, the blockchain miners are required to keep the .sbtc contract up-to-date with peg transactions. But doing this would be a hard fork, so we instead must assume that there exists at least one honest person somewhere who will do this.

This does not imply a federation. Anyone can join as a Stacker, and anyone can relay Bitcoin transactions to .sbtc.

The mini sBTC proposal describes a way to build a 2-way peg using a “vanilla” .sbtc contract. By that, I mean there’s nothing special about .sbtc here – it’s just another smart contract. There can be more than one; Stackers choose which one they want to delegate their STX to.

In practice, prospective partners would evaluate the existing .sbtc contracts and choose the one they want to work with. I expect that, given the strength of network effects, there will be a small number of dominant .sbtc contracts (perhaps as few as one), and a smattering of smaller ones used for experimenting with new ways for dealing with the peg. But, that’s the whole point of this – mini sBTC gives partners, developers, and users a way to quickly iterate and test .sbtc implementations so that if we all find one we like, we can tailor SIP-021 to its needs.

The .sbtc contract(s)’ peg wallets would be backed with fewer STX. In practice, wallets that support mini sBTC would inform users in advance of how much STX is committed to maintain the peg, and would warn them if it significantly drops to the point where it’s dangerous to put BTC in.

2 Likes
#5

Because mini sBTC smart contracts are just vanilla smart contracts, you could deploy two of them – one with a cap, and one without. Let the market decide which one it wants :wink:

This could be one outcome of mini sBTC – if we see a large market for an uncapped peg, and also a large market for a capped peg, then SIP-021 would need to accommodate multiple .sbtc contract implementations at once in order to maximize the system’s usefulness.

3 Likes
#6

This is a very good proposal and would allow the ecosystem to move significantly faster.

When it comes to the ‘go to market implementation’ of mini sBTC, I would suggest to strive for one canonical version of mini sBTC with as much Stacked STX directed to it (as opposed to multiple versions). Most builders would expect the ecosystem to set one standard that is sound, rather than having different options to choose from. Having one standard also makes it easier to bring new builders into the ecosystem.

The usefulness of the mini sBTC canonical version will be determined by 1) the amount of stacked STX directed to it and 2) the (non-)restrictiveness of the peg in rules, as we discussed in the Making sBTC ready for DeFi prime time discussion

1 Like
#7

As a library user, I can decode the first N inputs’ witness scripts, as long as they are each less than W items long (for some library constants N and W).

This requires also verification of the coinbase tx

#8

Peg in/peg out sOrdinals :pinched_fingers:t2:

1 Like
#9

I just want to remind folks that mini sBTC is NOT a product. It’s a development tactic we’re employing to deliver a testable artifact as soon as possible. If someone wanted to take the testable artifact and turn it into a different product, that’s totally fine (and encouraged!), but it’s not something that’s on the sBTC developers’ roadmap at this time.

That said,

The “go to market implementation” is essentially going to be “here’s the code, here’s a version of it we’re using on testnet, and here’s how to get some testnet sBTC so you can build your sBTC apps.”

We can’t stop someone else from making their own version of it, nor would we try to. It may very well be that someone else can come up with better ideas than the one we’d operate, and if so, we’d want to incorporate them sooner rather than later. For example, it may very well be that some users prefer a collateralized peg; we find out by empowering folks to go try it out for themselves.

If multiple mini sBTC instances arise this way, then I think that (1) this is a great “problem” to have and (2) we should curate a list of popular instances. But we’ll address this when (or if) it happens.

EDIT:

The go-to-market strategy for the final SIP-021 sBTC system is obviously going to be very different. There will definitely be a canonical sBTC contract that we’d pitch to Stackers, and we’d strive to incorporate all of their feedback (since they’re on the hook for running it).

Mini sBTC is a way to get early feedback on what that canonical sBTC contract will need to do. Instead of trying to hash it all out in Github comments like we did for Stacks 2.1, we can actually put ideas to the test before committing to them in a hard fork. For example, it may very well be that there’s enough demand for pegging ordinals in and out of Stacks that the final SIP-021 system might require Stackers to run ordinal wallets (or barring that, we leave the door open in the design to add it later without needing a separate hard fork). Mini sBTC makes it possible to test this hypothesis.

1 Like
#10

Yup, it will. The code would need to verify three merkle proofs – one for the transaction’s inclusion, one for the coinbase’s inclusion, and one for its witness data inclusion. The verified coinbase transaction can be cached once calculated, since it’s the same for each Bitcoin transaction in that block.

1 Like
#11

Thanks for those comments! This makes a lot of sense. The GTM group led by @andre.btc can take forward and figure out what can best be done on mainnet once a testnet version of mini-sBTC is out :sparkles:

Exciting work guys!

3 Likes
#12

@jude What most stood out to me was this note about handling peg-in requests when peg-out requests are still pending:

“ Stackers simply will refuse to consume the user’s peg-in BTC UTXO”

Could the same approach be used in non-mini-sBTC so that if users send a peg-in request when the collateralization ratio is below the threshold it isn’t processed?

My concern is that the collat ratio limit is ineffective in practice if people can still send their native BTC but just not get their sBTC minted yet. It doesn’t really achieve the collat ratio goal, since it doesn’t prevent the economic risk getting worse, which is a function of native BTC sent to the wallet, not the minted supply of sBTC.

#13

Yes @MattySTX! :sunglasses: This is a great idea that can be combined with other tactics, such as:

I’ve added your idea to the sBTC Project plan for scoping and implementation!

#14

If Stackers are in a position at all to prevent a peg-in from completing, then the spending script that the user commits to when they send the first transaction would have a timeout clause – either the Stackers complete the peg-in within a given number of Bitcoin blocks, or the user can spend the BTC.

This has other benefits besides preserving a collateralization ratio. Namely, if the user sends to the wrong peg wallet address by accident (e.g they copied a bad address, the address expires due to a concurrent peg hand-off at a reward cycle boundary), then they don’t risk losing their BTC.

4 Likes