Schnorr Signature

앨리스가 밥에게 비트코인을 보내려고 합니다. 지갑은 비트코인을 받고 보내는 앱이나 기기입니다. 지갑은 거래를 구성하고, 선택한 서명 모드가 요구하는 데이터에 개인키로 서명합니다. 노드는 서명과 나머지 지출 조건을 모두 검증합니다. 노드는 거래와 블록을 검증하고 네트워크의 다른 참여자와 통신하는 소프트웨어입니다. 유효한 서명만으로 앨리스의 법적 신원이나 의도한 수신자, 충분한 미사용 자금의 존재까지 확인할 수는 없습니다. 각각 별개의 문제입니다. 이미 서명한 결제도 본인이 의도하지 않은 실수일 수 있습니다. [5] [3] [10] [11]

Pieter Wuille, Jonas Nick, Tim Ruffing이 작성한 BIP340은 Bitcoin의 Schnorr 서명을 정확히 정의합니다. BIP341은 이를 Taproot의 지출 규칙에 연결하며, 이 규칙은 2021년 비트코인의 실제 운영 네트워크인 Mainnet의 블록 709632에서 활성화됐습니다. 블록은 공동 기록에 추가하는 거래 묶음입니다. 서명 알고리즘과 지출 조건이라는 두 계층을 구분해야 합니다. 기존 출력 유형과 SegWit v0는 여전히 ECDSA(기존 서명 알고리즘)를 사용합니다. 업그레이드가 과거의 서명을 소급해 바꾼 것은 아닙니다. [1] [2] [11]

바이트는 데이터의 양을 나타내는 일반적인 단위입니다. Bitcoin 방식은 키와 서명 계산에 쓰이는 수학적 구조인 secp256k1 타원곡선을 사용합니다. BIP340은 서명을 고정된 64바이트 형식으로 정의합니다. 공개키는 x좌표의 32바이트로 표현합니다. x-only라는 말이 보안 검사를 생략한다는 뜻은 아닙니다. 검증자가 곡선 위의 어떤 점을 선택할지도 규칙이 명확하게 정합니다. 작고 정확한 형식은 소프트웨어가 처리하기 쉽지만, 이 두 숫자만으로 전체 거래의 크기를 알 수는 없습니다. [1] [12]

지갑은 막연한 ‘동의합니다’에 서명하지 않습니다. sighash 모드는 거래의 어떤 데이터로 서명 대상 메시지를 만들지 정합니다. SIGHASH_DEFAULT는 SIGHASH_ALL과 비슷하게 모든 입력과 출력에 관한 정보를 보호합니다. 이전에 받은 어떤 코인을 쓰고, 어떤 지출 조건이 붙은 새 금액을 만드는지에 관한 정보입니다. 포함된 데이터를 바꾸면 서명이 무효가 됩니다. 하지만 다른 서명 자체처럼 모든 바이트에 서명한다는 뜻은 아닙니다. 허용된 다른 모드는 보호 범위가 다릅니다. 서명은 64바이트이며 기본 모드가 아니면 유형을 나타내는 한 바이트가 붙어 해당 항목이 65바이트가 됩니다. 이는 입력이나 거래 전체의 크기가 아닙니다. [2]

서명할 때 비밀 nonce 값을 만듭니다. 같은 키로 서로 다른 메시지에 이 값을 재사용하면 개인키가 노출될 수 있습니다. 따라서 BIP340은 nonce 도출을 정확히 규정하고, 구현을 추가로 보호하기 위한 보조 난수도 권장합니다. 사용자가 nonce를 직접 정하거나 백업에 적어 두는 것이 아닙니다. 검증된 서명 라이브러리가 관리해야 합니다. 이 부분을 임의로 구현하면 올바른 암호 방식도 무력해질 수 있습니다. [1] [9]

Schnorr 서명의 수학적 구조는 여러 사람이 하나의 메시지에 합의해 공동 서명을 만드는 프로토콜을 가능하게 합니다. BIP327의 MuSig2가 한 예입니다. 이 프로토콜의 기본 형태에서는 선택한 그룹의 모든 구성원이 기여해야 합니다. 참여자 간 조율, 올바른 키 처리, 전용의 안전한 nonce 절차가 필요합니다. 아무렇게나 완성된 서명들을 더하면 되는 것이 아닙니다. 지갑이 Schnorr Signature를 지원한다는 사실만으로 이런 공동 작업까지 지원한다고 볼 수는 없습니다. [8]

Taproot는 서로 다른 지출 경로를 제공합니다. key path에서는 네트워크가 출력에 기록된 공개키에 대해 서명을 검증합니다. 그 키는 한 사람이나 협력하는 그룹을 나타낼 수 있습니다. script path에서는 선택한 스크립트, 즉 결제가 충족해야 하는 조건을 담은 프로그램을 공개합니다. Tapscript는 Taproot에서 사용하는 스크립트 언어의 형태입니다. OP_CHECKSIGADD 명령은 서명 하나를 검증하고 성공하면 누적값에 하나를 더합니다. 이를 반복하면 여러 개별 서명이 요구되는 수를 충족하는지 확인할 수 있습니다. 이러한 스크립트 기반 Multisig는 하나의 집계 서명과 다른 방식입니다. 사용하는 지갑에서 누구의 협력이 필요한지, 무엇이 공개되는지, 키를 잃으면 어떤 복구 방법이 남는지 확인해야 합니다. [7] [2]

중앙 심판이 없는 네트워크에서 바이트를 다르게 해석했다는 이유로 한 노드는 서명을 받아들이고 다른 노드는 거부해서는 안 됩니다. BIP340은 유효한 키, 서명, 검증 절차를 상세히 규정합니다. 여러 서명을 함께 검증해 계산량을 줄이는 batch verification도 가능합니다. 그러나 블록체인의 기록을 바꾸거나 서로 다른 거래 입력의 서명을 하나로 합치는 것은 아닙니다. [1]

공동 key-path 서명은 하나의 키로 만든 서명처럼 보일 수 있습니다. 따라서 서명만 보고 몇 명이 합의했는지 알 수 없는 경우가 있습니다. 다만 금액, 입력과 출력의 연결 관계, 거래 시점은 대체로 관찰할 수 있습니다. Schnorr Signature는 결제를 암호화하지 않습니다. 실제 프라이버시는 Taproot의 사용 방식, 지갑 동작, 결제 상황에도 달려 있습니다. [2] [3]

일반 사용자에게 중요한 것은 수신자, 금액, 수수료를 정확히 보여 주고 안정적으로 복구할 수 있는 지갑입니다. 개발자는 여기에 더해 정확한 BIP340 지원, 테스트 벡터, nonce 관리, 오류 시 동작을 확인해야 합니다. 알고리즘 이름이 제품 전체를 보장하지는 않습니다. libsecp256k1 같은 좋은 라이브러리는 암호 계산을 맡지만, 화면의 결제를 정말 승인해야 하는지 사람 대신 결정할 수는 없습니다. [4] [9] [6]