P2PKH는 공개키의 20바이트 HASH160으로 잠그고, 지출할 때 ECDSA 서명과 공개키 전체를 scriptSig에 드러냅니다. P2SH는 redeemScript의 20바이트 HASH160으로 잠그며, 지출하는 쪽은 해시가 맞는 redeemScript 전체와 그 조건을 채울 데이터를 내놓습니다. 네이티브 P2WPKH는 세그윗(SegWit) v0 증인 프로그램에 20바이트 공개키 해시를 두고, 서명과 공개키는 증인(witness) 영역에 넣습니다. 주소 접두사만 비교하기보다 출력 스크립트가 무엇의 해시를 약속했는지, 지출 데이터가 어디에 들어가는지를 봐야 합니다.
출력은 앞으로의 입력이 증명할 대상을 정해 둡니다
비트코인 잔액은 주소별 계정에 쌓이는 것이 아니라 UTXO의 금액과 scriptPubKey에 들어 있습니다. 주소는 지갑이 특정 표준 출력 스크립트를 주고받기 쉽게 인코딩한 표현일 뿐입니다. P2PKH·P2SH는 Base58Check를, 네이티브 세그윗은 Bech32 계열을 쓰지만 검증 노드가 실행하는 것은 디코딩된 스크립트입니다.
메인넷에서 흔히 1로 시작하는 주소는 P2PKH, 3은 P2SH, bc1q는 증인 v0 계열일 수 있습니다. 하지만 접두사만으로 실제 내부 조건을 다 알 수는 없습니다. 특히 P2SH는 멀티시그나 중첩 세그윗처럼 다양한 redeemScript를 감쌀 수 있습니다.
주소는 받는 사람이 제안한 출력 틀을 인코딩한 것입니다. 실제 잠금 조건은 거래 출력에 담긴 scriptPubKey입니다.
JOBCOIN 해설

