Bitcoin Script는 지출 조건을 표현하는 언어입니다. 거래의 각 출력, 즉 다음 사용 조건이 붙은 금액에는 그 조건이 담겨 있습니다. 이를 사용하려는 사람은 조건을 충족해야 합니다. Script는 이 거래가 바로 이 자금을 사용해도 되는지라는 간단한 질문에 답하는 데 쓰입니다.
Alice가 20 000 sat, 즉 비트코인의 최소 단위로 이만 단위를 받습니다. 네트워크가 Alice 명의의 계좌를 만드는 것은 아닙니다. 거래 출력, 곧 금액과 나중에 사용할 조건이 만들어집니다. 아직 사용하지 않은 출력을 UTXO라고 합니다. 일반적인 결제에서는 해당 키로 만든 서명을 요구합니다. Alice가 나중에 결제할 때 지갑은 이 출력을 선택하고, 새 거래의 입력에서 이를 가리키며 디지털 서명을 만듭니다. 개인 키를 사용하지만 그 키를 어디에도 보내지 않습니다. 다른 사람들은 공개 키로 서명을 검증합니다. Alice의 수신 주소를 아는 것만으로는 충분하지 않습니다. 원래 출력의 조건은 scriptPubKey 필드에 기록되며, Bitcoin Script는 조건 충족 여부를 확인하는 방법을 정합니다. 노드는 Alice를 알아보는 직원이 아니라 규칙을 검사하는 컴퓨터입니다. 서명뿐 아니라 같은 출력이 이미 사용되었는지도 확인해야 합니다. 적용되는 모든 규칙을 충족해야 거래가 유효합니다. [4] [2]
일반적인 결제의 조건은 지갑이 구성합니다. 지갑의 안내에 따라 백업하세요. 호환되는 지갑에서 백업 단어로 정상 복원한다고 해서 모든 스크립트를 수동으로 저장해야 하는 것은 아닙니다. 하지만 여러 서명이 필요한 Multisig처럼 복잡한 구성에서는 한 참여자의 단어만으로 전체 지출 방식을 설명하지 못할 수 있습니다. 일상적인 사용에는 스크립트를 십육진수로 직접 구성하기보다 검증된 절차를 사용하는 지갑이 적합합니다. 출력 디스크립터는 스크립트 유형, 키, 키의 파생 방법을 설명하여 복원한 지갑이 무엇을 찾아야 하는지 정하는 데 도움을 줍니다. 복잡한 구성을 복원할 때는 개인 키만으로 충분하지 않을 수 있습니다. 필요한 스크립트와 키가 어디서 어떻게 파생되었는지를 나타내는 키 출처 정보도 보관하고, 의도한 지출 경로를 검증해야 합니다. [11]
다음 장에서는 거래 내부에 조건을 기록하는 방식을 살펴봅니다. 일상적인 결제를 위해 반드시 알아야 하는 내용은 아닙니다. scriptSig 필드와 witness라는 부분이 검증 데이터를 제공합니다. 해시는 데이터의 지문이며, 시간 잠금은 정해진 경계 이전의 사용을 막습니다. 스택은 위에서부터 넣고 빼는 데이터 더미라고 생각하면 됩니다. Script는 스택을 통해 데이터를 처리합니다. 값을 스택에 넣으면, 옵코드라고 부르는 명령이 값을 꺼내거나 비교하거나 다른 방식으로 처리합니다. 서명 명령은 서명을 검증합니다. 이 검증 과정에서는 개인 키를 사용하거나 서명을 생성하지 않습니다. 이 언어는 서명, 해시 조건, 시간 잠금을 조합할 수 있지만 일반적인 반복문은 없으며 튜링 완전하지 않습니다. 즉, 범용 프로그래밍 언어로 표현할 수 있는 모든 계산을 표현할 수는 없습니다. 노드는 해당 출력 유형과 스크립트 버전에 맞는 정확한 규칙을 적용해야 합니다. [1] [3]
P2PKH (Pay to Public Key Hash) 출력은 보통 OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG 형태입니다. 입력은 scriptSig에 서명과 공개 키를 제공합니다. 검증 과정에서는 공개 키의 해시가 출력에 있는 값과 일치하는지 확인한 다음 서명을 검증합니다. 따라서 주소나 공개 키를 알고 있다는 것만으로는 이런 출력을 사용할 수 없습니다. 개인 키를 사용하는 쪽은 서명하는 지갑이며, 거래를 검사하는 노드가 아닙니다. [1]
P2SH는 BIP16에 따라 출력에 스크립트의 해시를 저장합니다. 그 출력을 사용하는 입력은 사용할 때 공개하는 스크립트인 올바른 redeemScript와 필요한 데이터를 함께 제공합니다. scriptSig에는 데이터를 스택에 넣는 명령만 들어갈 수 있습니다. 노드는 먼저 해시가 일치하는지 확인하고, 스택에 남아 있는 항목으로 redeemScript를 평가합니다. 해시가 맞는 것만으로는 충분하지 않으며, 스크립트의 조건도 충족해야 합니다. [5]
SegWit 버전 0에서는 검증 데이터가 거래의 witness라는 부분으로 옮겨집니다. 이는 데이터 항목의 목록이며, 그 자체가 스크립트는 아닙니다. P2WPKH는 서명과 공개 키를 사용합니다. P2WSH에는 witnessScript도 포함되며, 그 SHA256 해시가 출력과 일치해야 합니다. 네이티브 SegWit에서는 scriptSig가 비어 있습니다. P2SH로 감싸는 경우 scriptSig에는 해당 witness 프로그램을 넣는 명령만 들어가며, 실제 검증 데이터는 witness에 남습니다. [6]
서명 검증은 정해진 절차에 따라 거래에서 도출한 메시지를 대상으로 합니다. SIGHASH 방식은 거래의 어느 부분을 서명이 변경으로부터 보호하는지 정합니다. 따라서 모든 서명이 거래 전체를 빠짐없이 보호한다고 단정할 수는 없습니다. BIP143은 SegWit 버전 0의 서명 연산에 지출하려는 출력의 금액을 항상 포함합니다. 지갑은 올바른 데이터와 선택한 방식을 알아야 하며, Script는 검증하면서 서명자의 실제 의도까지 판단하지 않습니다. [7]
BIP341에 따른 Taproot는 P2TR (Pay to Taproot) 출력을 사용하는 두 가지 방법을 제공합니다. 키 경로는 스크립트를 공개하지 않고 출력 공개 키를 기준으로 Schnorr 서명을 검증합니다. 반대로 스크립트 경로는 선택한 스크립트와 제어 블록인 control block을 공개하여, 그 스크립트가 출력과 연결되어 있음을 증명합니다. 트리의 다른 스크립트는 공개하지 않아도 됩니다. 공개한 스크립트의 규칙은 해당 리프의 버전에도 달려 있습니다. [8]
BIP342는 버전 0xc0인 Taproot 리프에 사용할 Tapscript를 정의합니다. 여기서 서명 명령은 Schnorr 서명을 사용하며, OP_CHECKSIGADD로 여러 서명을 요구하는 조건을 구성할 수 있습니다. 기존 OP_CHECKMULTISIG를 실행하면 스크립트 검증이 실패합니다. 이전의 스크립트 길이 한도인 10 000바이트와 옛 규칙으로 세는 201개 옵코드 한도는 여기에는 적용되지 않습니다. 서명 연산 횟수는 witness 크기에서 계산한 예산으로 제한되며, 스택 한도는 계속 존재합니다. 따라서 한 버전의 제한을 Script 전체의 공통 특성으로 설명해서는 안 됩니다. [9]
합의 규칙은 블록 안에서 지출이 유효한지를 정합니다. 거래의 표준성이란 미확인 거래를 Mempool에 받아들이고 다른 노드에 전달하기 위해 각 노드가 적용하는 추가적인 로컬 규칙이며, 표준을 만드는 과정이 아닙니다. 따라서 합의상 유효한 거래라도 일반적으로 전달되지 않을 수 있습니다. Tapscript의 OP_SUCCESSx는 특히 주의해야 합니다. 앞선 검사에 성공한 뒤 디코딩 중 이를 인식하면, 일반적인 실행과 스택 검사에 앞서 스크립트 검증이 성공으로 종료됩니다. 이는 향후 확장을 위해 마련한 여지이지, 일반적으로 안전한 지출 조건이 아닙니다. [10] [9]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 트랜잭션, Multisig, Timelock, Taproot. 다음 항목에서도 이 글을 참조합니다 Hash, SHA-256, 합의 규칙, Timelock.