Glosario / Referencia para desarrolladores
MSG_WITNESS_BLOCK
- ¿Qué es MSG_WITNESS_BLOCK?
- El tipo de inventario de bloque con testigo es la forma en que un nodo compatible con SegWit solicita un bloque en la serialización extendida, con todas las firmas adjuntas en lugar de quitadas.
Se especifica en el BIP-144.
Dos nodos pueden tener el mismo bloque y discrepar sobre cuántos bytes ocupa. MSG_WITNESS_BLOCK es el código 0x40000002, una solicitud de bloque corriente con el bit de testigo añadido, y existe desde que SegWit se activó en el bloque 481.824, el 24 de agosto de 2017. Si usted ejecuta su propio nodo, esta es la solicitud que obtiene las firmas que su máquina necesita antes de confiar en la cadena.
Cómo funciona
Bitcoin Core mantiene dos formas de escribir el mismo bloque y elige entre ellas según quién lo solicite.
El indicador de testigo es un único bit alto, 0x40000000. Si se suma al tipo de inventario de bloque, que es el 2, se obtiene 0x40000002. BIP144 introdujo tanto ese indicador como el bit de servicio NODE_WITNESS, de valor 8, que un nodo anuncia en su mensaje version para indicar que puede servir los datos más completos. El indicador solo aparece en una solicitud getdata. Los anuncios viajan como inventarios de bloque normales, porque un anuncio es solo un hash y el hash es el mismo en ambos casos.
Ese último punto es la razón por la que pueden coexistir dos serializaciones. Un encabezado de bloque fija una raíz de Merkle construida a partir de txid, y un txid se calcula sobre la transacción sin su testigo. Si se quitan todas las firmas, el hash del bloque sigue siendo el mismo identificador de 32 bytes. Por separado, una salida de la transacción coinbase fija los datos de testigo: su script ocupa al menos 38 bytes y empieza por la etiqueta de cuatro bytes 0xaa21a9ed, seguida de una raíz de Merkle de testigo de 32 bytes.
Es en el tamaño donde la diferencia se nota. El límite de un bloque es de 4.000.000 unidades de peso, contadas como tres veces el tamaño sin datos de testigo más el tamaño completo, lo que permite que un bloque cargado de datos de testigo se acerque a 4 MB en la red. El bloque 774.628, minado el 1 de febrero de 2023, llegó a aproximadamente 3,96 MB, casi todo ello una sola inscripción alojada en el espacio de testigo. Si se aplica esa fórmula de peso a la inversa, a un bloque tan grande casi no le queda nada en su forma sin datos de testigo. Un par antiguo que solicitara la serialización heredada (legacy) habría recibido el esqueleto y nada de la carga útil, que es precisamente la razón por la que esos pares se consideran incapaces de validar los bloques actuales.
Dónde aparece
Dos lugares hacen visible MSG_WITNESS_BLOCK sin leer código fuente: los propios registros de depuración de un nodo y sus estadísticas de pares.
Inicie bitcoind con la categoría de depuración net y verá desfilar líneas getdata durante toda la descarga inicial de bloques, todas ellas con el indicador de testigo, porque un nodo moderno solo descarga bloques de pares que admiten datos de testigo. La llamada RPC getpeerinfo desglosa los bytes enviados y recibidos por tipo de mensaje, así que es fácil ver cómo el tráfico de bloques domina una sincronización. Bitcoin Core 23.0 añadió la llamada RPC getblockfrompeer, que solicita a un par concreto un bloque específico por su hash, y obtiene la forma con testigo.
Los nodos podados complican el panorama. Un nodo que funciona con la poda activada, cuyo valor mínimo permitido es de 550 MiB, anuncia el bit de servicio NODE_NETWORK_LIMITED y solo sirve los 288 bloques más recientes, aproximadamente dos días de historial. Si se le solicita algo más antiguo, no devuelve nada.
Para quien compra y conserva bitcoin, el significado es tajante. Verificar la cadena usted mismo significa descargar cada firma y verificarla. Una billetera de teléfono que consulta a un servidor nunca envía esta solicitud, nunca ve un testigo y está dando por buena la palabra de otro sobre el saldo que aparece en su pantalla.
MSG_WITNESS_BLOCK frente a MSG_BLOCK
MSG_BLOCK solicita el mismo bloque sin las firmas, y hoy es una solicitud heredada. Ambos tipos nombran un bloque por el mismo hash, y a ambos se responde con un mensaje block. La diferencia está en si el byte marcador, el byte indicador y las pilas del testigo están presentes dentro de cada transacción. Un nodo que solicita MSG_BLOCK para un bloque reciente no puede verificar ni un solo gasto SegWit de ese bloque, así que Bitcoin Core reserva esa forma para los pares que nunca señalizaron NODE_WITNESS.