SIP-028: sBTC Signer Criteria

[andrerserrano]

Signer Criteria for sBTC, A Decentralized and Programmable Asset Backed 1:1 with BTC

Abstract

This SIP takes the position that Stacks can play a key role in offering a rich programming environment for Bitcoin with low-latency transactions. This would be achieved with a new wrapped Bitcoin asset, called sBTC, which would be implemented on Stacks 3.0 and later as a SIP-010 token. Stacks today offers a smart contract runtime for Stacks-hosted assets, and the forthcoming Stacks 3.0 release provides lower transaction latency than Bitcoin for Stacks transactions. By providing a robust BTC-wrapping mechanism based on threshold signatures, users would be able to lock their real BTC on the Bitcoin chain, instantiate an equal amount of sBTC tokens on Stacks, use these sBTC tokens on Stacks, and eventually redeem them for real BTC at 1:1 parity, minus the cost of the relevant blockchain transaction fees.

This is the first of several SIPs that describe such a system. This SIP describes the threshold signature mechanism and solicits from the ecosystem both a list of signers and the criteria for vetting them. These sBTC signers would be responsible for collectively holding all locked BTC and redeeming sBTC for BTC upon request. Given the high-stakes nature of their work, the authors of this SIP believe that such a wrapped asset can only be made to work in practice if the Stacks ecosystem members can reach broad consensus on how these signers are chosen. Thus, the first sBTC SIP put forth for activation concerns the selection of sBTC signers.

This SIP outlines but does not describe in technical detail the workings of the first sBTC system. A separate SIP will be written to do so if this SIP successfully activates.

[radicleart]

Hi Please update the activation criteria to include the voting address as below.

Activation
Since this SIP requires a change to the stacks consensus rules a community vote is additionally required.

Process of Activation

Users can vote to approve this SIP with either their locked/stacked STX or with unlocked/liquid STX, or both. The criteria for the stacker and non-stacker voting is as follows.

For Stackers:

In order for this SIP to activate, the following criteria must be met by the set of Stacked STX:

At least double the amount of Stacked STX locked by the largest Stacker in the cycle preceding the vote must vote at all to activate this SIP.
Of the Stacked STX that vote, at least 70% of them must vote "yes."
The voting addresses will be;

Bitcoin Yes Address: 3Jq9UT81fnT2t24XjNVY7wijpsSmNSivbK

Bitcoin No Address: 3QGZ1fDa97yZCXpAnXQd6JHF4CBC6bk1r4

Stacks Yes Address: SP36GHEPEZPGD53G2F29P5NEY884DXQR7TX90QE3T

Stacks No Address: SP3YAKFMGWSSATYNCKXKJHE2Z5JJ6DH88E4T8XJPK

which encode the hashes of the following phrases into bitcoin / stacks addresses:

Yes to A Decentralized Two-Way Bitcoin Peg
No to A Decentralized Two-Way Bitcoin Peg

Stackers (pool and solo) vote by sending a dust stacks to the corresponding stacks address from the account where their stacks are locked.

Solo stackers only, can also vote by sending a bitcoin dust transaction (6000 sats) to the corresponding bitcoin address.

For Non-Stackers:

Users with liquid STX can vote on proposals using the Ecosystem DAO. Liquid STX is the users balance, less any STX they have locked in PoX stacking protocol, at the block height at which the voting started (preventing the same STX from being transferred between accounts and used to effectively double vote). This is referred to generally as "snapshot" voting.

For this SIP to pass, 70% of all liquid STX committed by voting must be in favour of the proposal.

The act of not voting is the act of siding with the outcome, whatever it may be. We believe that these thresholds are sufficient to demonstrate interest from Stackers -- Stacks users who have a long-term interest in the Stacks blockchain's successful operation -- in performing this upgrade.

[Hero-Gamer]

If this sBTC V1 SIP were to go up for community vote.

I'd take a look at Multi-sig SIP's voting criteria comment for consistency #152 (comment)

Essentially my two suggestions below:

For Stackers:

In order for this SIP to activate, the following criteria must be met by the set of Stacked STX:

At least double the amount of Stacked STX locked by the largest Stacker in the cycle preceding the vote must vote at all to activate this SIP. Of the Stacked STX that vote, at least 70% of them must vote "yes."

My suggestion would be to change to:
In order for this SIP to activate, the following criteria must be met by the set of Stacked STX:

• At least 80 million Stacked STX must vote at all to activate this SIP.

