Cuando un minero encuentra un bloque, la velocidad importa. Cuanto más tarda un bloque en llegar a otros mineros, más probable es que compitan dos bloques, y una propagación lenta favorece a mineros grandes y bien conectados. Sin embargo, la mayoría de las transacciones de un bloque nuevo ya están en el mempool de cada nodo. BIP152, de Matt Corallo, evita enviarlas dos veces. Bitcoin Core lo soporta desde la versión 0.13.0 en 2016.
Qué se envía
Un bloque compacto contiene la cabecera de 80 bytes, un nonce aleatorio, una lista de ID cortos de transacción de 6 bytes y algunas transacciones completas «precargadas», al menos la transacción coinbase. Los ID cortos vienen de SipHash-2-4, con clave a partir de un hash de la cabecera y el nonce, para que un atacante no pueda predecirlos de antemano y crear colisiones.
Reconstruir el bloque
El receptor calcula ID cortos de sus propias transacciones del mempool y las empareja. Si falta algo, pide con getblocktxn y recibe un blocktxn. Una colisión de ID corto es posible pero rara. Cuando ocurre, el nodo cae a descargar el bloque completo.
Dos modos
- Bajo ancho de banda: el par anuncia el bloque como de costumbre, tras validarlo, y el receptor pide la versión compacta. Esto lleva 1,5 idas y vueltas, o 2,5 si faltan transacciones, pero usa mucho menos ancho de banda que antes.
- Alto ancho de banda: el par empuja el bloque compacto de inmediato, incluso antes de validarlo por completo. Si no falta nada, no hace falta ninguna ida y vuelta extra. Bitcoin Core elige hasta 3 pares para este modo.
Versiones
La versión 1 usa txids. La versión 2 usa wtxids, así que los ID cortos también cubren datos de witness. Los nodos modernos usan la versión 2.
Por qué importa
Una retransmisión de bloques más rápida y ligera reduce la cuota de bloques obsoletos y abarata ejecutar un nodo completo. También reduce la ventaja que obtienen los grandes mineros de redes de relay rápidas.