비트코인 주소 체계: P2PKH에서 Bech32m까지

비트코인 주소는 계정이 아니다. 블록체인에 저장되지도 않는다. 어디에도 등록되지 않는다. 비트코인 주소는 잠금 스크립트 — 비트코인을 지출할 수 있는 조건을 명시하는 프로그램 — 를 사람이 읽을 수 있는 형태로 압축 인코딩한 것이다. “주소로 비트코인을 보낸다”는 것은 그 주소가 인코딩하는 스크립트에 의해 잠긴 트랜잭션 출력을 생성한다는 뜻이다.

비트코인은 역사를 통해 네 가지 주요 주소 형식을 거쳤으며, 각각은 인코딩 효율성, 오류 감지, 기반 스크립트 기능의 진화를 나타낸다. P2PKH에서 P2TR로의 진행은 단순한 외형 변화가 아니다 — 비트코인의 보안, 프라이버시, 확장성의 근본적 개선을 반영한다.

도출 경로: 개인 키에서 주소까지

1단계: 개인 키 생성

비트코인 개인 키는 256비트(32바이트) 난수로, 1에서 n-1 범위에서 선택된다. 여기서 n은 secp256k1 타원곡선의 차수(약 1.158 x 10^77)이다. 비트코인의 보안은 전적으로 이 숫자의 무작위성에 달려 있다. 추측하거나, 예측하거나, 계산할 수 있다면, 비트코인을 탈취당할 수 있다.

가능한 개인 키의 수는 관찰 가능한 우주의 추정 원자 수(약 10^80)를 초과한다.

개인 키 예시(16진수):

e9873d79c6d87dc0fb6a5778633389f4453213303da61f20bd67fc233aa33262

2단계: 공개 키 도출 (타원곡선 곱셈)

공개 키는 secp256k1 곡선 위에서 타원곡선 점 곱셈을 통해 개인 키로부터 도출된다. 개인 키 k와 곡선의 생성점 G가 주어지면, 공개 키 K는:

K = k * G

이것은 단방향 연산이다 — k와 G로부터 K를 계산하는 것은 간단하지만(수 밀리초), K와 G로부터 k를 계산하는 것은 현재 기술로 우주의 나이보다 오래 걸릴 만큼 계산적으로 불가능하다.

비압축 공개 키는 65바이트: 0x04 접두사 + x 32바이트 + y 32바이트. 압축 공개 키는 33바이트: 0x02 또는 0x03 접두사(y가 짝수인지 홀수인지) + x 32바이트. 곡선 위의 각 x에 대해 가능한 y 값은 두 개뿐이므로, 압축 형식으로 충분하며 현재 표준이다.

3단계: 해싱 (레거시 및 SegWit v0 주소)

P2PKH, P2SH, P2WPKH 주소에서 공개 키는 해시되어 더 짧고 고정 길이인 식별자를 생성한다:

HASH160(publicKey) = RIPEMD-160(SHA-256(publicKey))

이것은 20바이트(160비트) 해시를 생성한다. 이중 해싱은 두 가지 목적을 갖는다:

1. 크기 축소: 33바이트(압축 공개 키) → 20바이트(해시)
2. 양자 저항 레이어: 공격자가 타원곡선을 역전시킬 수 있더라도(공개 키에서 개인 키 추출), 먼저 해시에서 공개 키를 찾아야 한다 — RIPEMD-160을 깨야 한다는 뜻이다. 하지만 이것은 공개 키가 아직 드러나지 않은 주소(받기만 하고 보내지 않은 주소)에만 유효하다.

4단계: 인코딩

원시 해시는 두 가지 인코딩 체계 중 하나를 사용하여 사람이 읽을 수 있는 문자열로 인코딩된다: Base58Check(레거시) 또는 Bech32/Bech32m(현대).

주소 유형 1: P2PKH — Pay-to-Public-Key-Hash

형식: 1로 시작 예시: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa (사토시의 제네시스 블록 주소) 인코딩: Base58Check 활성 시점: 제네시스 블록 (2009년 1월 3일)

P2PKH는 원래의 비트코인 주소 형식이다. P2PKH 주소로 비트코인을 보내면, 다음과 같은 잠금 스크립트를 가진 출력을 생성한다:

OP_DUP OP_HASH160 <20-byte pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Base58Check 인코딩

Base58은 시각적으로 혼동되는 문자를 제거한 Base64의 부분집합이다:

• 0(영)과 O(대문자 O) 제거 — 비슷하게 보임
• I(대문자 I)와 l(소문자 L) 제거 — 비슷하게 보임
• +와 / 제거 — URL과 파일명에서 문제 유발

