SIP-028: sBTC Signer Criteria #186
Conversation
|
Hi Please update the activation criteria to include the voting address as below. Activation Process of ActivationUsers 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. 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 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. |
|
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:
My suggestion would be to change to:
Historically that's what we've done. E.g. in SIP-015 (Stacks 2.1 Upgrade)
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%! |
|
How does this sip go with #156 ? |
|
I few nuances to clarify for the public will be great.
2. Number of Signer set
3. Signers voting structure.
|
Updated activation criteria, clarified number of signer set, added detail to the signer voting structure, and cleaned up the language.
Thanks, @Hero-Gamer I have incorporated all of these suggestions into the SIP. |
|
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: 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? If this sip is meant to supersede #156 - can you explain what the differences are, and if that PR is meant to be closed? |
|
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? |
@wileyj what is the correct SIP number for this?
There are only 200 words in the abstract
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. |
|
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?) |
Renaming to SIP-026
Thanks Jude. I will work on updating the SIP with the latest round of feedback. |
| - **Deposit redeem:** The sBTC Signers redeem the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO. | ||
| - **Mint:** The sBTC Signers finalize the deposit acceptance making a Clarity contract call that mints the sBTC on the Stacks Layer. |
There was a problem hiding this comment.
| - **Deposit redeem:** The sBTC Signers redeem the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO. | |
| - **Mint:** The sBTC Signers finalize the deposit acceptance making a Clarity contract call that mints the sBTC on the Stacks Layer. | |
| - **Deposit redeem:** The sBTC Signers redeem the deposit by consuming the deposit UTXO, consolidating it into the sBTC UTXO. | |
| - **Mint:** The sBTC Signers finalize the deposit acceptance making a Clarity contract call that mints the sBTC on the Stacks Layer. |
fix indentation
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
|
||
| For this SIP to pass, 66% of all liquid STX committed by voting must be in favor of the proposal. This precedent was set by [SIP-015](https://github.com/stacksgov/sips/blob/main/sips/sip-015/sip-015-network-upgrade.md). | ||
|
|
||
| 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. |
There was a problem hiding this comment.
"The act of not voting is the act of siding with the outcome" - @wileyj had issue with this wording on previous sip, might wanna check with him on this.
There was a problem hiding this comment.
correct - it's not relevant, and the assumption is incorrect regardless.
I don't like the wording or the implication, but it's not a blocker to moving to a vote.
|
|
||
| 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, with least 66% (48 million) voting "yes". |
There was a problem hiding this comment.
This SIP seems important enough to get high consensus of 80%.
66% required for Stacked STX we have not done before.
So perhaps think about using below to match other SIPs.
- 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."
And update non-Stackers vote power % to 80% to match.
|
|
||
|
|
||
| ### Updating The sBTC Signer Set | ||
| In the event that the sBTC Signer Set needs to be updated (for example, if a signer is no longer available to complete their responsibilities) sBTC Signers can perform a threshold vote to agree on the updated set. This process will also be performed if a signer needs to rotate their cryptographic keys. |
There was a problem hiding this comment.
is the threshold same as the threshold for approving pegging transactions? if yes best to state?
As it does not necessarily have to be the same.
| - Does the proposed sBTC signer commit to a direct communication channel to be set up with the sBTC core engineers in order to respond to urgent updates within 24 hours? | ||
| - Has the signer made contributions to Bitcoin or the Stacks network over the past year that demonstrate their commitment to the growth and success of the network? Examples include, but are not limited to: publishing independent research, marketing, co-authoring a SIP, submitting a Stacks pull request/issue, providing feedback on Stacks core development, or contributing to a Stacks Working Group. | ||
|
|
||
| The criteria described above will be used to identify sBTC Signers that are able to meet some or all of the responsibilities described in the previous section. |
There was a problem hiding this comment.
Should the list of signers be shown in the SIP-028?
Is feedback on the signer set for rest of stacks community? stacks-network/sbtc#624
As people may miss the opportunity to feedback if it's not on social or this SIP text
OR be in a file in the same folder as the SIP?
There was a problem hiding this comment.
that was a debated item here - it's up to the SIP authors becasue this SIP only defines how those initial signers may be chosen, it's not about who they are specifically.
| - Does the proposed sBTC signer agree to use reasonable efforts to maintain >99% uptime on the sBTC Signer? | ||
| * Note: This metric may be self-affirmed if independent verification is not possible, or confirmed by on-chain voting/stacking activity. | ||
| - Does the proposed sBTC signer commit to a direct communication channel to be set up with the sBTC core engineers in order to respond to urgent updates within 24 hours? | ||
| - Has the signer made contributions to Bitcoin or the Stacks network over the past year that demonstrate their commitment to the growth and success of the network? Examples include, but are not limited to: publishing independent research, marketing, co-authoring a SIP, submitting a Stacks pull request/issue, providing feedback on Stacks core development, or contributing to a Stacks Working Group. |
There was a problem hiding this comment.
I'm sure this has already been considered, but it might be worth explicitly stating 'geographical distribution' as a criterion for the overall set of signers criteria/consideration. Without this, it's possible that each of the 15 signers could meet individual eligibility criteria, but the entire group could still be U.S.-based, which could pose a jurisdictional risk. If I put my adversarial hat on..
|
|
||
| ## Specification | ||
|
|
||
| Management of the sBTC peg wallet on the Bitcoin blockchain shall be managed by the proposed set of signers through a democratic process, involving the sBTC Signer Set rather than a single custodian. At launch, the sBTC protocol will be maintained by 15 independent entities that make up the sBTC Signer Set and each unique signer is allocated exactly one vote. The system requires at least 70%, or 11 out of 15 signatures, for an sBTC operation to be fulfilled. The eligibility criteria to become an sBTC Signer are determined through the community governance process of ratifying this SIP. For this release, sBTC will not be part of Stacks consensus. |
There was a problem hiding this comment.
So just to confirm, if I take it to the extreme:
if 2 signers' STX power are huge, say holding than 70% number of STX in the signer set of 15, it would still require 11 individual signer votes for the transaction to approve?
There was a problem hiding this comment.
i don't think the sbtc signers will be voting based on any "STX power", since that would be a different signer binary they run (or not. i think the eligibility is that they do run one, but it's not relevant for sbtc signer set voting)
| | Term | Definition | | ||
| |---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ||
| | **SIP-10 Token** | A token on the Stacks blockchain that adheres to the fungible token standards outlined in [SIP-10](https://github.com/stacksgov/sips/blob/main/sips/sip-010/sip-010-fungible-token-standard.md). | | ||
| | **sBTC** | A SIP-10 token on the Stacks Blockchain that can be turned back into BTC on the Bitcoin Blockchain. 1 sBTC is equivalent to 1 BTC on the Bitcoin Blockchain. | |
There was a problem hiding this comment.
"Bitcoin blockchain" (lower b) used elsewhere in the doc, pick one or the other for consistency
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.