SIP-027: non sequential multisig transactions

[jbencin]

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.

[AcrossfireX]

@jbencin - can you comment on how this relates to stacks-network/stacks-core#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.

[jbencin]

@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

[fess-v]

I will close the previous SIP PR so we can move all discussions to this one instead @jbencin @AcrossfireX

[MarvinJanssen]

I welcome this SIP as it will make multisig much easier to use on Stacks. Excited to see more work in this direction. Some initial comments.

[AcrossfireX]

This SIP should be considered Accepted from the SIP Editors and should progress to technical CAB review. (Likely already underway)

[jbencin]

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

[obycode]

The latest updates look good to me.

[radicleart]

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 ?

[radicleart]

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.

[diwakergupta]

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?

[obycode]

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.

[obycode]

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.

[Hero-Gamer]

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.

[Hero-Gamer]

Hi @fess-v this SIP will be assigned to: SIP-027
Please can you update the text and content accordingly?

[obycode]

The vote results need to be posted to this SIP, then it should be merged.

[Hero-Gamer]

The vote results need to be posted to this SIP, then it should be merged.

Brice I got all the stats for you!

Activation Status
At the end of cycle 90, the following vote was calculated. A total of 118,632,231 STX participated.

• For solo stacking, 100% voted 'Yes.' Total voting power is 3,449,000 STX balance with votes cast from 1 account.

• For pool stacking, 100% voted 'Yes.' Total voting power is 114,914,556 STX balance with votes cast from 75 accounts.

• For non-stackers, 99.9933% voted 'Yes.' Total voting power of ‘Yes’ is 268,674 STX balance with votes cast from 157 accounts. 
For non-stackers, 0.0067% voted ’No.’ Total voting power of ‘No’ is 17 STX balance from 3 account.
  268,691.89

All voting criteria from STX holders have been met. A breakdown of the transactions can be found here.
A copy of the scripts used to tabulate the solo and pool stacking can be found here.

Script will be uploaded to SIP-027 folder by Jeff, once it's there URL will be available for text here.

[Hero-Gamer]

cc: @jbencin

[obycode]

LGTM

[jcnelson]

It is truly a pleasure to merge this in <3

[jcnelson]

Hi reviewers,

Can you please approve and merge #191 instead? It contains some fixes to this SIP, which I can't push directly since this PR comes from @jbencin's account.

Thanks!

[jcnelson]

Only requesting changes to that the superseding PR #191 can be reviewed and merged. It contains the same commit history as this; I merely took the liberty of resolving my own comments on top of this.

Please review the above PR instead so we can get this merged in 🎉