Opcode

안나가 피터에게 돈을 보내려 합니다. 지갑은 거래와 필요한 서명을 만들고, 노드는 안나가 선택한 코인을 쓸 수 있었는지 확인합니다. 지갑은 비트코인을 받고 보내는 앱이나 기기입니다. 노드는 거래와 블록을 검증하고 네트워크의 다른 참여자와 통신하는 소프트웨어입니다. Bitcoin Script는 그 검사의 일부를 표현하는 언어입니다. Opcode는 서명 검사 같은 한 단계입니다. 일반 결제에서 안나가 명령을 직접 작성하지는 않습니다. 그러나 노드는 소유자 이름이나 “서명됨” 표시를 믿을 수 없으므로 실제 조건을 평가해야 합니다. 유효한 스크립트는 거래 전체 검증의 일부일 뿐입니다. [1] [4]

읽기 쉬운 표시에는 OP_DUP나 OP_CHECKSIG가 나옵니다. 사람을 위한 명령 이름이며 실제 스크립트에서는 한 바이트 코드로 표현됩니다. 바이트는 데이터의 양을 나타내는 일반적인 단위입니다. 다른 부분에는 공개키 같은 데이터가 있습니다. 공개 키는 서명을 검증하는 데 사용하며 비밀로 유지할 필요가 없습니다. OP_PUSHDATA 계열 명령은 뒤따르는 몇 바이트를 데이터로 넣을지 정합니다. 넣은 데이터 안의 바이트를 다시 명령으로 실행하지는 않습니다. 요리법의 “소금을 넣으세요”와 실제 그릇에 넣는 재료의 차이를 생각하면 됩니다. [1] [2]

맨 위의 쪽지를 꺼내는 쪽지 더미를 생각해 보세요. 스크립트의 기본 작업 스택도 이렇게 움직입니다. OP_DUP는 맨 위 항목을 복사하고, OP_DROP은 맨 위 항목을 제거합니다. 비어 있지 않은 스택에 OP_DUP를 실행한 뒤 OP_DROP을 실행하면 내용이 원래대로 돌아옵니다. 코인을 늘린 것이 아니라 작업 데이터를 복사했을 뿐입니다. 필요한 항목이 없으면 평가가 실패할 수 있습니다. 순서와 정확한 인코딩도 중요합니다. [1]

OP_EQUAL은 위의 두 항목을 꺼내 바이트를 비교하고 그 결과로 바꿉니다. OP_EQUALVERIFY는 다르면 즉시 실패하며, 같으면 결과를 스택에 남기지 않고 계속합니다. 어느 쪽도 그 자체로 서명을 확인하지 않습니다. 누구나 같은 공개키 두 개를 제출할 수 있습니다. 필요한 메시지에 서명할 수 있었음을 입증하려면 알맞은 서명 검사가 필요합니다. [1] [4]

OP_CHECKSIG는 공개키와 거래로 구성한 메시지에 대해 서명을 검증하며 개인키를 공개하지 않습니다. 개인 키는 이러한 서명을 만드는 데 사용하는 비밀 숫자 값입니다. sighash 설정은 서명이 거래의 어느 부분을 다루는지 정합니다. 모든 모드가 전부에 서명하는 것은 아닙니다. 기존 스크립트와 SegWit 버전 0은 서명 알고리즘 ECDSA를 사용합니다. Taproot의 스크립트 규칙인 Tapscript는 일반적인 32바이트 키에 다른 알고리즘 Schnorr를 사용합니다. 이런 맥락 없이 명령 이름만으로는 충분하지 않습니다. [1] [3]

조건은 일반적인 지출이나 대체 복구 경로를 허용할 수 있습니다. OP_IF와 OP_ELSE는 스택 값으로 분기를 고르고, OP_ENDIF는 조건 부분을 닫습니다. Bitcoin Script에는 임의로 반복하는 일반적인 프로그램 루프가 없습니다. 그렇다고 실행하지 않는 분기의 모든 것을 무시할 수는 없습니다. 일부 명령은 스크립트를 읽을 때 검사하므로 명령 종류와 규칙 버전이 중요합니다. [1] [3]

CLTV인 OP_CHECKLOCKTIMEVERIFY는 체인에서 블록의 위치를 나타내는 블록 높이 같은 절대 기준을 강제할 수 있습니다. CSV인 OP_CHECKSEQUENCEVERIFY는 거래의 경과 기간 규칙과 함께, 쓰려는 출력이 확인된 때부터 상대적인 지연을 요구합니다. 출력은 이전에 받은 금액과 지출 조건의 기록입니다. 이 명령들은 거래 필드를 검사할 뿐, 타이머를 켜거나 돈을 보내거나 서명을 대신하지 않습니다. 실제 용도에 맞는 시간 잠금을 다른 조건과 조합해야 합니다. [7] [8] [9]

기술 예시를 읽기 전에 기존 스크립트, SegWit, Tapscript 중 무엇을 쓰는지 확인하세요. Tapscript는 서명 검사를 조합하는 OP_CHECKSIGADD를 추가합니다. 반면 OP_CHECKMULTISIG는 실행하면 실패하고 실행하지 않는 분기에서는 해당 규칙에 따라 무시됩니다. 이름이 모순되는 것이 아니라 검증 환경이 다릅니다. Opcode 목록은 별다른 고려 없이 형식 사이에서 옮겨 쓸 수 있는 만능 부품 상자가 아닙니다. [1] [3] [6]

BIP 342는 향후 Tapscript 확장을 위해 OP_SUCCESSx 계열을 예약합니다. 앞선 검사를 통과한 뒤 디코딩 중 해당 명령을 만나면, 실행하지 않는 분기에 있더라도 이후 스크립트 검사를 건너뛰고 성공합니다. 넣은 데이터 안에 우연히 같은 바이트가 있는 경우는 해당하지 않습니다. 규칙 변경을 위한 여지이지 이미 활성화된 새 보호 장치가 아닙니다. 아직 정의되지 않은 미래의 의미에 의존하는 조건은 작성자의 기대대로 자금을 지키지 못할 수 있습니다. [1] [3]

Full Node는 유효성 규칙을 독립적으로 검사하지만, 미확인 거래를 받아 공유할 때는 더 엄격한 규칙을 적용할 수 있습니다. 예를 들어 Bitcoin Core v29.0은 기본 설정에서 Tapscript 안에 OP_SUCCESSx 명령을 사용하는 거래의 중계를 거부합니다. 합의 규칙상 블록에 허용될 수 있어도 그렇습니다. 예시를 읽을 때는 버전, 초기 데이터, 서명 범위, 실패 조건을 확인하세요. 읽기 좋은 문법만으로 안전한 지갑이라고 할 수는 없습니다. 일반 사용에서는 검토된 소프트웨어에 이 작업을 맡깁니다. [1] [5]