비트코인 Script는 UTXO를 만든 출력의 scriptPubKey와 이를 쓰는 입력의 scriptSig 또는 witness 데이터를 정해진 규칙으로 평가해 최종 조건이 참인지 확인합니다. 전통적 P2PKH에서는 서명과 공개키를 스택에 넣고 공개키의 HASH160이 출력에 고정된 해시와 같은지 검사한 뒤 OP_CHECKSIG가 현재 거래의 서명 해시와 공개키로 서명을 검증합니다. 단순히 마지막 스택 값만 참이면 되는 일반 설명에는 P2SH·SegWit·Taproot의 별도 검증 규칙과 정책 플래그라는 조건이 빠져 있습니다.
지출 조건은 이전 출력에 들어 있습니다
Bitcoin 거래 입력은 임의 잔액을 직접 가리키지 않고 이전 transaction의 txid와 output index로 UTXO를 참조합니다. 그 출력의 scriptPubKey가 돈을 쓰기 위한 조건을 정의하고, 새 입력은 scriptSig나 witness에 조건을 만족할 데이터와 서명을 제공합니다. 검증 노드는 참조된 출력 금액과 script까지 가져와 전체 거래 맥락에서 평가합니다.
Bitcoin Developer Guide는 Script를 상태가 없고 반복문이 없는 Forth 계열 stack 언어로 설명합니다. opcode는 위에서부터 값을 꺼내 계산하고 결과를 다시 넣습니다. 네트워크 전체 상태를 임의로 읽는 스마트 계약 VM과 다르며, 서명이 커밋하는 거래 필드와 UTXO 데이터가 실행의 핵심 맥락입니다.
Bitcoin Script는 돈을 보내는 프로그램이 아니라, 특정 UTXO를 지금 이 입력이 써도 되는지 판정하는 조건식입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 지출 조건은 이전 출력에 들어 있습니다
Bitcoin 거래 입력은 임의 잔액을 직접 가리키지 않고 이전 transaction의 txid와 output index 로 UTXO를 참조합니다.
- P2PKH 스택을 한 단계씩 따라갑니다
P2PKH의 입력은 먼저 signature와 public key를 push합니다.
- 서명은 현재 거래의 선택된 부분에 묶입니다
OP_CHECKSIG가 검증하는 message는 화면에 보이는 txid 문자열이 아닙니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
P2PKH 스택을 한 단계씩 따라갑니다
P2PKH의 입력은 먼저 signature와 public key를 push합니다. OP_DUP는 공개키를 복제하고 OP_HASH160은 복제본에 SHA-256 뒤 RIPEMD-160을 적용합니다. 출력에 있던 expected pubkey hash가 이어서 push되고 OP_EQUALVERIFY가 두 해시가 같은지 확인합니다. 다르면 즉시 실패합니다.
해시가 같으면 stack에는 signature와 public key가 남습니다. OP_CHECKSIG는 서명 끝의 sighash type과 거래 데이터를 이용해 서명 대상 digest를 만들고 secp256k1 공개키로 검증합니다. 성공하면 true가 남고 실패하면 false가 남습니다. 서명 바이트만 올바른지 보는 것이 아니라 어떤 transaction 부분에 서명했는지도 중요합니다.
| 단계 | 스택 동작 | 실패 조건 |
|---|---|---|
| 데이터 push | signature·pubkey 추가 | 인코딩 규칙 위반 |
| OP_DUP | pubkey 복제 | 스택 부족 |
| OP_HASH160 | pubkey hash 계산 | 유효한 데이터 필요 |
| OP_EQUALVERIFY | expected hash 비교 | 해시 불일치 |
| OP_CHECKSIG | 거래 서명 검증 | 서명·digest 불일치 |
서명은 현재 거래의 선택된 부분에 묶입니다
OP_CHECKSIG가 검증하는 message는 화면에 보이는 txid 문자열이 아닙니다. input별 scriptCode와 amount, version, inputs, outputs, locktime 중 sighash 규칙이 선택한 부분을 serialization하고 hash한 값입니다. Legacy, SegWit v0, Taproot는 서명 해시 구성 규칙이 서로 다릅니다.
따라서 같은 DER signature를 다른 input이나 금액에 그대로 붙인다고 일반적으로 유효하지 않습니다. SIGHASH_NONE·SINGLE·ANYONECANPAY 같은 플래그는 커밋 범위를 바꾸므로 wallet은 서명자가 허용한 변경 범위를 명확히 보여 줘야 합니다. OP_CHECKSIG 성공만으로 수신 주소 의도가 안전했다는 뜻도 아닙니다.
- 참조 UTXO의 txid·vout을 확인합니다.
- scriptPubKey 유형과 witness version을 식별합니다.
- 입력 stack 항목과 인코딩을 확인합니다.
- sighash type과 커밋 범위를 확인합니다.
- consensus·policy 결과를 별도로 기록합니다.
P2SH와 SegWit은 추가 검증 단계를 둡니다
P2SH 출력은 redeemScript의 HASH160을 잠급니다. 입력이 제공한 전체 redeemScript가 약속된 해시와 같은지 먼저 검사한 뒤 그 script를 실제 조건으로 다시 실행합니다. P2WPKH는 scriptSig 대신 witness에 signature와 pubkey를 두고 20바이트 witness program을 P2PKH와 유사한 scriptCode로 해석합니다.
Taproot의 key path는 한 개 Schnorr signature를 output key로 검증하고 script path는 tapscript와 control block으로 약속된 Merkle root를 재구성합니다. 모든 주소 형식을 ‘scriptSig와 scriptPubKey를 단순 연결’한다고 설명하면 최신 witness 규칙을 놓칩니다. output type을 먼저 식별해야 합니다.
유효성과 중계 가능성은 같지 않습니다
Consensus rule을 만족하면 block 안에서 유효할 수 있지만 각 node의 mempool은 IsStandard와 fee·size 정책으로 거래를 중계하지 않을 수 있습니다. Developer Guide도 non-standard transaction이 기본 node에서 relay되지 않아도 miner가 block에 넣으면 consensus 검증을 통과할 수 있음을 설명합니다.
디버깅에서는 script error, consensus flag, mempool rejection reason을 나눕니다. regtest에서 통과한 custom script가 public network에서 자동 전파된다고 가정하지 않습니다. 실제 배포 전에는 목표 Bitcoin Core 버전의 testmempoolaccept와 raw transaction decode 결과를 함께 보관합니다.
자주 묻는 질문
P2PKH는 scriptSig와 scriptPubKey를 항상 단순 연결하나요?
전통 P2PKH 설명에는 유용하지만 P2SH·SegWit·Taproot는 별도 평가 규칙이 있으므로 output type을 먼저 확인해야 합니다.
OP_CHECKSIG는 txid에 서명하나요?
아닙니다. 해당 sighash 알고리즘이 선택한 거래 필드를 직렬화해 만든 digest를 검증합니다.
Script가 참이면 모든 노드가 mempool에 받아 주나요?
아닙니다. consensus 유효성과 표준 중계·mempool 정책은 별개입니다.
