Multisignature transaction signing order independence #139
Conversation
…gnature-transaction-signing-order-independence
|
|
||
| SIP Number: 02X | ||
|
|
||
| Title: Multisignature transaction signing order independence |
There was a problem hiding this comment.
recommend using consistent terminology Multisignature -> Multisig / Multi-Signature (multisig)
| License: CC0-1.0 | ||
|
|
||
| Sign-off: - | ||
|
|
There was a problem hiding this comment.
it would be good to add the relevant Layer field affected by this proposal. Please refer to https://github.com/stacksgov/sips/blob/main/sips/sip-000/sip-000-stacks-improvement-proposal-process.md
recommend adding Discussions-To field with link to forum discussion for relevant topic
| Multisig transactions require multiple private keys to sign off on a transaction before it can be executed on the Stacks network. For example, a Stacks wallet may require the use of two out of three private keys to authorize a transaction. This means that multiple parties involved in the transaction must agree to the terms of the transaction and sign off on it before the funds can be transferred. Multisig transactions offer an additional layer of security and control over Stacks transactions, making them an essential tool for anyone looking to safeguard their funds. | ||
|
|
||
| For these transactions to be genuinely flexible and useful for common users, DAOs, dApps, and Stacks ecosystem projects, it is essential for signatures to be order-independent. Current restrictions on signature orders impede the emergence of multisignature solutions. Implementing this feature will result in an easier user experience and increased security when using Multisig wallets within the Stacks ecosystem. This will provide a user-friendly approach for multiple parties to cooperate in a secure environment to participate in Staking STX, Treasury Management for DAOs, and interact with dApps. |
There was a problem hiding this comment.
please reformat text so that each line does not exceed 100 character limit
|
|
||
| # Backwards Compatibility | ||
|
|
||
| Fully compatible with the previous strict signature order logic |
There was a problem hiding this comment.
please add missing sections : "Introduction", "Specification", "Related Work", "Activation", and "Reference Implementations"
These sections are essential for a comprehensive SIP as they provide more in-depth understanding of the problem, technical specifications, comparisons with other existing solutions, conditions for activating the SIP, and any reference implementations.
|
SIP Editor Update 5/25: Status: Additional feedback is required from stakeholders in community. Will begin engaging conversations on various mediums for more feedback. |
|
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: Was discussed in detail on recent SIP editor call and additional community feedback on PR is required. |
|
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. |
|
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!) |
|
I just finished a draft SIP (#152) related to this suggesting how an order-independent multisig transaction could be implemented in |
|
Closed, SIP moved to a new PR |
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 (hirosystems/stacks.js#1487) and stacks blockchain (stacks-network/stacks-core#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!