Envío de bloque no solicitado

Enviar sin invitación es descortés en la mayoría de los protocolos y correcto en este. Cada ida y vuelta que un bloque pasa en tránsito es tiempo que algún minero dedica a minar sobre una punta de la cadena que ya no existe, así que BIP152 formalizó el atajo: hasta tres pares elegidos pueden lanzarle un bloque en cuanto lo tengan. Su nodo lo valida desde cero de todos modos y no le debe nada al remitente.

Cómo funciona

Bajo el nombre de envío de bloque no solicitado circulan dos cosas distintas, una antigua e informal y otra especificada.

La forma antigua es simplemente un mensaje block que llega sin ningún mensaje getdata que le corresponda. El protocolo nunca lo prohibió y los destinatarios siempre han procesado esos bloques, aunque con condiciones. Bitcoin Core comprueba la prueba de trabajo del encabezado antes de hacer nada costoso, no retransmite el bloque hasta que quede validado por completo y se conecte a la mejor cadena, y trata un bloque que no se conecta a nada que conozca como algo que descartar y no como un rompecabezas que resolver. Esas reglas existen porque los datos no solicitados son gratuitos para el remitente y costosos para el destinatario, y esa es la forma que adopta todo ataque de denegación de servicio en el protocolo.

La forma especificada es el modo de alto ancho de banda de BIP152. Un nodo envía a su par un mensaje sendcmpct cuyo primer byte es 1, lo que significa: no anunciar, solo enviar. Ese par puede entonces enviarle un mensaje cmpctblock en el instante en que tenga noticia de un bloque nuevo, posiblemente antes de haber terminado de validarlo. BIP152 establece un tope estricto de tres pares de ese tipo y Bitcoin Core hace cumplir exactamente eso, manteniendo una lista de como máximo tres nodos escogidos por haber entregado primero los bloques recientes. Tres es una solución intermedia: redundancia suficiente para que un solo par lento no pueda hacerle esperar, y lo bastante pocos como para que usted no reciba el mismo bloque por cada una de sus conexiones.

Como un anuncio de alto ancho de banda puede preceder a la validación, el nodo que lo recibe lo trata como una afirmación y no como un hecho. La prueba de trabajo se comprueba primero, por ser la única parte de un bloque que no se puede falsificar a bajo costo, y todo lo demás sigue la ruta normal. La versión de protocolo 70015 existe precisamente para que un nodo pueda señalizar que no penalizará a un par por anunciar un bloque que después resulte no haber sido comprobado por completo.

Dónde aparece

Los envíos no solicitados se concentran allí donde los segundos valen dinero.

Los pools de minería mantienen conexiones directas entre sí y con redes de retransmisión como FIBRE, construidas para mover bloques entre continentes con tan poco intercambio de anuncio y solicitud como permite la física. En una máquina común, la llamada RPC getpeerinfo informa de dos indicadores por par, bip152_hb_to y bip152_hb_from, que muestran a qué pares ha solicitado usted que le envíen bloques y cuáles le han solicitado lo mismo a usted. Ver el primero en tres pares es normal, y tres es el límite.

Envío de bloque no solicitado frente a retransmisión estándar de bloques

La retransmisión estándar de bloques y un envío no solicitado difieren en quién decide que los bytes se muevan. Con la retransmisión estándar solicita el destinatario, así que controla su propio ancho de banda y puede rechazar cualquier cosa que ya tenga. Con un envío decide el remitente, lo que ahorra una ida y vuelta pero pone en manos de un extraño una palanca sobre los recursos de usted. La respuesta de Bitcoin es no elegir entre los dos: permitir el envío, limitarlo a tres pares que usted mismo seleccionó, verificar la prueba de trabajo antes de gastar nada y validar el bloque por completo, sin importar con cuánta cortesía haya llegado.