Transaction Relay y goteo en Bitcoin

Si un nodo tiene 100 conexiones con otros nodos y recibe una nueva transacción mediante una solicitud getData, envía un mensaje inv a sus 100 pares conectados, ¿correcto?

¿También envía el mensaje inv al par del que acaba de recibir la transacción, ya que todavía es uno de sus pares de conexión?

'Los mensajes, en general, se descargan periódicamente cada 100 ms. Sin embargo, la retransmisión de transacciones se lleva a cabo mediante el "goteo" de mensajes. Bitcoin selecciona aleatoriamente con una probabilidad de 1/4 de las transacciones para un mensaje inv y detiene las transacciones restantes. Cada vecino obtiene un conjunto diferente de transacciones elegidas al azar, cada una aproximadamente 1/4 del conjunto disponible actualmente. Solo el "nodo de goteo" seleccionado aleatoriamente (cf. retransmisión de mensajes addr) obtiene todas las transacciones de inmediato. Los otros vecinos lo obtienen más tarde o ya lo obtuvieron de otro vecino. El goteo reduce la sobrecarga y, al mismo tiempo, dificulta el análisis del tráfico, de manera similar a como lo hacen las mezclas en las redes mixtas.'

Tengo un poco de dificultad para entender cómo funciona el goteo en términos de transacciones. Creí que el proceso era cuando ocurre una transacción, el nodo responsable de la transacción enviaría mensajes INV a sus pares y enviaría el tx si los pares responden con getData.

Respuestas (2)

Si un nodo tiene 100 conexiones con otros nodos y recibe una nueva transacción mediante una solicitud getData, envía un mensaje inv a sus 100 pares conectados, ¿correcto?

No. Depende de qué nodos hayan enviado un invmensaje indicando que tienen esa transacción. Cuando se invrecibe un correo electrónico, el nodo recordará lo que invese nodo les ha enviado para que no intente enviarle algo que ya tiene. Como máximo, se enviarán 99 invmensajes. Como ya sabemos que el par que nos envió la transacción ya la tiene, no le enviamos un inv. Como mínimo, no se enviarán invmensajes porque todos los nodos ya podrían habernos enviado un mensaje invpara la misma transacción.

¿También envía el mensaje inv al par del que acaba de recibir la transacción, ya que todavía es uno de sus pares de conexión?

Como se indicó anteriormente, no lo hace. Si bien no existe una regla que lo impida explícitamente, es sensato no enviar un correo electrónico inva alguien que ya invle haya enviado un correo electrónico por el mismo motivo. Esto ahorra costos de ancho de banda.

Tengo un poco de dificultad para entender cómo funciona el goteo en términos de transacciones.

Para cada par, el nodo mantiene una lista de transacciones a las que se dirige inv. Envía invtransacciones periódicamente con un retraso aleatorio entre cada una inv. Las transacciones se seleccionan para que entren en el invmensaje de forma algo aleatoria y de acuerdo con algunas métricas relacionadas con la tarifa. Selecciona un número limitado de transacciones a inv.

Creí que el proceso era cuando ocurre una transacción, el nodo responsable de la transacción enviaría mensajes INV a sus pares y enviaría el tx si los pares responden con getData.

El nodo que crea una transacción trata esa transacción como cualquier otra que recibió a través de la red. Para cada par al que está conectado el nodo, agrega esa transacción a la lista de transacciones que enviará eventualmente a ese nodo. Entonces todo lo demás es como siempre. La próxima vez que envíe un invmensaje para un par en particular, elige transacciones para inv, y la transacción que creó puede o no ser una de esas. Una vez que se invenvía, el otro nodo responderá con un getdatapara las cosas que quiere, que puede incluir o no la transacción que creó. Luego, su nodo responde con las getdatatransacciones mismas.

Muchas gracias por tu respuesta detallada. Entonces, si entiendo esto correctamente, los nodos no enviarán un mensaje INV a los pares que saben que ya tienen la transacción (es decir, los pares que ya enviaron a este nodo un INV a la misma transacción). Y cuando un nodo quiere enviar un tx INV a sus pares, lo agrega a una lista ya existente de transacciones que quiere enviar a ese par específico. Cuando finalmente se envía, ¿este mensaje INV contiene múltiples hashes de txID o es un INV por hash de txid?
Cuando envía, invdebe contener múltiples txid. Sin embargo, es posible (y quizás probable) que para cuando envíe un correo electrónico inv, solo haya uno o dos txid para enviar.
Puede valer la pena señalar que las comillas en la pregunta de OP están desactualizadas (se refieren al antiguo mecanismo de goteo que fue reemplazado con lotes distribuidos por poisson hace algunos lanzamientos importantes en Bitcoin Core).
¿Qué pasa con los txs que no encajan en el mempool local, todos los mantienen circulando (recibiendo y transmitiendo nuevamente porque no se ven)?
@VincentAlex Las transacciones que no se agregan al mempool de un nodo no son retransmitidas por ese nodo. Las transacciones que se agregan al mempool de un nodo no se transmiten más de una vez. Por lo tanto, las transacciones que no pueden ingresar a los mempools simplemente no se transmiten. No siguen circulando a menos que alguien los retransmita intencionalmente.

envía un mensaje inv a sus 100 pares conectados, ¿correcto?

a 99

¿También envía el mensaje inv al par del que acaba de recibir la transacción?

está permitido, pero no hay razón para hacerlo

el nodo responsable de la transacción enviaría mensajes INV

nadie es responsable de nada

¿Por qué envía solo a 99 en lugar de a 100 pares? Si soy un nodo que acaba de recuperar una transacción, envío un INV a todos mis compañeros al respecto, ¿no es así? Incluso al que acaba de enviarme los datos, a menos que haya una manera de hacer un seguimiento de quién me los envió. entonces no enviaré el INV a ese nodo
Esto no responde a la pregunta, que es sobre la implementación práctica del protocolo de retransmisión tx, no sobre qué modificación se le permite a los nodos.
Transaction Relay y goteo en Bitcoin
RespuestasAquíPolítica de privacidad1y, 0v