유효한 비트코인 메시지 서명은 특정 주소 또는 스크립트 조건을 만족할 수 있는 주체가 정해진 메시지에 동의했다는 암호학적 증거가 될 수 있습니다. 그러나 그 주체의 실명, 주소에 있는 자금의 법적 소유권, 과거 거래의 송신자, 현재도 계속 키를 통제한다는 사실까지 자동으로 증명하지는 않습니다. 검증자는 주소·메시지·서명 형식과 생성 시각의 맥락을 모두 고정하고 주장 범위를 좁혀야 합니다.
서명은 문구와 키 조건의 결합을 검증합니다
검증에는 주소, 원문 메시지, 서명 값이 모두 필요합니다. 공백, 줄바꿈, 대소문자 하나가 달라도 다른 메시지입니다. Bitcoin Core의 verifymessage는 주소와 base64 서명, 메시지를 입력받아 일치 여부를 true 또는 false로 반환합니다. 성공은 그 조합이 검증됐다는 뜻이지 문장 내용이 사실이라는 독립 증명은 아닙니다.
예를 들어 ‘나는 회사 대표다’라는 문구에 주소 키로 서명할 수는 있지만, 해당 주소가 회사 공식 주소인지와 서명자가 실제 대표인지에는 외부 근거가 필요합니다. 반대로 공식 웹사이트에 미리 공개된 주소가 특정 날짜와 목적이 포함된 문구에 서명했다면, 그 주소 키를 통제하는 쪽이 해당 문구에 응답했다는 더 구체적인 증거가 됩니다.
암호학적 서명은 문장의 진실성을 보증하지 않고, 누가 어떤 키 조건으로 그 문장에 동의했는지를 좁혀 줍니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 서명은 문구와 키 조건의 결합을 검증합니다
검증에는 주소, 원문 메시지, 서명 값이 모두 필요합니다.
- 키 보유와 신원과 자금 소유를 분리합니다
개인키를 가진 사람이 서명할 수 있다는 사실은 주소를 기술적으로 통제한다는 근거입니다.
- 재사용 공격을 막으려면 문구에 맥락을 넣습니다
‘확인합니다’처럼 짧고 재사용 가능한 문구는 다른 사이트나 다른 날짜에 다시 제시되기 쉽습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
키 보유와 신원과 자금 소유를 분리합니다
개인키를 가진 사람이 서명할 수 있다는 사실은 주소를 기술적으로 통제한다는 근거입니다. 그러나 거래소 수탁 주소, 회사 공동 지갑, 외부 서명 대행, 유출된 키처럼 통제자와 법적 소유자가 다를 수 있습니다. 서명 시점에 키에 접근했다는 사실을 곧바로 자금의 권리자로 확대하면 안 됩니다.
BIP322는 어떤 메시지 서명 프로토콜도 자금 통제를 완전히 증명할 수 없다고 명시합니다. 서명은 생성 직후 키가 이전되거나 유출되면 현재 상태를 나타내지 못할 수 있고, 키 보유자가 다른 사람을 대신해 문구에 서명할 수도 있습니다. 과거 거래를 내가 보냈다는 주장도 BIP322의 기본 사용 사례가 아닙니다.
| 주장 | 서명만으로 가능한 판단 | 추가 근거 |
|---|---|---|
| 특정 문구에 대한 키 응답 | 정확한 형식이면 검증 가능 | 메시지 원문·주소·서명 |
| 서명자의 실명 | 확정 불가 | 공식 채널·신원 확인 |
| 주소 자금의 법적 소유 | 확정 불가 | 계약·수탁 관계 |
| 과거 거래를 직접 송금 | 기본 서명만으로 확정 불가 | 거래 생성 기록·별도 증거 |
| 현재도 키를 보유 | 오래된 서명만으로 확정 불가 | 새 nonce가 든 재서명 |
재사용 공격을 막으려면 문구에 맥락을 넣습니다
‘확인합니다’처럼 짧고 재사용 가능한 문구는 다른 사이트나 다른 날짜에 다시 제시되기 쉽습니다. 검증 요청에는 도메인, 목적, 고유한 nonce, UTC 시각, 만료 시각을 넣으세요. 공개할 필요가 없는 개인정보나 비밀은 서명 문구에 포함하지 않습니다. 서명은 메시지를 암호화하지 않으므로 원문을 보는 사람에게 내용이 드러납니다.
검증자는 자신이 만든 nonce가 정확히 포함됐는지 확인하고, 메시지 표시 화면에서 줄바꿈과 유니코드가 바뀌지 않았는지 보관해야 합니다. 문구를 캡처 이미지로만 받지 말고 복사 가능한 원문을 확보하세요. 웹 서비스가 접두사나 형식을 자동으로 바꾸는 경우 어떤 표준으로 서명됐는지도 기록해야 합니다.
- 검증 목적과 대상 도메인을 메시지에 포함합니다.
- 예측하기 어려운 일회성 nonce와 만료 시각을 넣습니다.
- 주소·원문·서명·사용 표준을 한 묶음으로 보존합니다.
- 지갑 화면에 표시된 전체 문구를 서명 전에 확인합니다.
- 검증 성공과 신원 확인 결과를 별도 항목으로 기록합니다.
레거시 방식과 BIP322 지원 범위를 확인합니다
전통적인 Bitcoin Core 메시지 서명은 주로 P2PKH 주소 형식에서 널리 사용됐습니다. BIP322는 비트코인 스크립트를 기반으로 세그윗과 탭루트 등 더 다양한 주소 조건을 다루기 위한 일반 형식을 정의합니다. 지갑이 ‘메시지 서명’을 지원한다고 해도 어떤 주소 유형과 어떤 변형을 지원하는지는 다를 수 있습니다.
BIP322에는 legacy, simple, full, proof-of-funds 변형이 있으며 검증 소프트웨어의 호환성도 확인해야 합니다. 한 지갑에서 만든 서명이 다른 검증기에서 실패한다고 즉시 위조라 단정하지 말고 주소 유형, 접두사, 직렬화 형식, 메시지 인코딩을 대조하세요. 동시에 검증기가 지원하지 않는 형식을 성공처럼 표시하지 않도록 공식 문서를 확인합니다.
서명 요청 자체가 피싱일 수 있습니다
의미를 이해하지 못한 메시지나 거래 유사 데이터에 서명하면 로그인 승인, 소유권 주장, 다른 서비스의 인증에 악용될 수 있습니다. ‘가스비가 없다’거나 ‘자금은 이동하지 않는다’는 설명만 믿지 말고 사람이 읽을 수 있는 전체 메시지와 요청 출처를 확인하세요. 메시지 서명과 온체인 거래 서명은 구분되지만, UI가 모호하면 중단하는 편이 안전합니다.
개인키를 내보내 signmessagewithprivkey 같은 명령에 붙여 넣는 방식은 피하세요. 지갑 내부의 서명 기능을 사용하고 하드웨어 지갑이라면 기기 화면에 표시된 주소와 메시지를 확인합니다. 온라인 검증 사이트에는 개인키가 필요하지 않습니다. 검증을 위해 시드나 개인키를 요구하는 곳은 사용하지 마세요.
검증 결과를 짧은 주장으로 기록합니다
좋은 결과 기록은 ‘2026-09-27에 주소 A가 nonce N을 포함한 메시지 M에 대해 BIP322 simple 서명을 생성했고 검증기 V에서 유효했다’처럼 범위를 제한합니다. ‘A의 주인은 누구다’ 또는 ‘A의 모든 자금은 누구 소유다’라는 결론은 서명 밖의 사실이므로 별도 근거가 필요합니다.
중요한 계약이나 지급 검증이라면 새 nonce로 다시 서명을 받고 공식 채널에서 주소를 교차 확인하세요. 공동 지갑은 여러 서명 조건과 정책이 있으므로 단일 주소 서명만으로 조직 전체의 승인을 나타내지 않을 수 있습니다. 서명은 유용한 한 조각이지만 주장 전체를 대신하지 않습니다.
자주 묻는 질문
유효한 서명이 있으면 주소 잔액도 그 사람 소유인가요?
아닙니다. 기술적 키 통제와 법적·경제적 소유는 다를 수 있습니다. 수탁·공동 지갑 관계를 별도로 확인해야 합니다.
옛날 서명으로 지금도 키를 가진 것을 증명할 수 있나요?
보장되지 않습니다. 현재 시각과 일회성 nonce를 넣은 새 메시지 서명을 요청하는 편이 낫습니다.
서명 검증 사이트에 시드가 필요한가요?
필요하지 않습니다. 검증에는 주소·메시지·서명만 필요합니다. 시드나 개인키를 요구하면 중단하세요.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
