RPC 바이트 순서

지갑이 트랜잭션 ID라고 부르는 64자 문자열은 그 바이트가 다른 어디에서도 취하는 순서가 아닙니다. Bitcoin Core는 해시를 최상위 바이트부터 인쇄하는 타입에 보관하고, 모든 탐색기가 그 습관을 따라 했으며, 이 관례는 이제 영구적입니다. 식별자를 검색창에 붙여 넣을 때는 무해하고, 코드에 붙여 넣을 때는 비용이 큽니다.

작동 방식

RPC 바이트 순서는 노드에서 나오는 길에 적용되는 표시 변환이며, 다른 해시가 아닙니다.

다이제스트는 SHA-256에서 고유한 방향이 없는 32바이트로 나옵니다. Bitcoin Core는 이를 그 바이트들을 하나의 매우 큰 수로 모델링하는 컨테이너에 보관하고, 수를 인쇄하면 최상위 부분이 왼쪽에 오므로 배열이 뒤집힙니다. 블록이나 트랜잭션을 지칭하는 모든 JSON 필드가 그렇게 나옵니다: getblockhash의 해시, getrawtransaction의 txid, getblock의 merkleroot, 블록을 부모 블록과 연결하는 previousblockhash입니다.

한 가지 결과는 모든 탐색기의 첫 화면에서 보입니다. 작업 증명은 이 인쇄 방향에서 긴 영의 연속으로 시작하는 다이제스트를 만들어냅니다. 그 영들은 원시 바이트의 반대쪽 끝에 있습니다. 채굴 목표는 인쇄된 형식에서 추론하기가 더 쉬우며, 관례가 정리되지 않고 유지된 이유 중 하나입니다.

뒤집기는 해시에만 적용됩니다. 공개 키, 서명, 스크립트, 위트니스 항목은 모두 실제 순서로 인쇄되므로 decodescript의 스크립트는 원시 트랜잭션과 직접 비교할 수 있지만 txid는 그렇지 않습니다. 이 두 규칙을 섞는 것이 동작하는 코드가 보통 잘못되는 지점입니다.

하나의 응답이 두 관례를 동시에 담을 수도 있습니다. 상세 출력으로 트랜잭션을 요청하면 txid 필드는 뒤집혀 있고, 바로 옆의 hex 필드는 같은 해시를 반대 방향으로 담은 손대지 않은 직렬화입니다.

확인할 수 있는 곳

RPC 바이트 순서는 대부분의 사람이 다루는 유일한 해시 형식입니다.

거래소가 출금 확인 이메일에 넣는 것, 블록 탐색기가 URL에서 기대하는 것, 지원 담당자가 보내 달라고 요청하는 것, bitcoin-cli가 인쇄하는 것이 모두 이것입니다. getblockhash 0으로 노드에 첫 블록을 요청하면 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f가 반환되며, 그 문자열을 어느 탐색기에 붙여 넣어도 2009년 1월 3일에 채굴된 블록으로 연결됩니다.

실패 방식은 좁고 일관적입니다. 누군가 직접 트랜잭션 식별자를 계산하면서 직렬화에 SHA-256을 두 번 적용하고, 그 결과를 탐색기와 비교하면 전혀 비슷하지 않습니다. 두 문자열은 같은 32바이트이며 그중 하나는 뒤집어야 합니다. 스크립트가 원시 입력에서 txid를 꺼내 API에서 모은 식별자 표에서 찾을 때도 같은 해결책이 적용됩니다.

들일 만한 2초짜리 습관이 있습니다. 누군가 보낸 해시가 어디로도 연결되지 않으면, 트랜잭션이 존재하지 않는다고 결론 내리기 전에 거꾸로 시도해 보십시오. 지원 게시판은 지갑이 아니라 원시 데이터에서 복사된 해시로 가득하며, 뒤집기 전까지는 완전히 유효해 보입니다.