BIP327 MuSig2는 여러 참여자의 공개키를 집계 공개키(aggregate public key) 하나로 묶고, 두 차례의 통신 라운드를 거쳐 BIP340과 호환되는 슈노르(Schnorr) 서명 하나를 만드는 n-of-n 방식입니다. 탭루트 키 경로에서 쓰면 체인에는 서명자가 한 명인 일반 P2TR과 똑같은 공개키·서명 형태만 보입니다. 전통적인 스크립트 멀티시그는 여러 공개키와 개별 서명을 redeemScript나 증인 스크립트, 탭스크립트에 드러내므로 크기와 정책 노출이 더 큽니다. 대신 몇 명 이상이 서명해야 하는지 같은 기준 조건을 스크립트에서 바로 표현할 수 있습니다.
집계 키 하나가 여러 서명자를 대표합니다
MuSig2의 키 집계(KeyAgg)는 참여자 공개키마다 계수를 곱해, 악성 키(rogue-key) 공격을 막는 집계 점을 계산합니다. BIP327 v1.0.4는 BIP340 공개키·서명과 호환되고 탭루트 트윅도 지원합니다. 키를 어떤 순서로 둘지 미리 합의하지 않으면 참여자마다 다른 집계 키가 나올 수 있으므로 정해진 기준 목록을 고정해야 합니다.
이 출력을 P2TR 키 경로로 쓰면 관찰자는 여러 서명자가 협력했는지 알아차리기 어렵습니다. P2SH 멀티시그처럼 m, n과 각 공개키가 지출 때 드러나지 않습니다. 프라이버시와 비용에서 이득을 보는 대신, 조직은 서명자 구성과 승인 증거를 별도 감사 기록에 남겨야 합니다.
MuSig2는 여러 서명을 감춰 주는 스크립트가 아닙니다. 여러 서명자가 정상적인 슈노르 서명 하나를 함께 만드는 프로토콜입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 집계 키 하나가 여러 서명자를 대표합니다
MuSig2의 키 집계(KeyAgg)는 참여자 공개키마다 계수를 곱해, 악성 키(rogue-key) 공격을 막는 집계 점을 계산합니다.
- 서명은 논스와 부분 서명, 두 라운드로 진행됩니다
일반적인 흐름에서 서명자는 저마다 비밀 논스(nonce)를 만들고 공개 논스를 주고받습니다.
- 논스는 한 번만 쓰고 곧바로 버립니다
같은 비밀 논스를 다른 메시지나 다른 집계 맥락에 다시 쓰면, 두 부분 서명의 관계에서 비밀키가 드러날 수 있습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
서명은 논스와 부분 서명, 두 라운드로 진행됩니다
일반적인 흐름에서 서명자는 저마다 비밀 논스(nonce)를 만들고 공개 논스를 주고받습니다. 공개 논스를 모두 집계한 뒤 메시지, 집계 키, 트윅을 묶은 세션 맥락으로 부분 서명을 만듭니다. 집계자는 부분 서명을 검증하고 합쳐 최종 BIP340 서명을 완성합니다.
BIP327은 외부 집계자가 통신 부담을 덜어 줄 수 있지만, 악의적인 집계자는 세션을 실패시킬 수 있다고 설명합니다. 개별 논스를 감추거나 바꾸면 부분 서명을 검증하는 능력도 달라집니다. 가용성을 신뢰와 헷갈리지 말고, 시간 초과와 재시도, 책임 추적 기록을 미리 설계합니다.
| 항목 | MuSig2 키 경로 | 스크립트 멀티시그 |
|---|---|---|
| 온체인 키 | 집계 키 하나 | 여러 키가 드러날 수 있음 |
| 서명 형태 | BIP340 서명 하나 | 개별 서명 여러 개 |
| 기본 정책 | n-of-n | m-of-n 표현 가능 |
| 상호작용 | 논스·부분 서명 라운드 | PSBT로 서명 수집 |
| 주요 위험 | 논스·세션 상태 | 스크립트·키 순서 오류 |
논스는 한 번만 쓰고 곧바로 버립니다
같은 비밀 논스를 다른 메시지나 다른 집계 맥락에 다시 쓰면, 두 부분 서명의 관계에서 비밀키가 드러날 수 있습니다. 장치가 멈춘 뒤 세션 상태를 잘못 되살려 논스를 재사용하는 것도 같은 위험입니다. 서명 장치는 논스를 메시지·집계 키·세션 ID에 묶어 두고, 쓴 뒤에는 지워야 합니다.
BIP327은 상태를 두지 않는 결정적 서명 방식도 정의합니다. 다만 이는 별도 입력과 다른 서명자들의 집계 논스를 쓰는 방식이지, 아무렇게나 결정적 논스를 만들어도 된다는 뜻이 아닙니다. 구현체는 공식 테스트 벡터와 상태 전이 검사를 통과해야 하고, 부분 서명을 보내기 전에 화면에서 최종 거래를 확인해야 합니다.
- 참여 공개키 목록과 순서를 합의합니다.
- 집계 키와 탭루트 트윅을 각자 따로 계산합니다.
- 세션마다 새 비밀 논스를 만듭니다.
- 모든 서명자가 같은 메시지인지 확인합니다.
- 부분 서명을 검증한 뒤 최종 서명을 조립합니다.
전통 멀티시그는 정책을 드러내 놓고 보여 줍니다
레거시 P2SH 2-of-3은 redeemScript에 기준 수와 세 공개키를 넣고, 지출 때 여러 ECDSA 서명을 냅니다. 탭스크립트는 OP_CHECKSIGADD로 기준 정책을 표현합니다. 사용한 리프가 공개되면 관찰자도 조건을 읽을 수 있지만, 서명자 한 명이 연락이 닿지 않아도 지출할 수 있는 m-of-n 정책을 직접 짤 수 있습니다.
MuSig2 기본형인 n-of-n에서는 서명자 한 명만 응답하지 않아도 키 경로 서명을 끝낼 수 없습니다. 예비 스크립트 경로에 지연 복구 키를 넣어 둘 수는 있지만, 쓰는 순간 정책 일부가 드러나고 증인 수수료도 더 듭니다. 운영 요구부터 정하고 체인에 남는 흔적만 보고 고르지 않습니다.
PSBT와 서명기 구현 버전을 맞춥니다
BIP373은 MuSig2 참여자, 공개 논스, 부분 서명을 PSBT에 담는 필드를 정의합니다. 기존 PSBT 서명기가 이 필드를 모르면 라운드 상태를 지켜 내지 못합니다. 지갑과 하드웨어 서명기, 조정자가 지원하는 BIP327 버전과 트윅 규칙을 배포 전에 맞춰 봅니다.
마지막 검증은 집계 서명이 실제 서명 전 거래의 서명 해시(sighash)에 대해 BIP340 검증을 통과하는지 보는 일입니다. 조정자의 성공 응답만 적어 두지 말고 PSBT 입력, 집계 키, 세션 기록 해시, 최종 거래 ID를 함께 이어 둡니다. 테스트 중에도 비밀 논스나 개인키를 로그에 남기지 않습니다.
자주 묻는 질문
MuSig2는 2-of-3 같은 기준 방식을 언제나 지원하나요?
BIP327 MuSig2는 n-of-n입니다. 기준 방식이 필요하면 별도 프로토콜이나 스크립트 경로 정책을 써야 합니다.
집계 키는 서명자끼리 통신해야 만들 수 있나요?
키 집계 자체는 주고받을 필요가 없습니다. 하지만 실제 서명에는 논스와 부분 서명 라운드가 필요합니다.
집계자가 자금을 훔칠 수 있나요?
정상 프로토콜에서는 서명을 위조할 수 없지만 세션을 방해할 수는 있습니다. 서명자는 메시지와 맥락을 스스로 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
