Mensaje P2P

No existe ningún servidor central al que llamar, así que toda la relación de un nodo con la red es esta conversación. Bitcoin Core anuncia la versión de protocolo 70016, abre sus conexiones en el puerto 8333 y todo el vocabulario cabe en una página. Su retiro llega a un minero porque una máquina le dijo tx a otra, y eso se retransmitió unos pocos miles de veces en unos pocos segundos.

Cómo funciona

Cada conexión se abre con una negociación inicial (handshake) y después pasa a un pequeño conjunto de intercambios de mensajes que se repiten.

Lo primero que envía cualquiera de los dos lados es el mensaje version, que lleva el número de protocolo que habla, sus indicadores de servicio, la hora actual, la dirección que cree que tiene el otro extremo, un nonce aleatorio que sirve para detectar si se ha conectado consigo mismo por accidente, una cadena de agente de usuario y la altura de la mejor cadena que conoce. Cada lado responde con el mensaje verack. Hasta que ambos lo hacen, no se procesa nada más.

Ese número de protocolo es una escalera de funcionalidades, no un adorno. El anuncio directo de encabezados requiere 70012, la negociación de bloques compactos requiere 70014, anunciar un bloque compacto antes de la validación completa requiere 70015 y retransmitir transacciones por identificador de testigo requiere 70016. Un nodo lee el número de su par y renuncia discretamente a ofrecer las capacidades que ese par no puede usar, y así es como la red se actualiza sin una transición coordinada.

Agrupado por función, el vocabulario es breve. Para encontrar pares: getaddr, addr y la variante addrv2 de BIP155, que puede llevar direcciones de Tor e I2P. Para anunciar: inv y headers. Para solicitar: getheaders, getdata, getblocks, mempool. Para entregar: tx, block, cmpctblock, blocktxn, notfound. Para el mantenimiento: ping, pong, sendheaders, sendcmpct, wtxidrelay y feefilter, el último de los cuales le pide a un par que no se moleste en retransmitir transacciones por debajo de la comisión por vB que especifica.

Hay dos silencios deliberados. Los comandos que no se reconocen se ignoran en lugar de rechazarse, y eso es lo que permite que un tipo de mensaje nuevo se despliegue poco a poco en una red que nadie puede actualizar de una vez. Y un par no tiene forma de decirle a usted por qué descartó su transacción: el mensaje reject de BIP61 se desactivó de forma predeterminada en Bitcoin Core 0.18.0 y la opción se eliminó por completo en la 0.20.0, porque las respuestas eran poco fiables, triviales de falsificar y habitualmente se tomaban por fidedignas.

Dónde aparece

Los mensajes P2P son lo que su propio nodo pasa el día entero haciendo, y es fácil observarlos.

Inicie Bitcoin Core con -debug=net y el registro nombrará cada mensaje a medida que llegue. La llamada RPC getpeerinfo informa, para cada conexión, de los bytes enviados y recibidos desglosados por tipo de mensaje, lo cual es la forma más rápida de descubrir que un solo par le está suministrando casi todo mientras los demás permanecen inactivos. Difundir un pago desde una billetera conectada a su propio nodo produce una pequeña secuencia reconocible: un mensaje inv que sale, un getdata que vuelve y un tx que sale en respuesta.

Mensaje P2P frente a RPC

Bitcoin tiene dos interfaces y no son intercambiables. P2P es de nodo a nodo: sin autenticación, sin cifrado salvo que ambos extremos negocien el transporte v2, en el puerto 8333 y con un vocabulario que ningún participante puede ampliar por sí solo. RPC es de programa a nodo: con autenticación, local de forma predeterminada, en el puerto 8332 y con una lista de métodos que cambia en cada versión. Un pago que usted crea pasa por ambas: entra en su nodo como una llamada RPC y sale de él como un mensaje P2P, y solo la segunda mitad le incumbe a alguien más.