메인넷에서 1로 시작하는 주소는 보통 P2PKH, 3은 P2SH, bc1은 네이티브 세그윗 계열입니다. bc1q는 주로 SegWit v0, bc1p는 Taproot의 SegWit v1에 쓰입니다. 시작 문자는 주소 형식의 단서이지만 소유자나 안전성을 보증하지 않으므로 지갑 지원 여부와 전체 주소를 함께 확인해야 합니다.
주소의 첫 글자는 잠금 조건을 포장하는 방식의 단서다
비트코인 주소는 코인이 들어 있는 계좌 번호라기보다, 새 거래 출력에 어떤 잠금 조건을 넣어야 하는지 지갑이 읽을 수 있게 표현한 문자열입니다. 메인넷에서 1로 시작하는 주소는 전통적인 P2PKH에 흔하고, 3으로 시작하는 주소는 P2SH에 쓰입니다. bc1으로 시작하면 Bech32 계열 인코딩을 사용한 SegWit 출력일 가능성이 큽니다. 이 차이는 같은 비트코인을 받는 여러 방법이며 별개의 코인을 뜻하지 않습니다.
첫 글자만으로 구체적인 지갑 회사나 수취인을 알아낼 수는 없습니다. 특히 3 주소는 중첩 세그윗뿐 아니라 여러 종류의 redeem script를 담을 수 있어 '3이면 무조건 멀티시그' 또는 '3이면 무조건 세그윗'이라고 단정하면 틀립니다. 주소가 제공하는 정보는 지급에 필요한 스크립트 유형의 일부 단서이고, 실제 지출 조건은 해당 출력이 나중에 소비될 때 더 자세히 드러납니다.
| 시작 예 | 대표 형식 | 실무에서 읽을 점 |
|---|---|---|
| 1… | P2PKH | 오래된 지갑에서도 널리 지원 |
| 3… | P2SH | redeem script를 해시로 감싼 형식 |
| bc1q… | SegWit v0 | Bech32와 witness v0 조합 |
| bc1p… | Taproot, SegWit v1 | Bech32m과 witness v1 조합 |
1과 3 주소는 Base58Check를 사용한다
전통적인 P2PKH와 P2SH 주소는 버전 바이트와 해시, 체크섬을 Base58Check로 표현합니다. Bitcoin Developer Reference는 메인넷 P2PKH에 0x00, P2SH에 0x05 버전 바이트가 흔히 쓰이며, 이 데이터에 이중 SHA-256으로 만든 체크섬 일부를 붙인다고 설명합니다. 버전 값과 Base58 표현의 결과로 사람이 보는 문자열이 각각 1과 3으로 시작하게 됩니다.
체크섬은 복사나 입력 과정의 일부 오류를 탐지하는 장치입니다. 하지만 체크섬을 통과했다고 해서 주소가 의도한 상대의 것이라는 뜻은 아닙니다. 공격자가 자신의 유효한 주소를 보내면 그 주소도 당연히 올바른 체크섬을 갖습니다. 따라서 지갑이 '유효한 주소'라고 표시하는 것과 '올바른 수취인 주소'인지 확인하는 것은 서로 다른 검사입니다.
유효한 형식은 올바른 수취인을 보증하지 않는다.
JOBCOIN 해설
bc1q와 bc1p는 witness 버전을 구분한다
BIP 173은 Bech32 주소 형식과 SegWit 주소 변환 규칙을 정의했습니다. 사람이 읽을 수 있는 부분인 bc는 비트코인 메인넷을 가리키고, 뒤의 1은 구분자입니다. 따라서 bc1 전체를 한 덩어리의 브랜드 이름처럼 읽기보다 네트워크 접두부와 인코딩 구분자로 이해하면 좋습니다. 테스트넷 주소는 메인넷과 다른 사람이 읽을 수 있는 부분을 사용하므로 네트워크 혼동을 찾는 데도 도움이 됩니다.
Taproot에 쓰이는 witness v1은 BIP 350의 Bech32m 체크섬을 사용합니다. 그래서 bc1p 주소를 구형 Bech32 구현이 잘못 처리할 수 있고, 반대로 최신 디코더는 witness 버전에 맞는 체크섬 형식을 검사해야 합니다. bc1q와 bc1p는 첫 세 글자가 같아도 내부 버전과 체크섬 규칙이 같지 않습니다. 송금 앱이 주소를 인식하지 못하면 문자를 억지로 바꾸지 말고 앱의 Taproot 지원 여부를 확인해야 합니다.
- bc는 메인넷의 사람이 읽을 수 있는 접두부인지 확인한다.
- bc1q인지 bc1p인지 구분해 수취 지갑 지원 여부를 확인한다.
- 주소를 변환하거나 앞부분을 임의로 고치지 않는다.
- 큰 금액 전에 같은 네트워크에서 소액 시험 송금을 고려한다.
세그윗 주소가 수수료에 영향을 주는 방식
SegWit은 서명 관련 데이터를 별도 구조로 다루고 거래 무게와 가상 크기 계산을 도입했습니다. 네이티브 세그윗 출력을 소비하는 거래는 전통 형식과 비교해 같은 기능에서 가상 크기를 줄일 수 있어 수수료 효율이 좋아질 수 있습니다. 다만 주소만 바꾼다고 모든 거래가 항상 같은 비율로 저렴해지는 것은 아닙니다. 실제 입력 유형과 개수, 출력 구성, 선택한 수수료율이 총비용을 결정합니다.
3으로 시작하는 중첩 세그윗은 네이티브 bc1 지원이 부족하던 시기에 호환성을 높이는 다리 역할을 했습니다. 오늘도 서비스마다 출금 주소 지원 범위가 다를 수 있습니다. 받는 쪽이 bc1 주소를 생성했다고 해서 보내는 거래소가 반드시 이를 지원하는 것은 아니므로, 출금 폼에서 주소가 거부될 때는 수취 주소가 틀렸다고 단정하기보다 해당 서비스의 지원 형식을 먼저 확인합니다.
송금 화면에서는 네트워크와 전체 주소를 확인한다
접두사는 빠른 1차 확인에 유용합니다. 비트코인 메인넷 출금을 선택했는데 주소가 예상한 형식과 전혀 다르다면 멈춰야 합니다. 그러나 접두사가 맞는 것만으로 확인을 끝내서는 안 됩니다. 복사한 전체 주소의 처음과 끝 여러 글자를 수취인이 제시한 값과 대조하고, 가능하면 QR 코드와 텍스트를 서로 다른 경로로 확인합니다.
주소를 클립보드에서 붙여 넣은 직후에는 악성 프로그램이 값을 바꾸지 않았는지 다시 확인합니다. 최근 거래 내역에서 비슷한 앞뒤 글자의 주소를 골라 재사용하는 것도 위험합니다. 지갑이 새 수신 주소를 생성하는 구조라면 매번 수취인이 현재 제공한 주소를 기준으로 삼습니다. 형식 검사는 오타를 줄이는 한 층이고, 상대 확인은 별도의 보안 절차입니다.
지원되지 않는 주소를 만났을 때의 대응
앱이 bc1p를 지원하지 않는다면 수취인에게 지원되는 다른 형식의 새 주소를 요청할 수 있습니다. 이때 검색 사이트에서 임의의 주소 변환기를 사용하거나 bc1p를 bc1q로 글자만 고쳐서는 안 됩니다. 주소는 잠금 조건과 체크섬을 인코딩한 결과라 일부 문자를 바꾸면 다른 데이터가 되거나 유효성 검사를 통과하지 못합니다.
기업이나 고액 거래에서는 주소를 별도 채널로 재확인하고 소액 시험 거래 후 확정을 기다리는 절차가 유용합니다. 시험 거래의 주소와 본 거래의 주소가 같아야 하는지, 수취 시스템이 입금마다 새 주소를 발급하는지도 먼저 확인합니다. 주소 시작 문자는 판단을 돕는 표지일 뿐이며, 최종 기준은 수취인이 확인한 전체 주소와 올바른 비트코인 네트워크입니다.
자주 묻는 질문
3으로 시작하면 항상 세그윗 주소인가요?
아닙니다. 3 주소는 P2SH로, 중첩 세그윗 외에도 다른 redeem script를 담을 수 있습니다.
bc1 주소는 대소문자를 구분하나요?
Bech32는 전체가 대문자이거나 전체가 소문자인 표현은 가능하지만 혼합 대소문자는 유효하지 않습니다. 일반적으로 지갑은 소문자로 표시합니다.
bc1p를 지원하지 않는 거래소에서는 어떻게 하나요?
문자를 고치지 말고 수취 지갑에서 해당 거래소가 지원하는 새 주소 형식을 생성하거나 거래소 지원 범위를 확인해야 합니다.
