Multisignature transaction signing order independence

[fess-v]

Hey everyone!

We are developing a multisig solution named Asigna (Asigna.io), and we have encountered an important issue. Following the weekly SIP call discussion, we created this SIP to expedite the process. We have attached two GitHub issues for stacks.js (https://github.com/hirosystems/stacks.js/issues/1487) and stacks blockchain (https://github.com/stacks-network/stacks-blockchain/issues/2622). This issue has been labeled as "in the icebox," and we would like to bring it to the attention of the Stacks development team.

Please note that the first commit only contains a draft proposal to initiate discussions and will be updated with more technical information later.

The initial discussion was initiated by the following post on the Stacks forum (https://forum.stacks.org/t/implementing-a-fully-functioning-multisig-wallet-on-stacks/14889).

The issue is in the next_verification method from the MultisigSpendingCondition struct and the verify method for message signatures. Verify goes subsequently over the initial public key array, therefore checks their signatures subsequently, while the next_verification method checks the next signature by wrapping the previous signature into a new hash, which makes it tied to the previous signer. In my opinion, the solution is to untie this relation and make each sign only the original transaction by each signer and check their signatures accordingly. The same thing should be implemented in the javascript Stacks.js library for signature construction. It is also possible to change the order in which signatures are being checked and still wrap the previous signature with a new hash, but I just want to ask if it's really required.

Thanks everyone!

[AcrossfireX]

SIP Editor Update 5/25: RICE Details: Reach - 200,000, Impact - 2/5, Confidence - 100%, Effort - 0.5 person-months. Final RICE Score: 800,000

Status: Additional feedback is required from stakeholders in community. Will begin engaging conversations on various mediums for more feedback.

[AcrossfireX]

Full details on this SIP can be seen in detail on the SIP impact assessment sheet where RICE scoring was conducted and tracked. Additional comments also available here: https://docs.google.com/spreadsheets/d/1DsdUkZ99c6m7U57m7RnzSd0nni3vGdMIT80k-_zQUb0/edit?usp=sharing

Was discussed in detail on recent SIP editor call and additional community feedback on PR is required. Reference Links: https://github.com/stacks-network/stacks-blockchain/pull/3710 https://forum.stacks.org/t/implementing-a-fully-functioning-multisig-wallet-on-stacks/14889 https://github.com/hirosystems/stacks.js/issues/1487 https://github.com/stacks-network/stacks-blockchain/issues/2622

[markmhendrickson]

I just want to voice my support here for this SIP since we at Hiro Wallet would like to help power Asigna's multi-sig efforts and deliver on a highly usable experience that doesn't run into the current ordering constraint.

[janniks]

Big +1 for this SIP, a feature we'll definitely need if the Stacks ecosystem is to grow and larger groups think about multisigging sBTC (even if something similar would work via contracts, an out-of-the-bow solution is always better!)

[jbencin]

I just finished a draft SIP (#152) related to this suggesting how an order-independent multisig transaction could be implemented in stacks-node

[fess-v]

Closed, SIP moved to a new PR