MuSig - Revision history

NotATether: Add Key aggregation section and expand signing and wallet notes from BIP327

2026-09-13T07:38:54Z

Add Key aggregation section and expand signing and wallet notes from BIP327

← Older revision		Revision as of 07:38, 13 September 2026
Line 2:		Line 2:

	Script-based n-of-n multisignature reveals the number of keys and needs one signature per key. Schnorr linearity lets keys be aggregated so one joint signature covers the set. The original MuSig scheme (often called MuSig1) needed three communication rounds. MuSig2, published by Jonas Nick, Tim Ruffing, and collaborators, reduces signing to two rounds. BIP327 standardizes encodings, nonce generation, BIP32 and Taproot tweaks, and partial-signature checks so independent wallets can cosign the same Taproot key-path spend.		Script-based n-of-n multisignature reveals the number of keys and needs one signature per key. Schnorr linearity lets keys be aggregated so one joint signature covers the set. The original MuSig scheme (often called MuSig1) needed three communication rounds. MuSig2, published by Jonas Nick, Tim Ruffing, and collaborators, reduces signing to two rounds. BIP327 standardizes encodings, nonce generation, BIP32 and Taproot tweaks, and partial-signature checks so independent wallets can cosign the same Taproot key-path spend.

			== Key aggregation ==

			BIP327 defines a deterministic KeyAgg algorithm over an ordered list of plain or x-only public keys. Coefficients bind each key into the aggregate so that a rogue-key attack cannot substitute an adversary-controlled aggregate. Optional BIP32 derivation and BIP341 Taproot tweaks are applied in the order the BIP specifies. The aggregate public key is what wallets put in a <code>tr()</code> descriptor or compare against a PSBT output.

			Because aggregation is n-of-n, removing or reordering a participant changes the aggregate key. Backup and recovery procedures must store the full participant list and tweak schedule, not only one extended private key.

	== Signing rounds ==		== Signing rounds ==

	Each signer contributes a fresh public nonce, then a partial signature. Partial signatures combine into one 64-byte BIP340 signature. Reusing a secret nonce across sessions can leak the key. An optional untrusted aggregator can collect nonces and partials to cut communication cost. It may abort but cannot forge a valid aggregate signature alone.		Each signer contributes a fresh public nonce, then a partial signature. Partial signatures combine into one 64-byte BIP340 signature that verifies under [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] rules for the aggregate key. Reusing a secret nonce across sessions can leak the key. An optional untrusted aggregator can collect nonces and partials to cut communication cost. It may abort but cannot forge a valid aggregate signature alone.

	Session transcripts must bind the aggregate key, the message, and each participant's nonce so a partial signature cannot be replayed in another session.		Session transcripts must bind the aggregate key, the message, and each participant's nonce so a partial signature cannot be replayed in another session. Signers should verify every peer nonce and every partial signature against the BIP327 equations before releasing their own second-round share.

	== Wallet notes ==		== Wallet notes ==
Line 15:		Line 21:
	Hardware signers that implement BIP327 need the key aggregation coefficients and Taproot tweak in the PSBT or an equivalent secure channel. Mismatched participant lists produce a different aggregate key and an on-chain script that nobody can satisfy together. Test vectors in BIP327 are the usual interoperability check between libraries. Wallets should refuse to sign if the claimed aggregate key does not equal the MuSig2 key aggregation of the advertised participant keys and tweaks.		Hardware signers that implement BIP327 need the key aggregation coefficients and Taproot tweak in the PSBT or an equivalent secure channel. Mismatched participant lists produce a different aggregate key and an on-chain script that nobody can satisfy together. Test vectors in BIP327 are the usual interoperability check between libraries. Wallets should refuse to sign if the claimed aggregate key does not equal the MuSig2 key aggregation of the advertised participant keys and tweaks.

			On-chain, a MuSig2 key-path spend is indistinguishable from any other BIP340 Taproot key-path spend. Script-path alternatives remain available if the Taproot tree commits to fallback policies.

	== See also ==		== See also ==
