비트코인 Schnorr 서명의 선형성이 주는 변화

BIP340은 secp256k1 곡선 위에서 32바이트 x좌표 전용(x-only) 공개키와 64바이트 Schnorr 서명을 정의합니다. 검증식 sG=R+eP의 선형 구조 덕분에, 여러 참여자의 공개키와 부분 서명을 안전한 별도 프로토콜로 합쳐 겉보기에는 공개키 하나와 서명 하나처럼 만들 수 있습니다. 그러나 개별 Schnorr 서명을 그냥 더한다고 안전한 다중서명이 되지는 않습니다. 악성 키(rogue-key) 방지, 논스 생성과 커밋, 세션 묶기를 갖춘 MuSig2 같은 프로토콜이 필요합니다.

BIP340은 정확한 인코딩과 검증 방식을 고정합니다

BIP340 서명은 R의 x좌표 r 32바이트와 스칼라 s 32바이트를 이어 붙인 64바이트입니다. 공개키는 secp256k1 점의 x좌표 32바이트이며, lift_x는 y가 짝수인 점을 고릅니다. 이름이 똑같이 ‘Schnorr 계열’이어도 인코딩과 챌린지 해시가 다르면 BIP340과 호환되지 않습니다.

챌린지 e는 태그 해시 BIP0340/challenge에 r, 공개키 바이트, 메시지를 넣어 계산합니다. 검증자는 값의 범위와 점 조건을 확인하고, R=sG-eP가 무한원점이 아니며 y가 짝수이고 x(R)=r인지 봅니다. 지갑은 임의 길이 메시지를 그대로 받는 구현과, 32바이트 거래 해시값을 서명하는 상위 규칙을 구분해야 합니다.

Schnorr의 선형성은 조합할 수 있는 재료일 뿐이며, 안전한 다중서명 완제품은 별도 프로토콜이 만듭니다.

JOBCOIN 해설

그림으로 보기키 보관과 거래 서명

1. 01
   BIP340은 정확한 인코딩과 검증 방식을 고정합니다

   BIP340 서명은 R의 x좌표 r 32바이트와 스칼라 s 32바이트를 이어 붙인 64바이트입니다.

2. 02
   선형 검증식이 집계를 가능하게 합니다

   서명자 한 명의 s=k+ed 관계는 sG=R+eP로 검증됩니다.

3. 03
   태그 해시와 보조 난수가 용도를 나눕니다

   BIP340은 해시 입력마다 BIP0340/aux, nonce, challenge 태그를 씁니다.

설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

선형 검증식이 집계를 가능하게 합니다

서명자 한 명의 s=k+ed 관계는 sG=R+eP로 검증됩니다. 여러 서명자의 키와 논스, 부분 서명을 계수와 함께 합치면, 집계 공개키에 대해 보통의 BIP340 검증자가 받아들이는 결과 하나를 만들 수 있습니다. 체인은 개별 서명자 목록을 볼 필요가 없습니다.

이 성질은 Taproot 키 경로 다중서명이 온체인에서 차지하는 공간을 줄이고 정책을 감추는 데 도움을 줍니다. 하지만 누가 몇 명 참여했는지 숨는다는 것은, 운영 감사에서도 서명자 참여 증거가 체인에 남지 않는다는 뜻입니다. 참여자는 세션 기록과 정책 승인을 따로 남겨야 합니다.

태그 해시와 보조 난수가 용도를 나눕니다

BIP340은 해시 입력마다 BIP0340/aux, nonce, challenge 태그를 씁니다. 태그 해시를 두 번 앞에 붙이는 구조는 같은 SHA256 기본 함수를 다른 용도의 방식과 섞어 쓸 때 생길 수 있는 해석 충돌을 줄입니다. 구현이 임의의 태그나 항목 순서를 쓰면 표준 테스트 벡터를 통과하지 못합니다.

서명할 때는 비밀키, 메시지, 보조 난수 데이터로 논스를 만듭니다. 보조 난수는 꼭 필요한 무작위성을 외부 난수 생성기 하나에만 기대지 않도록 설계됐지만, 0 값을 허용한다는 설명을 ‘논스 관리가 중요하지 않다’로 읽으면 안 됩니다. 결함 공격, 부채널 공격, 논스 재사용은 여전히 핵심 위험입니다.

• BIP340 공식 테스트 벡터를 모두 실행합니다.
• x좌표 전용 키의 짝수 y 정규화를 확인합니다.
• 태그 해시 문자열과 항목 순서를 고정합니다.
• 논스와 보조 난수 처리를 격리합니다.
• 다중서명에는 검토된 MuSig2 구현을 씁니다.

일괄 검증은 구현이 고르는 선택지입니다

BIP340은 여러 서명을 무작위 계수로 묶어 일괄 검증(batch verification)할 수 있는 구조를 설명합니다. 대량 검증에서 스칼라 곱셈 비용을 줄일 수 있지만, 실패하면 어느 서명이 틀렸는지 찾기 위해 개별 검증이나 나눠 검사하는 전략이 필요합니다. 합의 노드 구현이 반드시 일괄 검증을 써야 하는 것은 아닙니다.

일괄 검증 계수를 공격자가 예측하거나 조종할 수 있으면 건전성이 약해질 수 있으므로, 안전한 난수와 알고리즘 준수가 필요합니다. 거짓으로 나온 일괄 검증을 참이 될 때까지 단순 재시도하는 로직은 만들지 않습니다. 단일 검증과 일괄 검증이 같은 결과를 내는지 테스트 벡터와 퍼징으로 확인합니다.

Taproot와 MuSig2의 역할을 나눕니다

Taproot 키 경로는 BIP341 출력 키에 대한 BIP340 서명을 요구합니다. 이 키가 단일 서명자의 키인지, 여러 키를 MuSig2로 집계한 키인지 합의 규칙은 구분하지 않습니다. MuSig2는 키 집계, 논스 교환, 부분 서명을 정의하고 결과만 BIP340 서명으로 내놓습니다.

BIP340 자체는 t-of-n 임계값 방식을 정의하지 않습니다. BIP327 MuSig2도 기본적으로 n-of-n이며, 임계값이 필요하면 검토된 다른 프로토콜이나 스크립트 경로 정책을 써야 합니다. ‘Schnorr라서 자동으로 2-of-3’ 같은 제품 설명은 서명자 가용성과 복구 조건을 가립니다.

자주 묻는 질문