멀티시그니처

호기심

1. 두 개의 서명이 필요한 스크립트가 스택에서 세 개의 항목을 꺼내는 이유는 무엇인가요?
2. 빈 바이트 문자열이 어떻게 단순한 관례가 아니라 합의 규칙이 될 수 있을까요?
3. 10개의 키가 하나로 합쳐져 단일 서명자의 것과 구별할 수 없는 서명이 될 때 무엇이 변하나요?

탐구

1. 멀티시그니처 스크립트는 나열된 n개의 공개 키에 대해 최소 m개의 서명이 유효해야 한다고 규정합니다. 잠금 스크립트에는 m, n개의 공개 키, 그리고 n이 나열됩니다. OP_CHECKMULTISIG는 n, n개의 키, m, 그리고 m개의 서명을 스택에서 꺼내며, 서명은 나열된 순서대로 키와 일치해야 합니다. 유효한 서명이 m개보다 적으면 지출은 무효입니다.
2. 원래 구현의 코딩 오류로 인해 OP_CHECKMULTISIG는 필요한 서명보다 스택 항목을 하나 더 꺼냅니다. 이 ‘더미(dummy)’ 요소는 암호학적 검증에서는 무시되지만 반드시 있어야 합니다. 없으면 스택 언더플로가 발생해 트랜잭션이 실패합니다. 초기 지출자들은 이 자리를 채우는 값으로 OP_0을 사용했고, 노드가 그 자리에 어떤 값이든 받아들였기 때문에 이 관행은 수년간 이어졌습니다.
3. 2017년 8월 SegWit과 함께 활성화된 BIP147(NULLDUMMY)은 이 가변성(malleability) 벡터를 합의 규칙으로 봉쇄했습니다. 이제 더미 요소는 반드시 빈 바이트 배열이어야 합니다. 비어 있지 않은 값이면 단 하나의 0 바이트라도 스크립트가 실패합니다. 이로써 더미의 내용을 바꿔 트랜잭션 ID를 변경하는 일이 불가능해졌고, 이후의 모든 컨펌에 걸쳐 트랜잭션 해시가 안정되었습니다.
4. 표준성(standardness) 규칙은 노드가 어떤 멀티시그 스크립트를 중계할지를 정합니다. 비트코인 코어의 기본 정책에서 베어 멀티시그니처 출력은 키 3개로 제한됩니다. P2SH로 감싸면 멀티시그는 최대 15개의 키를 사용할 수 있고(520바이트 리딤 스크립트 한도에 따른 제한), P2WSH에서는 최대 20개까지 가능합니다. 이 구분 덕분에 복잡한 기업 트레저리 구성도 기본 트랜잭션 계층을 비대하게 만들지 않고 작동할 수 있습니다.
5. 두 가지 새로운 도구가 기존의 멀티시그 패턴을 대체합니다. Taproot의 Schnorr 서명을 기반으로 구축된 별도의 프로토콜인 MuSig2(BIP327, 2023)는 여러 공개 키를 하나의 키로 통합하여 표준 Schnorr 서명을 생성합니다. 온체인상에서는 이 방식으로 발생하는 지출이 일반적인 단일 키 Taproot 방식의 지출과 구별할 수 없습니다. Taproot 자체에 포함된 Tapscript는 OP_CHECKSIGADD를 추가하여, 스택 팝 버그나 기존 옵코드의 20키 제한 없이 단계적인 서명 검증을 가능하게 합니다.
6. 이 메커니즘을 살펴보려면 블록 탐색기를 열고 SegWit 이전의 베어 멀티시그 트랜잭션을 찾으세요. scriptSig를 보면 OP_0으로 시작하고 그 뒤에 서명들이 이어집니다. 이를 P2WSH 멀티시그 지출과 비교해 보세요. 여기서는 위트니스에 빈 항목, 서명들, 그리고 키를 나열한 위트니스 스크립트가 들어 있습니다. 전체 키 목록을 출력에 넣을 때와 입력에 넣을 때의 비용 차이가 바이트 수 차이로 드러나는 점에 주목하세요.

핵심 사실

연습 아홉, 여섯, 셋, 하나

팩트 체크

날짜, 수치 및 주장은 아래에 명시된 출처들을 통해 확인되었습니다.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 7
• BIP147: Dealing with dummy stack element malleability
• BIP327: MuSig2 for BIP340-compatible Multi-Signatures
• BIP342: Validation of Taproot Scripts