• Of the Stacked STX that vote, at least 80% of them must vote "yes."

Historically that's what we've done. E.g. in SIP-015 (Stacks 2.1 Upgrade)

For Non-Stackers:

For this SIP to pass, 70% of all liquid STX committed by voting must be in favour of the proposal.

Commented in the multi-sig SIP, historically been 66% for context, but I actually think it's great to trial 70% threshold. Recommendation: keep 70%!

[friedger]

How does this sip go with #156 ?

[andrerserrano]

How does this sip go with #156 ?

#156 is now outdated. This SIP supersedes that issues.

[Hero-Gamer]

I few nuances to clarify for the public will be great.
1. Community governance process is voting on eligibility criteria

• sBTC Signers will be selected through an open community governance process - this wording indicates community governance process has some roles in selecting the sBTC Signers, but my understanding is the community vote is only voting on the "eligibility criteria" laid out in this SIP.
• sBTC Signers that meet the criteria are selected by a separate group of people (sBTC Working Group?).
• Therefore I'd personally phrase it as: eligibility criteria is confirmed through this community governance vote

2. Number of Signer set

• I'm not seeing the number of Signer set specified in this SIP. Could be 3, could be 15. Could be 30. I did hear on the call it is 15. So it would be good for the public information to know a range being targeted perhaps on the SIP itself, of if it's been decided it's going to be 15, just to allow people to get a sense what we are opting into/voting on.

3. Signers voting structure.

• For the pegging in and pegging out, more important for the pegging out part, what's the consensus mechanism, is it 1 signer 1 vote (if 15 signers, would need to reach 11 votes, is it 70/60/50% the quorum?), or is it via number of STX they held and reaching 70% of STX quorum consensus. From the SIP call my understanding is 1 signer 1 vote. Would be great to lay it out for the people using the V1 bridge understand the risk assessment.

[andrerserrano]

I few nuances to clarify for the public will be great. 1. Community governance process is voting on eligibility criteria

• sBTC Signers will be selected through an open community governance process - this wording indicates community governance process has some roles in selecting the sBTC Signers, but my understanding is the community vote is only voting on the "eligibility criteria" laid out in this SIP.
• sBTC Signers that meet the criteria are selected by a separate group of people (sBTC Working Group?).
• Therefore I'd personally phrase it as: eligibility criteria is confirmed through this community governance vote

2. Number of Signer set

• I'm not seeing the number of Signer set specified in this SIP. Could be 3, could be 15. Could be 30. I did hear on the call it is 15. So it would be good for the public information to know a range being targeted perhaps on the SIP itself, of if it's been decided it's going to be 15, just to allow people to get a sense what we are opting into/voting on.

3. Signers voting structure.

• For the pegging in and pegging out, more important for the pegging out part, what's the consensus mechanism, is it 1 signer 1 vote (if 15 signers, would need to reach 11 votes, is it 70/60/50% the quorum?), or is it via number of STX they held and reaching 70% of STX quorum consensus. From the SIP call my understanding is 1 signer 1 vote. Would be great to lay it out for the people using the V1 bridge understand the risk assessment.

Thanks, @Hero-Gamer I have incorporated all of these suggestions into the SIP.

[wileyj]

The formatting of this sip is off. I see a sip number referenced, but the PR is adding a single (text) file to the root of the repo. Please create a new file in the format, ex: ./sips/sip-025/sip-025-sbtc.md ref: https://github.com/stacksgov/sips/pull/156/files

Secondly - the sip number is already occupied by the emergency SIP process: https://github.com/stacksgov/sips/blob/main/sips/sip-022/sip-022-emergency-pox-fix.md

Third - the PR contains a lot of graphics and other data that isn't present in the file being PR'ed. is that by design?
ref: https://github.com/stacksgov/sips/pull/156/files for how to include graphics and other data in a proposed SIP (essentially, all additional data should be included in the sip folder i mentioned above).

If this sip is meant to supersede #156 - can you explain what the differences are, and if that PR is meant to be closed?
Alternatively, should the changes be PR'ed to the branch in #156 ?

[jiga]

hi @andrerserrano please see my comments below

Preamble: The preamble is missing several required fields such as 'Author', 'Created', 'License', 'Sign-off', 'Layer', 'Discussions-To', 'Comments-Summary', 'Comments-URI', 'License-Code', 'Post-History', 'Requires', 'Replaces', and 'Superseded-By'.

Abstract: The abstract exceeds the 5000-word limit.