문자 집합: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

Base58Check는 Base58에 체크섬을 추가한다:

1. 버전 바이트 + 페이로드로 시작: 0x00 + <20-byte pubKeyHash>
2. 체크섬 계산: SHA-256(SHA-256(version + payload))의 처음 4바이트
3. 연결: version + payload + checksum
4. Base58로 인코딩

버전 바이트 0x00이 Base58 인코딩 후 P2PKH 주소를 1로 시작하게 만든다.

Base58Check의 한계

대소문자 구분. Base58은 대문자와 소문자 모두 사용하여 주소가 대소문자에 민감하다. 단일 문자의 대소문자를 잘못 입력하면 주소가 완전히 바뀔 수 있다.

오류 감지 약점. 4바이트 체크섬은 높은 확률로 오류를 감지하지만, 특정 오류 패턴에 최적화되지 않았다. 오류를 수정할 수 없고 감지만 가능하다.

비효율적 QR 인코딩. QR 코드는 바이너리 모드보다 상당히 컴팩트한 알파뉴메릭 모드가 있지만, 대문자만 지원한다. Base58이 소문자를 포함하므로 바이너리 모드를 사용해야 하여 더 큰 QR 코드를 생성한다.

주소 유형 2: P2SH — Pay-to-Script-Hash

형식: 3으로 시작 인코딩: Base58Check 활성 시점: BIP-16 (2012)

P2SH 주소는 공개 키의 해시가 아닌 임의 스크립트의 해시를 인코딩한다.

인코딩 과정은 P2PKH와 동일하지만 버전 바이트가 0x05(Base58 인코딩 후 3으로 시작하는 주소 생성):

Base58Check(0x05 + HASH160(redeemScript) + checksum)

P2SH의 주요 용도:

• 다중서명 지갑 — 리딤 스크립트에 OP_CHECKMULTISIG 포함
• 래핑된 세그윗 (P2SH-P2WPKH) — 세그윗 증인 프로그램을 감싸는 P2SH 스크립트

주소 유형 3: P2WPKH — Pay-to-Witness-Public-Key-Hash (SegWit v0)

형식: bc1q로 시작 예시: bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq 인코딩: Bech32 활성 시점: BIP-141/143/173 (2017)

P2WPKH는 네이티브 세그윗 버전 0 주소 형식이다. Base58Check의 모든 한계를 해결하기 위해 설계된 완전히 새로운 인코딩 체계 — Bech32 — 를 사용한다.

Bech32 인코딩

Bech32(BIP-173)는 피터 위일러와 그렉 맥스웰이 설계했으며, Base58Check에 대한 포괄적 개선이다.

Bech32 주소의 구조:

bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq
│  │ │                                      │
│  │ └──────── 데이터 ──────────────────────┘
│  └── 구분자
└── 사람이 읽을 수 있는 부분 (HRP)

문자 집합: Bech32는 32개 문자만 사용: qpzry9x8gf2tvdw0s3jn54khce6mua7l. 모두 소문자(또는 모두 대문자 — 인코딩은 대소문자 무관). Base58Check의 대소문자 구분 문제를 제거한다.

BCH 체크섬: Bech32는 오류 감지를 위해 BCH(Bose-Chaudhuri-Hocquenghem) 코드를 사용하며, 이는 Base58Check의 이중 SHA-256 체크섬보다 근본적으로 우수하다:

• 최대 4자까지 영향을 미치는 모든 오류를 보장 감지
• 4자 이상 영향을 미치는 대부분의 오류 감지
• 오류 위치 파악 — 체크섬이 오류가 존재한다는 것뿐만 아니라 어디에 있는지도 식별 가능
• 32문자 알파벳과 일반적 주소 길이에 맞게 특별 최적화

QR 코드 효율성: Bech32는 소문자 알파뉴메릭 문자만 사용하므로, 주소를 대문자로 변환하면 QR 코드가 더 효율적인 알파뉴메릭 모드를 사용할 수 있다. Base58Check 주소보다 약 30-40% 작은 QR 코드를 생성한다.

Bech32의 약점

Bech32에는 알려진 약점이 있다: 주소 끝부분(체크섬 바로 앞)에서 q 문자를 삽입하거나 삭제해도 유효한 체크섬이 생성될 수 있다. 세그윗 버전 0 주소에서는 고정 길이 요구사항으로 완화되지만, 가변 길이 프로그램이 가능한 미래 세그윗 버전에서는 위험할 수 있다.

이 약점이 Bech32m의 개발로 직접 이어졌다.

주소 유형 4: P2TR — Pay-to-Taproot (SegWit v1)

