Un bloque compacto es una codificación de transporte, no un bloque de consenso menor. Un Full Node debe recuperar las transacciones exactas en orden y validar todo el bloque.
Un ID corto tiene 48 bits obtenidos truncando SipHash-2-4. Las claves derivan de la cabecera y el nonce suministrado; no es un identificador global de transacción. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation]
Algunas transacciones llegan completas como elementos preincluidos, normalmente la coinbase entre ellas. Sus índices indican la posición en el bloque reconstruido. [BIP 152 — Compact Block Relay]
El receptor compara ID cortos con transacciones conocidas, por ejemplo en su mempool. Un ID igual por sí solo no prueba identidad de transacciones. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation]
Los elementos faltantes o ambiguos se piden por índice con getblocktxn. La respuesta blocktxn entrega las transacciones solicitadas para terminar la reconstrucción. [BIP 152 — Compact Block Relay] [Bitcoin Developer Reference — P2P] [Bitcoin Core v29.0 — net processing]
Se conserva el orden exacto y se verifican los compromisos del bloque. Un Full Node aún valida el consenso antes de aceptar; el transporte compacto no es una excepción. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation] [Bitcoin Core v29.0 — net processing]
Tras negociar sendcmpct, el modo de alto ancho de banda puede anunciar directamente con cmpctblock. Tras controles preliminares puede preceder la validación completa del emisor sin eliminar la del receptor. [BIP 152 — Compact Block Relay] [Bitcoin Core v29.0 — net processing]
El modo de bajo ancho de banda usa primero anuncios inv o headers y luego el receptor solicita el bloque compacto. Puede requerir más rondas que un anuncio directo. [BIP 152 — Compact Block Relay] [Bitcoin Developer Reference — P2P]
Las colisiones pueden provocar solicitudes de transacciones o fallos de reconstrucción seguidos de descarga completa. No permiten aceptar un bloque incorrecto como válido por consenso. [BIP 152 — Compact Block Relay] [Bitcoin Core — BIP 152 implementation] [Bitcoin Optech — Compact block relay]
La versión 2 deriva ID de wtxid en vez de txid y transmite datos witness según BIP 144. La versión del protocolo compacto no es el número de versión del propio bloque. [BIP 152 — Compact Block Relay] [BIP 144 — SegWit peer services]
El beneficio depende de transacciones compartidas y condiciones de red. Poco solapamiento añade solicitudes; el objetivo principal es ahorrar datos, no garantizar tamaño de mensaje ni latencia cero. [BIP 152 — Compact Block Relay] [Bitcoin Optech — Compact block relay]
Para obtener la imagen más completa, lee esta entrada junto con Propagación de bloques, Descarga inicial de bloques, Ataque de eclipse, Byte virtual. También enlazan con esta entrada Propagación de bloques, Compact Block Filters, Compact Block Filters, Matt Corallo.