그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 출력은 앞으로의 입력이 증명할 대상을 정해 둡니다
비트코인 잔액은 주소별 계정에 쌓이는 것이 아니라 UTXO의 금액과 scriptPubKey에 들어 있습니다.
- P2PKH는 공개키 해시를 맞춰 봅니다
P2PKH의 scriptPubKey는 OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG 형태입니다.
- P2SH는 조건의 해시부터 확인합니다
P2SH 출력은 OP_HASH160 <ScriptHash> OP_EQUAL로 짧습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
P2PKH는 공개키 해시를 맞춰 봅니다
P2PKH의 scriptPubKey는 OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG 형태입니다. 지출 입력의 scriptSig가 서명과 공개키를 내놓으면, 노드는 그 공개키의 HASH160이 출력에 적힌 값과 같은지 확인한 뒤 그 공개키로 거래 서명을 검증합니다.
공개키는 UTXO가 만들어질 때는 드러나지 않고, 처음 지출할 때 공개됩니다. 같은 주소를 다시 쓰면 한 번 공개된 키 해시와 여러 결제 관계가 서로 이어집니다. 주소 재사용을 피하는 일은 양자 공격 같은 가정 때문만이 아니라, 지금 당장의 거래 관계 프라이버시에도 중요합니다.
| 유형 | 잠그는 대상 | 지출 데이터 위치 |
|---|---|---|
| P2PKH | HASH160(pubkey) | scriptSig: 서명·공개키 |
| P2SH | HASH160(redeemScript) | scriptSig: 인수·redeemScript |
| P2WPKH | v0 + HASH160(pubkey) | 증인: 서명·공개키 |
| P2SH-P2WPKH | HASH160(witness program) | scriptSig+ 증인 |
| P2TR | v1 + x좌표 전용 출력 키 | 증인: 키 경로 또는 스크립트 경로 |
P2SH는 조건의 해시부터 확인합니다
P2SH 출력은 OP_HASH160 <ScriptHash> OP_EQUAL로 짧습니다. 지출하는 쪽은 scriptSig 맨 끝에 직렬화한 redeemScript를 공개하고, 노드는 그 HASH160이 출력과 같은지 확인한 다음 나머지 스택 항목으로 redeemScript를 실행합니다. 돈을 보내는 사람은 복잡한 멀티시그 조건 전체를 알 필요 없이 스크립트 해시만 받으면 됩니다.
P2SH 자체가 멀티시그를 뜻하지는 않습니다. 2-of-3 멀티시그가 흔한 쓰임새였지만, 허용되는 redeemScript라면 무엇이든 넣을 수 있고 P2WPKH·P2WSH 증인 프로그램을 감싸는 중첩 세그윗에도 쓰입니다. 주소가 3으로 시작한다는 이유만으로 서명자 수를 짐작하지 않습니다.
- 주소를 해당 네트워크 규칙에 맞게 디코딩합니다.
- scriptPubKey의 옵코드와 프로그램 길이를 봅니다.
- P2SH라면 redeemScript가 언제 공개되는지 확인합니다.
- 증인 데이터가 있으면 버전과 프로그램을 확인합니다.
- 예상 가상 바이트와 수수료를 실제 입력 유형으로 계산합니다.
P2WPKH는 서명 데이터를 증인 영역으로 떼어 냅니다
P2WPKH의 scriptPubKey는 증인 version 0과 20바이트 키 해시로 이뤄집니다. 네이티브 지출의 scriptSig는 비어 있고, 증인 스택에 서명과 압축 공개키가 들어갑니다. 노드는 이 프로그램을 미리 정해진 P2PKH 비슷한 조건으로 해석하며, BIP143 방식의 서명 해시에 이전 출력의 금액을 포함합니다.
세그윗은 증인 데이터를 txid 계산에서 떼어 내 제3자가 거래를 변조할 여지를 줄이고, 무게 할인을 통해 같은 논리의 지출을 더 적은 수수료로 처리하게 합니다. 그렇다고 ‘증인 데이터는 검증하지 않는다’는 뜻은 아닙니다. 블록 무게와 wtxid에는 반영되고, 합의 규칙에 따라 서명도 검사합니다.
어떤 형식을 쓸지는 받는 쪽과 지갑 기능에 달려 있습니다
오래된 송금 시스템이 bc1 주소를 거부하는 경우가 있어, 전환기에는 중첩형 P2SH-P2WPKH가 쓰였습니다. 요즘 지갑끼리는 네이티브 세그윗이 더 단순하고 효율적일 수 있지만, 상대 서비스가 그 입금 형식과 네트워크를 지원하는지 확인해야 합니다. 주소를 다른 체인에 다시 쓰지 않습니다.
개발자는 출력 디스크립터로 스크립트 유형과 키 파생 경로를 밝혀 두고, 테스트 벡터로 주소와 스크립트 변환을 검증하는 편이 안전합니다. 화면에는 ‘Legacy’, ‘Nested SegWit’, ‘Native SegWit’ 같은 이름표뿐 아니라 예상 수수료와 호환성 이유도 보여 줘서, 사용자가 이름만 보고 보안 등급을 오해하지 않게 해야 합니다.
자주 묻는 질문
3으로 시작하는 주소는 모두 멀티시그인가요?
아닙니다. P2SH는 redeemScript 해시를 인코딩한 것이며, 멀티시그뿐 아니라 중첩 세그윗 같은 여러 조건을 담을 수 있습니다.
P2WPKH는 공개키 해시를 쓰지 않나요?
씁니다. 20바이트 HASH160(pubkey)를 증인 v0 프로그램에 넣고, 서명과 공개키는 증인 영역에 둡니다.
세그윗의 증인 데이터는 서명 검증에서 빠지나요?
아닙니다. txid 계산과 무게 처리 방식이 다를 뿐, 합의 규칙이 증인 속 서명을 검증합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.