형식: bc1p로 시작 인코딩: Bech32m 활성 시점: BIP-341/350 (2021년 11월)

P2TR 주소는 탭루트 업그레이드를 사용하는 세그윗 버전 1 출력을 나타낸다. 잠금 스크립트:

OP_1 <32-byte tweaked public key>

P2WPKH와의 두 가지 차이:

1. 버전 바이트가 OP_1(OP_0이 아님)
2. 증인 프로그램이 32바이트 공개 키(20바이트 해시가 아님)

왜 해시 대신 원시 공개 키인가?

P2TR은 20바이트 해시 대신 공개 키의 원시 32바이트 x좌표를 사용한다:

슈노르 서명 검증에 공개 키가 필요. ECDSA(서명에서 공개 키를 복구할 수 있는)와 달리, 슈노르 검증은 공개 키를 명시적 입력으로 요구한다. 지출자가 어차피 공개 키를 드러내야 하므로, 주소에서 해시하는 것은 추가 보안을 제공하지 않는다.

공간 효율성. 해시 방식에서는 출력에 해시와 증인에 공개 키 모두가 필요하다. 원시 키 방식에서는 키만 나타난다.

Bech32m 인코딩

Bech32m(BIP-350)은 삽입/삭제 약점을 수정하는 Bech32의 최소한의 변형이다. 유일한 차이는 체크섬 계산의 상수 하나다:

Bech32 체크섬 상수:  1
Bech32m 체크섬 상수: 0x2bc830a3

이 단일 변경으로:

• 주소 끝부분에서 문자를 삽입하거나 삭제하면 체크섬이 확실히 무효화된다
• Bech32의 다른 모든 바람직한 속성(오류 감지, 위치 파악, QR 효율성, 대소문자 무관)이 보존된다

호환성 규칙:

• 세그윗 버전 0 (P2WPKH, P2WSH)은 Bech32 사용 — 주소는 bc1q로 시작
• 세그윗 버전 1+ (P2TR 및 미래 버전)은 Bech32m 사용 — P2TR 주소는 bc1p로 시작

bc1 뒤의 q vs p 문자가 증인 버전(0 = q, 1 = p)을 나타내며, 어떤 체크섬 알고리즘이 사용되었는지를 암시적으로 알려준다.

Bech32m이 우수한 이유

모든 인코딩 형식 비교:

속성	Base58Check	Bech32	Bech32m
대소문자 구분	있음	없음	없음
오류 감지 보장	확률적(4바이트 해시)	4개 오류까지 보장	4개 오류까지 보장
오류 위치 파악	불가	가능	가능
QR 코드 효율	낮음(바이너리 모드)	우수(알파뉴메릭)	우수(알파뉴메릭)
삽입/삭제 감지	가능	끝부분 약함	가능
사용처	P2PKH (1…), P2SH (3…)	P2WPKH (bc1q…)	P2TR (bc1p…)

네트워크별 주소 접두사

네트워크	P2PKH	P2SH	P2WPKH	P2TR
메인넷	1...	3...	bc1q...	bc1p...
테스트넷	m... 또는 n...	2...	tb1q...	tb1p...
시그넷	m... 또는 n...	2...	tb1q...	tb1p...
레그테스트	m... 또는 n...	2...	bcrt1q...	bcrt1p...

어떤 주소 유형을 사용해야 하는가?

가능하면 P2TR (bc1p…)을 사용하라. 다음을 제공한다:

• 최고의 프라이버시 (기반 스크립트 복잡도에 관계없이 모든 탭루트 출력이 동일하게 보임)
• 최저의 트랜잭션 수수료 (키 경로 지출에서 가장 작은 증인 데이터)
• 가장 진보된 스크립트 기능 (슈노르 서명, MAST, 탭스크립트)
• 최고의 오류 감지 (Bech32m 인코딩)

대체로 P2WPKH (bc1q…)를 사용하라. 서비스가 P2TR을 지원하지 않으면 P2WPKH가 차선이다. 레거시 주소보다 낮은 수수료와 Bech32 인코딩을 제공한다.

새로운 사용에서는 P2PKH (1…)와 P2SH (3…)를 피하라. 이 레거시 형식은 더 높은 트랜잭션 수수료, 더 큰 트랜잭션 크기, 열등한 오류 감지를 갖는다. 세그윗을 지원하지 않는 매우 오래된 소프트웨어와 상호작용하는 경우에만 사용하라.

2026년 기준, 대다수의 비트코인 지갑과 서비스는 최소한 P2WPKH를 지원하며, P2TR 지원도 점점 보편화되고 있다.

관련 주제는 비트코인 지갑 주소, 세그윗, 탭루트 가이드를 참조하라.