tromp
July 19, 2025, 1:20pm
22
Yes, payment channels require 2-of-2 utxos, the simplest form of multi-sig. Other nodes cannot recognize these utxos, but will recognize the NRD kernels that can arise in channel closure.
3 Likes
Couldnât threshold Schnorr signing be used to expand the 2 of 2 to larger groups?
this is the way.. now if we could pop the kernel..
Vlad:
that allows wallets to
I saw on the news letter there is such a bounty for a messaging program. Why has this not been done yet?
k26dr
August 15, 2025, 12:30pm
26
Any reason not to just use MPC? It would allow multisig usage with no changes to the protocol.
Before I can start implementing multisig in the core wallet I need some more details.
*what exact flavour of multisig is required m (M-of-N threshold, 2-of-2, aggregate Schnorr, shared outputs, etc?
*Which flows need to support it (output creation, spending, message signing, proof-of-reserves)?
*How should users coordinate-interactive rounds like existing Slatepacks, or some new API?
*Do we need on-disk storage or shared keys or co-signer service?
*How should the Cli/api commands and wallet configuration expose it?
Once those requirements are defined, I can map out necessary changes and start implementing.
2 Likes
For 1 Iâm guessing we want M-of-N threshold so itâs similar to how you guys use btc multisig? (4-of-7?)
For question #2 , I guess the required supported flows would be output creation, spending, and message signing ( or maybe just spending? )
For Q #3 imma thinking of just going with slatepack rather then tryna implement a new api method
For Q #4 I guess weâll go with on-disk storage of shared keys, seems that most secure.
And for # 5 I guess we would need a new command added to the cli to expose the multisig ability, something like ./grin-wallet multisig
If anyone has any suggestions nows the time
1 Like
This is a work in progress, still need to make it cryptographically secure and a bunch of other things. This is an EXTREMELY rough draft.
Introducing âgrin-wallet multisigâ CLI command with subcommands âinitâ , âstatusâ , âsessionsâ and âapproveâ.
grin-wallet multisig init!!!
I fricking did it boyeees! You are welcome!
master â syntaxjak:feature/multisig
opened 10:06PM - 03 Nov 25 UTC
Extremely rough draft!
### 0. Usual wallet prep
Create/open the wallet⌠as normal (e.g. grin-wallet init, grin-wallet open), set your password, sync, etc.
### 1. Configure the local multi-signature policy (one time)
grin-wallet multisig init -t 2 \
-H alice \
-H bob \
-H carol
* This example sets a 2-of-3 policy with holders âaliceâ, âbobâ, âcarolâ.
* The command prints storage files (JSON) for each holder; distribute them securely. Inside each file is the âapproval tokenâ theyâll use with
`grin-wallet multisig approve`.
### 2. Produce or obtain the transaction Slatepack
When the wallet needs to sign/spend, youâll have a pending Slate:
* If youâre the sender: `grin-wallet send ... --file pending.slatepack` (or receive & save the Slatepack from the counterparty).
* If receiving an invoice, you might run `grin-wallet finalize` to get a Slatepack.
That pending Slatepack is what drives the FROST workflow.
### 3. Initialize the FROST session for that Slate
grin-wallet multisig frost-init \
--input pending.slatepack \
--session-out session.json
* `pending.slatepack` is the Slatepack file from step 2.
(If you omit `--input`, the command will prompt you to paste the Slatepack.)
* The CLI writes `session.json`, which includes the verifying key, labels, and current signing state summary.
### 4. Ask each holder for a roundâ1 commitment
Each holder uses a FROST implementation (or tooling) to parse session.json, pick their label, and generate their signing commitment. They return a payload
(hex/base64/json) for the coordinator.
Record each incoming commitment:
grin-wallet multisig frost-commitment \
--slate-id <UUID-from-session> \
--label alice \
--file alice_commitment.json
Repeat for every participant. You can check progress anytime:
grin-wallet multisig frost-session --slate-id <UUID> --outfile current_state.json
This prints (or saves) which labels have commitments/signature shares and which are still missing.
### 5. Build the signing package for roundâ2
After the threshold number of commitments has been recorded:
grin-wallet multisig frost-signing-package \
--input pending.slatepack \
--outfile signing_package.json
That file contains the message hash plus all recorded commitments. Share it with the holders so they can compute their signature shares.
### 6. Record roundâ2 signature shares
As holders send back their signature share:
grin-wallet multisig frost-signature \
--slate-id <UUID> \
--label alice \
--file alice_signature.json
Once the threshold shares are stored, grin-wallet multisig frost-session will show no âmissing signaturesâ.
### 7. Finalize (and post) the transaction
With the commitments & signatures logged, run the normal finalize path (the wallet will aggregate the shares automatically because the FROST session is
attached to the Slate):
grin-wallet finalize \
--input pending.slatepack \
--outfile finalized.slatepack
If desired, post it immediately:
grin-wallet finalize --input pending.slatepack --fluff
(or grin-wallet post on the finalized Slatepack).
------------------------------------------------------------------------------------------------------------------------------------------------------------
---
#### Quick reference of the new multisig subcommands
grin-wallet multisig frost-init # start a FROST session from a pending Slatepack
grin-wallet multisig frost-session # inspect session + stored commitments/signatures
grin-wallet multisig frost-signing-package
grin-wallet multisig frost-commitment # record round-1 commitment
grin-wallet multisig frost-signature # record round-2 signature share
grin-wallet multisig approve # (existing) record human approvals/tokens
grin-wallet multisig sessions/status # view multi-sig state
Each of these accepts --input path or --slatepack "..." where appropriate; if neither is given, the CLI will prompt/paste interactively.
The only remaining manual pieces are: (1) holders still need a tool/script to generate the actual FROST commitments/signatures from the session JSON (we
assume theyâre running a FROST implementation), and (2) orchestration is still coordinator-driven, though the CLI now streamlines the record-keeping a lot.
testing:
./target/debug/grin-wallet multisig ââhelp
Warning: Extremely experimental software, use at your own risk, the creator of this software will not be held responsible for any loses you may incur!
Attempting to add cryptographic security thanks to the advice from @NicolasFlamel
Gonna go frost style as @Anynomous mentioned in the OP
Phase 2 complete!
4 Likes