Line 21:		Line 28:
	* [[FROST]]		* [[FROST]]
	* [[Lightning Network]]		* [[Lightning Network]]
			* [[PSBT]]
			* [[Descriptor wallet]]

	== External links ==		== External links ==
	* [https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki BIP327: MuSig2 for BIP340-compatible multi-signatures]		* [https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki BIP327: MuSig2 for BIP340-compatible multi-signatures]
			* [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340: Schnorr signatures for secp256k1]
			* [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341: Taproot]
	* [https://eprint.iacr.org/2020/1261.pdf MuSig2 paper (IACR ePrint 2020/1261)]		* [https://eprint.iacr.org/2020/1261.pdf MuSig2 paper (IACR ePrint 2020/1261)]
	* [https://eprint.iacr.org/2018/068.pdf MuSig paper (IACR ePrint 2018/068)]		* [https://eprint.iacr.org/2018/068.pdf MuSig paper (IACR ePrint 2018/068)]
	* [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340: Schnorr signatures for secp256k1]

	[[Category:Technical]]		[[Category:Technical]]

NotATether: Expand Wallet notes on aggregate key checks

2026-09-13T07:35:50Z

Expand Wallet notes on aggregate key checks

← Older revision		Revision as of 07:35, 13 September 2026
Line 13:		Line 13:
	Wallets that cosign a MuSig2 Taproot key must agree on key aggregation order, tweaks, and nonce handling before signing begins. BIP327 defines the algorithms and encodings so independently written implementations can produce matching aggregate keys and compatible partial signatures. Lightning and other multiparty protocols may prefer MuSig2 key aggregation where every participant is expected to be online for n-of-n authorization, while threshold custody more often looks to [[FROST]].		Wallets that cosign a MuSig2 Taproot key must agree on key aggregation order, tweaks, and nonce handling before signing begins. BIP327 defines the algorithms and encodings so independently written implementations can produce matching aggregate keys and compatible partial signatures. Lightning and other multiparty protocols may prefer MuSig2 key aggregation where every participant is expected to be online for n-of-n authorization, while threshold custody more often looks to [[FROST]].

	Hardware signers that implement BIP327 need the key aggregation coefficients and Taproot tweak in the PSBT or an equivalent secure channel. Mismatched participant lists produce a different aggregate key and an on-chain script that nobody can satisfy together.		Hardware signers that implement BIP327 need the key aggregation coefficients and Taproot tweak in the PSBT or an equivalent secure channel. Mismatched participant lists produce a different aggregate key and an on-chain script that nobody can satisfy together. Test vectors in BIP327 are the usual interoperability check between libraries. Wallets should refuse to sign if the claimed aggregate key does not equal the MuSig2 key aggregation of the advertised participant keys and tweaks.

NotATether: Add Signing rounds and Wallet notes sections

2026-09-13T07:32:55Z

Add Signing rounds and Wallet notes sections

← Older revision		Revision as of 07:32, 13 September 2026
Line 2:		Line 2:

	Script-based n-of-n multisignature reveals the number of keys and needs one signature per key. Schnorr linearity lets keys be aggregated so one joint signature covers the set. The original MuSig scheme (often called MuSig1) needed three communication rounds. MuSig2, published by Jonas Nick, Tim Ruffing, and collaborators, reduces signing to two rounds. BIP327 standardizes encodings, nonce generation, BIP32 and Taproot tweaks, and partial-signature checks so independent wallets can cosign the same Taproot key-path spend.		Script-based n-of-n multisignature reveals the number of keys and needs one signature per key. Schnorr linearity lets keys be aggregated so one joint signature covers the set. The original MuSig scheme (often called MuSig1) needed three communication rounds. MuSig2, published by Jonas Nick, Tim Ruffing, and collaborators, reduces signing to two rounds. BIP327 standardizes encodings, nonce generation, BIP32 and Taproot tweaks, and partial-signature checks so independent wallets can cosign the same Taproot key-path spend.

			== Signing rounds ==

	Each signer contributes a fresh public nonce, then a partial signature. Partial signatures combine into one 64-byte BIP340 signature. Reusing a secret nonce across sessions can leak the key. An optional untrusted aggregator can collect nonces and partials to cut communication cost. It may abort but cannot forge a valid aggregate signature alone.		Each signer contributes a fresh public nonce, then a partial signature. Partial signatures combine into one 64-byte BIP340 signature. Reusing a secret nonce across sessions can leak the key. An optional untrusted aggregator can collect nonces and partials to cut communication cost. It may abort but cannot forge a valid aggregate signature alone.

			Session transcripts must bind the aggregate key, the message, and each participant's nonce so a partial signature cannot be replayed in another session.

			== Wallet notes ==

	Wallets that cosign a MuSig2 Taproot key must agree on key aggregation order, tweaks, and nonce handling before signing begins. BIP327 defines the algorithms and encodings so independently written implementations can produce matching aggregate keys and compatible partial signatures. Lightning and other multiparty protocols may prefer MuSig2 key aggregation where every participant is expected to be online for n-of-n authorization, while threshold custody more often looks to [[FROST]].		Wallets that cosign a MuSig2 Taproot key must agree on key aggregation order, tweaks, and nonce handling before signing begins. BIP327 defines the algorithms and encodings so independently written implementations can produce matching aggregate keys and compatible partial signatures. Lightning and other multiparty protocols may prefer MuSig2 key aggregation where every participant is expected to be online for n-of-n authorization, while threshold custody more often looks to [[FROST]].

			Hardware signers that implement BIP327 need the key aggregation coefficients and Taproot tweak in the PSBT or an equivalent secure channel. Mismatched participant lists produce a different aggregate key and an on-chain script that nobody can satisfy together.


	== See also ==		== See also ==

NotATether: Expand See also links

2026-09-12T21:11:32Z

Expand See also links

← Older revision		Revision as of 21:11, 12 September 2026
Line 10:		Line 10:
	* [[Taproot]]		* [[Taproot]]
	* [[Multi-signature]]		* [[Multi-signature]]
			* [[FROST]]
	* [[Lightning Network]]		* [[Lightning Network]]

NotATether: Add wallet interoperability and Lightning contrast

2026-09-12T21:11:29Z

Add wallet interoperability and Lightning contrast

← Older revision		Revision as of 21:11, 12 September 2026
Line 4:		Line 4:

	Each signer contributes a fresh public nonce, then a partial signature. Partial signatures combine into one 64-byte BIP340 signature. Reusing a secret nonce across sessions can leak the key. An optional untrusted aggregator can collect nonces and partials to cut communication cost. It may abort but cannot forge a valid aggregate signature alone.		Each signer contributes a fresh public nonce, then a partial signature. Partial signatures combine into one 64-byte BIP340 signature. Reusing a secret nonce across sessions can leak the key. An optional untrusted aggregator can collect nonces and partials to cut communication cost. It may abort but cannot forge a valid aggregate signature alone.

			Wallets that cosign a MuSig2 Taproot key must agree on key aggregation order, tweaks, and nonce handling before signing begins. BIP327 defines the algorithms and encodings so independently written implementations can produce matching aggregate keys and compatible partial signatures. Lightning and other multiparty protocols may prefer MuSig2 key aggregation where every participant is expected to be online for n-of-n authorization, while threshold custody more often looks to [[FROST]].

	== See also ==		== See also ==

NotATether: MuSig stub — MuSig2 / BIP327 n-of-n Schnorr aggregate

2026-09-09T10:22:28Z

MuSig stub — MuSig2 / BIP327 n-of-n Schnorr aggregate

New page

'''MuSig''' is a family of interactive multi-signature protocols that aggregate several public keys into one and produce a single BIP340 Schnorr-compatible signature for that aggregate. On Bitcoin the result can look like an ordinary single-key [[Taproot]] key-path spend. The Bitcoin-relevant construction is '''MuSig2''', standardized in [https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki BIP327]. It is an n-of-n scheme: every listed key must participate. Threshold k-of-n signing is a different design family (for example FROST), not MuSig2.

Script-based n-of-n multisignature reveals the number of keys and needs one signature per key. Schnorr linearity lets keys be aggregated so one joint signature covers the set. The original MuSig scheme (often called MuSig1) needed three communication rounds. MuSig2, published by Jonas Nick, Tim Ruffing, and collaborators, reduces signing to two rounds. BIP327 standardizes encodings, nonce generation, BIP32 and Taproot tweaks, and partial-signature checks so independent wallets can cosign the same Taproot key-path spend.

Each signer contributes a fresh public nonce, then a partial signature. Partial signatures combine into one 64-byte BIP340 signature. Reusing a secret nonce across sessions can leak the key. An optional untrusted aggregator can collect nonces and partials to cut communication cost. It may abort but cannot forge a valid aggregate signature alone.

== See also ==
* [[Taproot]]
* [[Multi-signature]]
* [[Lightning Network]]

== External links ==
* [https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki BIP327: MuSig2 for BIP340-compatible multi-signatures]
* [https://eprint.iacr.org/2020/1261.pdf MuSig2 paper (IACR ePrint 2020/1261)]
* [https://eprint.iacr.org/2018/068.pdf MuSig paper (IACR ePrint 2018/068)]
* [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340: Schnorr signatures for secp256k1]

[[Category:Technical]]