Pubkey 스크립트

비트코인은 주소에 보관되지 않습니다. 비트코인은 출력에 존재하며, 각 출력은 Pubkey 스크립트로 보호됩니다. Bitcoin Core는 해당 필드를 scriptPubKey라고 부르며, 일반적인 현대 출력에서 이 필드의 길이는 22바이트 또는 34바이트입니다. 누군가에게 주소를 알려준다는 것은 그 사람의 지갑이 작성할 Pubkey 스크립트의 조리법을 건네주는 것입니다.

작동 방식

직렬화된 트랜잭션의 각 출력은 세 가지가 연달아 이어집니다: 사토시 단위의 값 8바이트, 길이 접두사, 그리고 Pubkey 스크립트 자체입니다. 출력 안에는 수령인을 지칭하는 것이 없습니다. 스크립트가 곧 수령인이며, 주소는 그 안에 담긴 몇 바이트를 체크섬과 함께 인코딩한 것에 불과합니다.

오늘날 체인상의 거의 모든 것을 다섯 가지 템플릿이 설명합니다. 레거시 pay-to-public-key-hash 잠금은 25바이트를 차지하며 20바이트 해시를 둘러싼 네 개의 opcode를 지칭합니다. pay-to-script-hash 잠금은 23바이트이며 OP_EQUAL로 끝납니다. 네이티브 SegWit은 그에 비해 의도적으로 단순합니다: 버전 바이트 뒤에 단일 푸시가 오며, 단일 키에는 22바이트, 스크립트 해시에는 34바이트이고, 출력에는 아무런 로직도 없습니다. Taproot 역시 34바이트로, 버전 바이트와 32바이트 키입니다.

릴레이 정책은 이 짧은 목록만 인식하고 그 밖의 것은 전달하지 않으며, 그래서 직접 출력 형식을 만들어 내고 지갑이 그 형식으로 지급하기를 기대할 수 없습니다. 이 점에서 합의 규칙은 정책보다 느슨하지만, 실제 효과는 다섯 가지 템플릿이 전부라는 것입니다.

이 이름은 화석입니다. 초기 트랜잭션에서 스크립트에는 실제로 공개 키가 들어 있었습니다: 제네시스 블록의 코인베이스 출력은 67바이트이며, 압축되지 않은 65바이트 키 뒤에 OP_CHECKSIG가 옵니다. 이는 Bitcoin Core 자체의 소스에서 읽을 수 있습니다. 키 대신 해시로 지급하는 방식이 2011년에 표준이 되었고, 오늘날 대부분의 Pubkey 스크립트에는 공개 키가 전혀 들어 있지 않으며 그 키에 대한 커밋먼트만 들어 있습니다.

확인할 수 있는 곳

아무 노드에 원시 트랜잭션의 디코딩을 요청하면 모든 출력에 네 개의 필드를 가진 scriptPubKey 객체가 붙습니다: 사람이 읽을 수 있는 어셈블리, 원시 16진수, 유형 문자열, 그리고 그 유형이 대응하는 주소입니다. 블록 탐색기도 같은 것을 보여 주며, 보통 잠금 스크립트 또는 출력 스크립트로 이름이 바뀌어 표시됩니다.

지갑의 조회 전용 설정도 여기에 있습니다. 주소를 가져온다는 것은 소프트웨어에 체인에서 어떤 Pubkey 스크립트를 검색할지 알려주는 것이며, 그래서 키 하나가 만들어 낼 수 있는 스크립트 전체 계열을 생성하는 정의인 디스크립터가 본격적인 도구에서 주소별 가져오기를 대체했습니다.

실제로 필요한 읽기 능력은 짧습니다. 스크립트가 0으로 시작하고 20바이트를 담고 있다면, 누군가가 서명 하나와 값싼 입력으로 그것을 사용할 것입니다. 32바이트를 담고 있다면 그 뒤에 보이지 않는 계약이 있습니다. 1로 시작하고 32바이트를 담고 있다면 그것은 Taproot이며, 단일 키일 수도 있고 같은 얼굴을 한 조건 트리 전체일 수도 있습니다.

Pubkey 스크립트 vs 서명 스크립트

Pubkey 스크립트는 질문을 정하고 서명 스크립트는 그 질문에 답하려 시도하며, 두 스크립트는 서로 다른 사람이 서로 다른 시점에 작성합니다. 돈을 보내는 사람은 사용자가 알려준 주소를 바탕으로 Pubkey 스크립트를 작성하고 그 바이트 값을 지불합니다. 서명 스크립트는 나중에 사용할 때 본인이 작성하고 그 바이트 값을 본인이 지불합니다. 그래서 Taproot 주소로 보내는 것은 레거시 주소로 보내는 것보다 발신자에게 조금 더 비싸지만, 나중에 코인을 옮길 때 본인에게는 훨씬 더 많은 비용을 아껴 줍니다. 또한 두 스크립트는 하나로 합쳐진 프로그램이 아니라 따로 실행되며, 이는 원래의 결합 실행이 악용 가능하다는 것이 드러난 뒤 2010년에 이루어진 변경입니다.