Introduction: The introduction section is missing.

Specification: The specification section lacks detailed technical specifications, code snippets, payload formats and performance evaluations. Need more details on Deposit Accept step.

Related Work: This section is missing.

Backwards Compatibility: This section is missing.

Reference Implementations: This section is missing. Are there any issues/checkins to refer to?

[andrerserrano]

Secondly - the sip number is already occupied by the emergency SIP process: https://github.com/stacksgov/sips/blob/main/sips/sip-022/sip-022-emergency-pox-fix.md

@wileyj what is the correct SIP number for this?

Abstract: The abstract exceeds the 5000-word limit.

There are only 200 words in the abstract

Introduction: The introduction section is missing.

The introduction section is formatted similar to SIP 21 with a glossary and problem statement.

Going through the rest of the feedback now and will update accordingly. Thanks.

[jiga]

How does this sip go with #156 ?

#156 is now outdated. This SIP supersedes that issues.

does this SIP really supersedes #156 or does #156 requires this SIP as prerequisite ?

[jiga]

about Bootstrap Signer Eligibility

Communication & Availability: towards this, should Signers also have to be public entities ?

Ecosystem Alignment: How is this measured or ensured?

Are there any security requirements that must be followed by Signers (e.g. hardened deployments, following private key handling best practices? auditable?)

[jcnelson]

This process is to ensure that the sBTC Working Group can adjust to any changes in the sBTC Signer Set quickly and without the overhead of an additional community vote.

I think this may be a case of you "saying the quiet part out loud." I can understand the desire to avoid the time costs of a long-running vote, but surely there must be some means for community oversight of the signer set?

[jcnelson]

I think once you have an initial signing set, then you can have future SIPs for changing it. Unlike this SIP, I think there's room for SIPs that only change the signing set, which can have shorter voting windows and only require participation from sBTC holders (since they'd be the only stakeholders).

[jcnelson]

As part of the related work section, can you summarize the important ways by which sBTC differs? This helps the reader understand why sBTC is necessary -- what niche is it filling that these other systems do not fill, and cannot be trivially adapted to fill?

[jcnelson]

I think a missing but necessary activation criterion will be that the SIP authors put forth the list of signers, and their reasons why they have met the above criteria better than any other candidate (it would also be a good idea to list all of the candidates, even if they did not get selected).

[jcnelson]

If the sBTC working group can get together the above data, then at least the SC and user community will not be devolving their authority to advance and ratify SIPs (a strong point of contention I had earlier). The 15 signers would themselves be part of the SIP, as well as the rationale for including them over others. Then, the sBTC working group and its signer set can be held accountable by the user community as part of the activation process.

This also has the nice consequence of avoiding the need for the SC to independently vet the signer set according to the SIP's critiera, which would be very difficult to do as-written due to the ambiguity of the criteria. If there is any contention between the SC and user community with the sBTC working group over the signer set, then we can visit it before activation by way of simply re-considering the ultimate signer list instead of re-considering the means by which they were discovered and ranked.

[jcnelson]

Mostly nits at this point. Great job getting this together!

The only significant point of contention that makes this SIP very difficult to ratify is that this SIP still puts too much authority in the hands of the sBTC working group's ability to choose the signers. I can't support this as-is because it would mean that the sBTC working group -- a non-SIP-process body that is not accountable to SIP officers and the community they serve -- would end up with a lot of unrestrained power to decide what happens to peoples' BTC.

To avoid this, and to avoid the need to come up with (very complex) means of having the SC validate the signers themselves, I think the SIP authors should do the following prior to activation:

1. Obtain the list of signers from the sBTC working group, including the ones that were candidates but were not selected
2. Describe how each candidate met each criterion
3. If there were more than 15 candidates, describe why they were the best 15 candidates
4. Present this information as part of the Activation section, so the community can make its own decision on whether or not these signers are adequate (and whether or not the sBTC working group's rationale is good enough).

This not only holds the sBTC working group accountable, but also frees them from having to reproduce the vetting process with the SC (some of which can, understandably, be difficult).

Also, I think it needs to be explicitly stated that once this SIP activates, the signer set cannot be changed except through a subsequent SIP that supersedes this one. If we need to kick a signer out, or replace signers, then there needs to be an accountable process for doing so (EDIT: such as by having sBTC holders vote on new signing sets). SIPs like this don't need to take a long time to activate; all that's necessary for activation is that the relevant stakeholders have a means to accept or reject the decisions made by SIP officers and authors.

[jcnelson]

@andrerserrano @aldur I heard from @wileyj, who I understand spoke with you two, and we spoke about how to move this SIP forward. While I think all of the technical comments are readily addressable, it's currently my understanding that you are concerned about the speed at which you can choose a new signing set (should the need arise). And, that concern is the reason why this SIP proposes that the sBTC working group indefinitely retains the ability to unilaterally change signing sets with no community oversight -- something that I oppose on the strongest terms.

Community Oversight of the Signers

This SIP proposes a system that is intended to garner significant user and economic traction in the Stacks ecosystem. If ratified, there are three possible outcomes for sBTC:

1. sBTC drives substantial ecosystem growth -- both in terms of number of users and amount of BTC value locked in it
2. sBTC has little impact on ecosystem growth, but it does not slow or diminish it either
3. sBTC drives substantial ecosystem decline, such as by locking up and then losing a substantial amount of BTC

The first two outcomes are acceptable, and if I had to choose, I'd (obviously) chose the foremost. The third one, however, must be avoided at all costs.

What makes this SIP challenging in a way not faced by other SIPs like SIP-010 is that the integrity of sBTC relies on an honest signer set. Indeed, the success or failure of sBTC hinges on the behavior of its signers! It does not matter how perfect the sBTC code is if too many signers go offline or act maliciously -- we can hit outcome #3 solely through signer misbehavior.

As such, avoiding outcome #3 requires ensuring that the signer set is honest and online at all times, or as close to it as possible. This not only requires a means of choosing suitable candidates (a process described by this SIP), but also requires a means of identifying, adding, and removing the signers themselves as needed. Offline or malicious singers must be replaced with honest, online signers as quickly as possible to achieve an acceptable quality of service needed for outcome #1 above.

But, who decides which signer candidates are trustworthy? It can't be just the SIP authors -- we have no way of knowing who the ecosystem trusts, short of asking the ecosystem itself. But this SIP does not do this. Instead, it proposes delegating the decision-making of which signers are trustworthy to an unelected, unaccountable body that isn't even part of the SIP process.

Why should the ecosystem blindly and indefinitely trust the sBTC working group to decide who handles their BTC? Can't the ecosystem collectively decide this for itself?

Fast sBTC Signer Selection

The SIP process is a means for the ecosystem to decide for itself what services the Stacks blockchain should (and should not) provide for them. Since decision speed seems to be the driving concern for choosing sBTC signers, why not extend this SIP to provide a means for the ecosystem to decide the signing set after it it initially proposed? Then, the SIP's ratification would not only choose the initial signing set, but also provide an accountable means for rotating signers.

I can see a few ways to do this (this is non-exhaustive):

• sBTC signer smart contract. This SIP could propose a smart contract that contains a registry of all candidate signers, and provides a means for sBTC holders to rank them by trustworthiness. Every so often (e.g. once a reward cycle), the sBTC software inspects this smart contract to identify the 15 highest-ranked candidates to become the new signers in the next reward cycle. For example, a very simple ranking system could be that sBTC holders can vote to replace signer A with signer B, and if enough sBTC votes by the end of the reward cycle, then the new signer must replace the old signer in the next reward cycle. There doesn't have to be a programmatic way for the sBTC software to automatically eject the old signer and add the new signer (this can be a manual process); what matters is that the signer set reflects the wishes of the ecosystem.

• sBTC Consideration Advisory Board. This SIP could elevate the sBTC working group to a CAB, and specify a governance charter for them that not only requires CAB officers to stand for election by an ecosystem-wide vote, but also requires CAB officers to poll the ecosystem (such as via SIP-018 signed structured messages) every so often for their opinions on a signer set. This SIP would specify voting thresholds for CAB officer election and signer set activation. Importantly, signer set activation can be fast -- as fast as sBTC holders can clear the voting threshold. This would also pave the way for future SIPs that require the sBTC CAB's sign-off, which I think is something you're going to want anyway.

• Fast-Activating SIPs. Nothing about the SIP process has to be slow -- a SIP can be ratified as soon as it gets the right sign-offs. This SIP could describe a template for future SIPs that only change the sBTC signing set, and require a threshold of sBTC holder votes via SIP-018 signed structured messages. The difference between this and the above is that it doesn't require organizing the sBTC WG into a CAB.

I'm sure there are other ways to do this, but my point is that signer set agility is feasible today without delegating unilateral authority to the sBTC WG.