Bech32m은 Bech32의 체크섬 끝에 섞는 상수를 1에서 0x2bc830a3으로 바꾼 변형이고, 증인 버전 0 주소는 Bech32, 버전 1 이상은 Bech32m으로 만듭니다. 이 글은 2026-10-27에 연 BIP 350 원문(상태 Deployed)으로 확인한 범위만 다룹니다.
확인 기준일 2026-10-27 · 다음 확인 예정 2026-11-26
Bech32에는 어떤 약점이 있었을까?
원문 Motivation은 마지막 글자가 p일 때 그 앞의 q를 몇 개든 넣거나 빼도 체크섬이 깨지지 않는다고 설명합니다. 기존 버전 0 주소는 길이가 고정이라 영향이 없지만 앞으로의 용도에서는 문제가 될 수 있다고 적습니다.
| 구분 | Bech32 | Bech32m |
|---|---|---|
| 체크섬 끝에 섞는 상수 | 1 | 0x2bc830a3 |
| 적용 증인 버전 | 0 (P2WPKH, P2WSH) | 1~16 |
| 증인 프로그램 길이 | 버전 0은 정확히 20 또는 32바이트 | 2~40바이트 범위(예시 디코더 기준) |
| 사람이 읽는 부분(HRP) | 변경 없음 | 변경 없음 |
무엇이 같고 무엇이 달라졌을까?
체크섬 상수 외의 요소는 사람이 읽는 부분(HRP)을 포함해 그대로입니다. 디코더는 두 방식을 모두 시도하되, 디코딩한 증인 버전에 맞는 방식인지 확인해야 합니다. 버전 0 주소의 구조는 비트코인 주소가 1·3·bc1로 시작하는 이유 글에, 버전 1의 지출 방식은 탭루트 key path와 script path 지출 비교 글에 있습니다.
주소를 볼 때는 무엇부터 확인할까?
bc1p로 시작하는 주소는 버전 1이므로 Bech32m 규칙이 적용됩니다. 두 방식을 섞어 쓰는 앱은 체크섬 오류를 낼 수 있어 오류 메시지를 상수 문제로 단정하지 않습니다.
주소 길이는 어떻게 검사될까?
원문의 예시 디코더는 증인 버전을 0부터 16까지로 받고, 증인 프로그램 길이를 2바이트에서 40바이트 사이로 제한하며, 버전 0이면 정확히 20바이트나 32바이트여야 한다고 확인합니다. 따라서 같은 길이의 데이터라도 버전이 다르면 사용하는 체크섬 상수가 달라서, 한 글자만 틀려도 검증이 실패할 수 있습니다. 원문 각주는 버전 0에 두 방식을 모두 허용하면 체크섬의 오류 검출 능력이 약해진다고 설명하므로, 버전과 방식의 짝을 엄격히 맞추는 것이 규칙의 핵심입니다.
이 글에서 확인하지 못한 것은?
Bech32의 문자 집합과 체크섬 다항식의 세부, 원문의 시험 벡터, 개별 지갑과 거래소가 Bech32m 주소를 언제부터 지원했는지는 이번에 확인하지 못했습니다. 따라서 특정 서비스가 bc1p 주소 출금을 지원한다거나 못 한다고 적지 않습니다. 지원 여부는 해당 서비스의 공지에서 확인해야 합니다. 정리하면 Bech32m은 주소의 모양을 바꾸지 않고 검증 수식의 상수 하나만 바꾼 변경이며, 버전 숫자가 어느 쪽 규칙을 쓸지 정합니다. 주소를 직접 입력하다 오류가 나면 먼저 앞머리의 버전 글자를 확인하는 순서가 합리적입니다. 원문 상태는 Deployed입니다.
자주 묻는 질문
Bech32m 주소는 Bech32 주소와 무엇으로 구별하나요?
원문이 정한 규칙은 증인 버전입니다. 버전 1 이상은 Bech32m으로 인코딩합니다.
기존 bc1q 주소가 무효가 되었나요?
원문은 버전 0 주소가 계속 Bech32를 쓴다고 적습니다. 무효가 된다는 내용은 없습니다.
메타데이터의 Replaces 표기는 무슨 뜻인가요?
문서 머리에는 173을 대체한다고 적혀 있으나 본문은 BIP173을 개정한다고 설명해 서로 달라 보입니다. 이 글은 본문 설명을 따랐습니다.
