BIP327 MuSig2는 여러 참여자의 공개키를 aggregate public key 하나로 만들고 두 communication rounds를 거쳐 BIP340과 호환되는 단일 Schnorr signature를 생성하는 n-of-n 방식입니다. Taproot key path에서 쓰면 chain에는 일반 단일 signer P2TR과 같은 공개키·서명 형태가 보입니다. 전통 script multisig는 여러 공개키와 개별 서명을 redeemScript·witness script 또는 tapscript에 공개하므로 크기와 정책 노출이 더 크지만 threshold 조건을 script에서 직접 표현할 수 있습니다.
집계 키 하나가 여러 signer를 대표합니다
MuSig2 KeyAgg는 참여자 public keys에 계수를 적용해 rogue-key 공격을 막는 aggregate point를 계산합니다. BIP327 v1.0.4는 BIP340 public key·signature와 호환되고 Taproot tweak도 지원합니다. Key 순서 정책을 합의하지 않으면 참여자들이 서로 다른 aggregate key를 만들 수 있어 canonical list를 고정해야 합니다.
이 output을 P2TR key path로 쓰면 observer는 여러 signer가 협력했는지 알기 어렵습니다. P2SH multisig처럼 m, n과 각 public key가 지출 때 공개되지 않습니다. 프라이버시와 비용 이점 대신 조직은 signer 구성·승인 증거를 별도 audit log에 남겨야 합니다.
MuSig2는 여러 서명을 숨겨 주는 script가 아니라, 여러 signer가 하나의 정상 Schnorr 서명을 함께 만드는 protocol입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 집계 키 하나가 여러 signer를 대표합니다
MuSig2 KeyAgg는 참여자 public keys에 계수를 적용해 rogue-key 공격을 막는 aggregate point를 계산합니다.
- 서명은 nonce와 부분 서명의 두 라운드입니다
일반 flow에서 각 signer는 secret nonce를 만들고 public nonce를 교환합니다.
- Nonce는 한 번만 사용하고 즉시 폐기합니다
같은 secret nonce를 다른 message나 aggregate context에 재사용하면 두 partial signature 관계에서 secret key가 드러날 수 있습니다 .
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
서명은 nonce와 부분 서명의 두 라운드입니다
일반 flow에서 각 signer는 secret nonce를 만들고 public nonce를 교환합니다. 모든 public nonces를 aggregate한 뒤 message, aggregate key, tweaks와 결합한 session context로 partial signature를 생성합니다. Aggregator는 partial signatures를 검증·합쳐 최종 BIP340 signature를 만듭니다.
BIP327은 third-party aggregator가 통신 복잡도를 줄일 수 있지만 악성 aggregator가 세션을 실패시킬 수 있다고 설명합니다. Individual nonce를 숨기거나 바꾸면 partial verification 능력도 달라집니다. Availability를 신뢰와 혼동하지 않고 timeout·재시도·blame 기록을 설계합니다.
| 항목 | MuSig2 key path | Script multisig |
|---|---|---|
| 온체인 key | aggregate key 하나 | 여러 key 공개 가능 |
| 서명 형태 | BIP340 하나 | 개별 signatures |
| 기본 정책 | n-of-n | m-of-n 표현 가능 |
| 상호작용 | nonce·partial sig 라운드 | PSBT 서명 수집 |
| 주요 위험 | nonce·session state | script·key order 오류 |
Nonce는 한 번만 사용하고 즉시 폐기합니다
같은 secret nonce를 다른 message나 aggregate context에 재사용하면 두 partial signature 관계에서 secret key가 드러날 수 있습니다. Crash 뒤 세션 상태를 잘못 복원해 nonce를 재사용하는 것도 같은 위험입니다. 서명 장치는 nonce를 message·aggregate key·session id에 바인딩하고 사용 후 지워야 합니다.
BIP327은 deterministic and stateless signing도 별도 입력과 다른 signer aggregate nonce를 사용해 정의하지만 임의로 단순 deterministic nonce를 만들라는 뜻이 아닙니다. 구현은 공식 test vectors와 상태 전이 검사를 통과하고 partial signature 전송 전에 화면에서 최종 transaction을 확인해야 합니다.
- 참여 public key 목록과 순서를 합의합니다.
- aggregate key와 Taproot tweak를 독립 계산합니다.
- 세션마다 새 secret nonce를 생성합니다.
- 모든 signer가 같은 message를 확인합니다.
- partial signature를 검증한 뒤 최종 signature를 조립합니다.
전통 멀티시그는 정책을 명시적으로 보여 줍니다
Legacy P2SH 2-of-3은 redeemScript에 threshold와 세 public keys를 넣고 지출 때 여러 ECDSA signatures를 제공합니다. Tapscript는 OP_CHECKSIGADD로 threshold policy를 표현합니다. 사용 leaf가 공개되면 조건을 observer도 읽을 수 있지만 한 signer offline 상황을 허용하는 m-of-n 정책을 직접 구성할 수 있습니다.
MuSig2 기본 n-of-n에서는 signer 한 명이 응답하지 않으면 key path 서명을 완성하지 못합니다. Backup script path에 delayed recovery key를 넣을 수 있지만 사용 시 정책 일부가 공개되고 더 큰 witness fee가 듭니다. 운영 요구를 먼저 정하고 chain footprint만 보고 선택하지 않습니다.
PSBT와 signer 구현 버전을 맞춥니다
BIP373은 MuSig2 participants, public nonces, partial signatures를 PSBT에 담는 field를 정의합니다. 기존 PSBT signer가 이 필드를 모르면 round state를 보존하지 못합니다. Wallet·hardware signer·coordinator가 지원하는 BIP327 version과 tweak convention을 배포 전에 확인합니다.
최종 검증은 aggregate signature가 실제 unsigned transaction의 sighash에 대해 BIP340 verify되는지 확인하는 것입니다. Coordinator 성공 응답만 기록하지 말고 PSBT input, aggregate key, session transcript hash, final txid를 연결합니다. 테스트 중 secret nonce나 private key를 log에 남기지 않습니다.
자주 묻는 질문
MuSig2는 항상 2-of-3 같은 threshold를 지원하나요?
BIP327 MuSig2는 n-of-n입니다. Threshold는 별도 protocol이나 script path 정책이 필요합니다.
집계 키는 signer끼리 통신해야 만들 수 있나요?
키 집계는 비대화형이지만 실제 signing은 nonce와 partial signature 라운드가 필요합니다.
Aggregator가 자금을 훔칠 수 있나요?
정상 protocol에서 서명을 위조할 수는 없지만 세션을 방해할 수 있습니다. Signer는 message와 context를 독립 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
