BIP340은 secp256k1 위에서 32바이트 x-only 공개키와 64바이트 Schnorr signature를 정의합니다. 검증식 sG=R+eP의 선형 구조는 여러 참여자의 공개키와 부분 서명을 안전한 별도 프로토콜로 결합해 최종적으로 하나의 공개키와 하나의 서명처럼 보이게 하는 기반입니다. 그러나 개별 Schnorr 서명을 단순히 더하면 안전한 multisignature가 되는 것은 아니며 rogue-key 방지, nonce 생성·커밋, 세션 바인딩을 갖춘 MuSig2 같은 프로토콜이 필요합니다.
BIP340은 정확한 인코딩과 검증을 고정합니다
BIP340 signature는 R의 x 좌표 r 32바이트와 scalar s 32바이트를 이어 붙인 64바이트입니다. 공개키는 secp256k1 point의 x 좌표 32바이트이며 lift_x는 even y를 가진 point를 선택합니다. 단순히 ‘Schnorr 계열’이라는 이름만 같아도 encoding과 challenge hash가 다르면 BIP340과 호환되지 않습니다.
Challenge e는 tagged hash BIP0340/challenge에 r, public key bytes, message를 넣어 계산합니다. Verifier는 범위와 point 조건을 확인하고 R=sG-eP가 무한점이 아니며 even y이고 x(R)=r인지 봅니다. Wallet은 임의 길이 message를 그대로 받는 구현과 32바이트 거래 digest를 서명하는 상위 규칙을 구분해야 합니다.
Schnorr의 선형성은 조합 가능한 재료이며, 안전한 다중서명 완제품은 별도 프로토콜이 만듭니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- BIP340은 정확한 인코딩과 검증을 고정합니다
BIP340 signature는 R의 x 좌표 r 32바이트와 scalar s 32바이트를 이어 붙인 64바이트입니다.
- 선형 검증식이 집계를 가능하게 합니다
한 signer의 s=k+ed 관계는 sG=R+eP로 검증됩니다.
- Tagged hash와 auxiliary randomness가 도메인을 나눕니다
BIP340은 hash 입력마다 BIP0340/aux, nonce, challenge 태그를 사용합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
선형 검증식이 집계를 가능하게 합니다
한 signer의 s=k+ed 관계는 sG=R+eP로 검증됩니다. 여러 signer의 key와 nonce, partial signature를 계수와 함께 합치면 aggregate public key에 대해 보통 BIP340 verifier가 받아들이는 하나의 결과를 만들 수 있습니다. Chain은 개별 signer 목록을 볼 필요가 없습니다.
이 특성은 Taproot key path multisignature의 작은 on-chain footprint와 policy privacy를 돕습니다. 하지만 누가 몇 명인지 숨는다는 것은 운영 audit에서도 signer 참여 증거가 chain에 남지 않는다는 뜻입니다. 참여자는 session transcript와 정책 승인을 별도로 기록해야 합니다.
| 항목 | BIP340 Schnorr | 전통 Bitcoin ECDSA |
|---|---|---|
| 서명 인코딩 | 고정 64바이트 | DER 가변 길이 |
| 공개키 표현 | x-only 32바이트 | 압축 33바이트 흔함 |
| 선형 집계 기반 | 직접적 | 별도 복잡성 |
| Taproot key path | 기본 서명 | 사용하지 않음 |
| nonce 실패 | 개인키 위험 | 마찬가지로 위험 |
Tagged hash와 auxiliary randomness가 도메인을 나눕니다
BIP340은 hash 입력마다 BIP0340/aux, nonce, challenge 태그를 사용합니다. 태그 hash를 두 번 prefix하는 구조는 같은 SHA256 primitive를 다른 용도의 scheme과 섞어 생길 수 있는 해석 충돌을 줄입니다. 구현이 임의 태그나 field 순서를 쓰면 표준 test vector를 통과하지 못합니다.
Signing은 secret key와 message, auxiliary random data를 사용해 nonce를 만듭니다. Auxiliary randomness는 필수 entropy를 외부 RNG 하나에만 의존하지 않도록 설계됐지만 0 값을 허용한다는 설명을 ‘nonce 관리가 중요하지 않다’로 읽으면 안 됩니다. fault·side channel과 nonce 재사용은 여전히 핵심 위험입니다.
- BIP340 공식 test vectors를 모두 실행합니다.
- x-only key의 even-y 정규화를 확인합니다.
- tagged hash 문자열과 field 순서를 고정합니다.
- nonce·aux randomness 처리를 격리합니다.
- multisig는 검토된 MuSig2 구현을 사용합니다.
Batch verification은 구현 선택입니다
BIP340은 여러 signature를 무작위 계수로 결합해 batch verify할 수 있는 구조를 설명합니다. 대량 검증에서 scalar multiplication 비용을 줄일 수 있지만 실패하면 어느 서명이 잘못됐는지 찾기 위해 개별 검증이나 분할 전략이 필요합니다. Consensus node 구현이 반드시 batch를 써야 하는 것은 아닙니다.
Batch coefficient를 공격자가 예측·통제하면 soundness가 약해질 수 있어 안전한 randomness와 알고리즘 준수가 필요합니다. 결과가 false인 batch를 단순 재시도해 true가 될 때까지 받는 로직은 만들지 않습니다. 단일 검증과 batch 검증의 동일 결과를 test vector와 fuzzing으로 확인합니다.
Taproot와 MuSig2의 역할을 분리합니다
Taproot key path는 BIP341 output key에 대한 BIP340 signature를 요구합니다. 이 key가 단일 signer key인지 여러 key의 MuSig2 aggregate인지 consensus는 구분하지 않습니다. MuSig2는 key aggregation, nonce exchange, partial signing을 정의하고 결과만 BIP340 signature로 제공합니다.
BIP340 자체는 t-of-n threshold scheme을 정의하지 않습니다. BIP327 MuSig2도 기본적으로 n-of-n이며 threshold 요구는 다른 검토된 protocol이나 script path 정책이 필요합니다. ‘Schnorr라서 자동으로 2-of-3’ 같은 제품 설명은 signer availability와 recovery 조건을 숨깁니다.
자주 묻는 질문
Schnorr 공개키는 왜 32바이트인가요?
BIP340은 x 좌표만 인코딩하고 검증 시 even y인 point를 선택하는 x-only 규칙을 사용합니다.
서명 두 개를 더하면 다중서명이 되나요?
아닙니다. Rogue-key와 nonce 공격을 막는 key aggregation·세션 프로토콜이 필요합니다.
MuSig2는 2-of-3 threshold인가요?
BIP327 MuSig2는 기본적으로 n-of-n입니다. t-of-n 요구는 별도 scheme이나 script policy가 필요합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
