서명 스크립트

트랜잭션의 모든 입력은 이전 출력을 가리키며, 자신이 그것을 사용할 권한이 있음을 증명해야 합니다. Bitcoin Core는 이 필드를 scriptSig라고 부릅니다. 레거시 pay-to-public-key-hash 입력에서는 71바이트 또는 72바이트 서명과 33바이트 공개 키를 담으며, 대략 107바이트입니다. SegWit 이후에는 그 증명이 보통 다른 곳에 위치하며, bech32 출금 비용이 더 적게 드는 이유의 대부분이 여기에 있습니다.

작동 방식

서명 스크립트가 먼저 실행되어 그 결과를 스택에 남기고, 출력의 스크립트가 이를 소비합니다. 둘은 하나로 이어진 프로그램으로 실행되지 않습니다. 스택을 넘겨받으며 순서대로 실행되는데, 이 분리는 원래 설계가 악용 가능함이 드러난 뒤 2010년에 도입되었습니다.

릴레이 정책은 이 필드가 데이터 푸시 외에는 아무것도 담지 않도록 요구합니다. 조건문도, 산술 연산도, 어떤 작업을 수행하는 옵코드도 없습니다. 이 제한이 존재하는 이유는 사용자가 이 바이트를 완전히 통제하기 때문이며, 공격자가 진입 시점에 로직을 실행하도록 허용하면 네트워크가 오래전에 닫은 문제가 다시 열립니다. pay-to-script-hash는 상환 스크립트가 마지막 단순 푸시로 도착해야 하므로, 이 규칙을 선호 사항이 아니라 합의 요건으로 만듭니다.

그 크기는 전적으로 무엇을 잠금 해제하는지에 달려 있습니다. 레거시 단일 키 입력은 서명과 키를 담습니다. 중첩 SegWit 입력은 정확히 23바이트를 담는데, 22바이트 위트니스 프로그램을 담은 단일 푸시이며, 나머지 전부를 위트니스로 넘깁니다. 네이티브 bech32 또는 bech32m 입력은 아무것도 담지 않습니다. 직렬화된 필드는 길이 0인 단일 바이트입니다.

서명 스크립트가 아무것도 증명하지 않는 입력이 하나 있습니다. 코인베이스 트랜잭션의 유일한 입력은 잠금 해제할 이전 출력이 없으므로, 이 필드는 2바이트에서 100바이트 사이의 여유 공간으로 용도가 바뀌었고, BIP-34 이후에는 블록 높이로 시작해야 합니다. 채굴업자들은 2009년부터 그곳에 메시지, 투표, 농담을 서명해 왔습니다.

확인하는 곳

아무 트랜잭션이나 디코딩하면 각 입력에 어셈블리 보기와 16진수 보기가 있는 scriptSig 객체가 표시됩니다. 네이티브 SegWit 또는 Taproot 입력에서는 둘 다 빈 문자열이고 별도의 위트니스 필드가 데이터를 담으며, 이 시각적 비대칭은 오래된 트랜잭션이 어떤 주소 형식을 사용했는지 한눈에 구별하는 가장 빠른 방법입니다.

이는 널리 오해되는 역사적 사건 하나도 설명합니다. scriptSig가 트랜잭션 ID 계산에 포함되었기 때문에, 제3자가 서명을 무효화하지 않고 다시 인코딩하여 이미 브로드캐스트된 트랜잭션의 ID를 바꿀 수 있었습니다. Mt. Gox는 2014년 2월에 출금을 중단하며 바로 이 동작을 탓했지만, 이후 체인에 대한 학술 분석에서는 변조된 트랜잭션의 규모가 사라진 코인을 설명하기에는 너무 작았음을 발견했습니다. SegWit은 잠금 해제 데이터를 ID 계산에서 완전히 빼냄으로써 2017년 8월에 그 논쟁을 끝냈습니다.

서명 스크립트 vs 위트니스 데이터

서명 스크립트와 위트니스 데이터는 같은 종류의 증명을 담으며, SegWit은 서명의 의미를 바꾸지 않고 그 역할을 하나에서 다른 곳으로 옮겼습니다. 이용자에게 중요한 차이는 비용과 영속성입니다. 위트니스 바이트는 각각 1 가중치 단위로 청구되는 반면 서명 스크립트 바이트는 4로 청구되므로, 동일한 단일 키 지출은 증명이 scriptSig에 실리면 대략 148 가상 바이트이고 위트니스에 실리면 대략 68 가상 바이트입니다. 위트니스 데이터는 또한 트랜잭션 ID 밖에 있어, 지출의 식별자가 전송 중에 변경될 수 없습니다. 레거시 입력은 여전히 옛 필드를 사용하며, 이런 이유로 1로 시작하는 주소에 보관된 코인은 옮길 때마다 조용히 더 많은 비용이 듭니다.