Glosario / Referencia para desarrolladores
Orden de bytes RPC
- ¿Qué es el orden de bytes RPC?
- El orden de bytes RPC es la forma invertida en que el software de bitcoin muestra los hash de 32 bytes, y la que tiene todo ID de transacción copiado de una billetera o un explorador de bloques.
La cadena de 64 caracteres que su billetera llama ID de transacción no sigue el orden que esos bytes tienen en ningún otro lugar. Bitcoin Core guarda un hash en un tipo que lo imprime con el byte más significativo primero, todos los exploradores copiaron la costumbre y la convención ya es permanente. Es inofensiva cuando usted pega un identificador en un cuadro de búsqueda y costosa cuando lo pega en código.
Cómo funciona
El orden de bytes RPC es una transformación de presentación que se aplica al salir de un nodo, no un hash distinto.
Un hash sale de SHA-256 como 32 bytes sin ningún sentido de lectura inherente. Bitcoin Core lo guarda en un contenedor que modela esos bytes como un único número muy grande, e imprimir un número pone la parte más significativa a la izquierda, lo que invierte la secuencia de bytes. Todo campo JSON que designa un bloque o una transacción sale así: el hash de la llamada RPC getblockhash, el txid de getrawtransaction, el merkleroot de getblock y el previousblockhash que une un bloque con su bloque padre.
Una consecuencia se ve en la portada de cualquier explorador. La prueba de trabajo produce unos hash que, en el sentido en que se imprimen, empiezan por una larga serie de ceros. Esos ceros están en el extremo opuesto de los bytes en bruto. Es más fácil razonar sobre los objetivos de minería en la forma impresa, y en parte por eso la convención se mantuvo en lugar de corregirse.
La inversión solo afecta a los hash. Las claves públicas, las firmas, los scripts y los elementos del testigo se imprimen todos en su orden real, así que un script obtenido con la llamada RPC decodescript se puede comparar directamente con la transacción en bruto, mientras que un txid no. Mezclar esas dos reglas es justo donde suele fallar un código que funciona.
Una sola respuesta puede incluso contener ambas convenciones a la vez. Si pide una transacción en modo detallado, el campo txid aparece invertido, mientras que el campo hex, justo a su lado, es la serialización intacta que contiene el mismo hash en el orden contrario.
Dónde aparece
El orden de bytes RPC es la única forma de un hash que la mayoría de la gente llega a manejar.
Es lo que un exchange pone en un correo de confirmación de retiro, lo que un explorador de bloques espera en una URL, lo que un agente de soporte le pide que envíe y lo que imprime bitcoin-cli. Pedir a un nodo el primer bloque de todos con getblockhash 0 devuelve 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, y pegar esa cadena de caracteres en cualquier explorador lleva al bloque minado el 3 de enero de 2009.
El modo de fallo es acotado y coherente. Alguien calcula por su cuenta un identificador de transacción, aplicando SHA-256 dos veces a la serialización, compara el resultado con un explorador y no encuentra ningún parecido. Ambas cadenas de caracteres son los mismos 32 bytes y una de ellas hay que invertirla. La misma solución vale cuando un script toma un txid de una entrada en bruto y lo busca en una tabla de identificadores obtenidos de una API.
Hay un hábito de dos segundos que vale la pena adoptar. Si un hash que alguien le envió no lleva a ningún sitio, pruébelo invertido antes de concluir que la transacción no existe. Los hilos de soporte están llenos de hash copiados de datos en bruto y no de una billetera, y parecen completamente válidos hasta que se invierten.