stacksgov
SIP-027: non sequential multisig transactions
While implementing Stacks multisig in the Ledger app (Zondax/ledger-stacks#152), I found the current multisig format confusing and hard to work with. Other developers that have tried to work with multisig seem feel the same way (example: PR #139), and as far as I know there is currently no Stacks wallet with full multisig support. So wrote up this SIP which makes slight modifications to SIP-005 to add a new multisig transaction type which is a bit simpler and allows participants to sign in any order.
@jbencin - can you comment on how this relates to https://github.com/stacks-network/stacks-blockchain/pull/3710 and its associated SIP draft? Is it possible to fold these into one shared SIP effort? Let me know if it makes more sense for them to remain seperate.
@AcrossfireX That PR is now implementing this draft SIP. I know there is another draft SIP mentioning order-independent multisig (#139), but that one lacks implementation details
I will close the previous SIP PR so we can move all discussions to this one instead @jbencin @AcrossfireX
This SIP should be considered Accepted from the SIP Editors and should progress to technical CAB review. (Likely already underway)
One more small thing I want to add here...
Even though the signing order is independent, the order of the public keys in the auth fields still determines how the address is generated. For backwards compatibility and to enable previously generated multisig accounts to use order-independent signing, I don't think we should mandate public key order, but I think we should recommend a public key ordering of least to greatest (which is equivalent to lexicographical sorting of hex-encoded values) to remove the guesswork when creating a transaction
@jcnelson - would we be able to get this in front of the Steering Committee for final approval and merge as the activation points to it being ready for epoch 3.0? It has been approved by the SIP editors and Technical CAB and seems ready for final discussions by the Steering Comittee.
Also would you prefer that the editors assign a formal SIP number to this as it has not yet been chosen. It appears that SIP-026 would be available.
@jcnelson I copied all the text from SIP-005's "Transaction Encoding" section and merged it with this SIP. This can now be viewed as a complete replacement for that section
Hi - i think the activation criteria for this SIP requires a community vote ?
If so the activation criteria sections needs to be updated to reflect this? For example, see Nakamoto activation criteria
@AcrossfireX can you please confirm this is the case ?
Hi Please update the activation criteria to include the community vote. Something like the following will be great.
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: 399iMhKN9fjpPJLYHzieZA1PfHsFxijyVY
-
Bitcoin No Address: 31ssu69FmpxS6bAxjNrX1DfApD8RekK7kp
-
Stacks Yes Address: SPA17ZSXKXS4D8FC51H1KWQDFS31NM29SKZRTCF8
-
Stacks No Address: SP39DK8BWFM2SA0E3F6NA72104EYG9XB8NXZ91NBE
which encode the hashes of the following phrases into bitcoin / stacks addresses:
Yes to Non-sequential Multisig Transactions No to Non-sequential Multisig Transactions
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.
Hi - i think the activation criteria for this SIP requires a community vote ?
If so the activation criteria sections needs to be updated to reflect this? For example, see Nakamoto activation criteria
@AcrossfireX can you please confirm this is the case ?
Why does this SIP require a community vote? Community votes is a very heavy mechanism (in terms of time, effort, communications etc) and should be used sparingly IMO. Is there clear guidance on which SIPs warrant a full-blown community vote?
Why does this SIP require a community vote?
This has been a discussion amongst the CABs, SIP editors, etc. and the current consensus is that anything that is consensus changing should require a community vote. One goal will be to make the voting process simpler so that it's not such a big deal.
Also, noting that the SIP doesn't have to be consensus breaking to require a community vote -- some SIPs might want a community vote even if not consensus changing -- but if it is consensus changing, then that triggers a vote requirement.
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:
-
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. If you want to be more conservative, make it 50 million given it's a less advertised SIP vs Nakamoto/sBTC.
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.
FYI Historically it has been:
- For this to pass 66% of all liquid STX committed by voting must in favour of the proposal.
If wanna be safe, lower to 66%. I think it's fine to higher the bar to 70% based on looking at the typical % rate in favor over the past few votes. If you want to be more ambitious you can adjust it to 80%.
To be safe as it is a less marketed SIP, would recommend choosing 66% as per SIP-015.
Hi @fess-v this SIP will be assigned to: SIP-027 Please can you update the text and content accordingly?