¿Cómo se puede gastar una salida mientras la transacción está en mempool?

He visto transacciones en un explorador de bloques donde la transacción está en mempool (sin confirmar) pero una de las salidas ya aparece como gastada, tengo curiosidad por saber cómo funciona esto. Esta pregunta es un duplicado de esta pregunta, pero la respuesta no satisface mi confusión. Estoy pensando en cómo se permite este proceso junto con las reglas de protocolo para los mensajes 'tx' enumerados aquí , particularmente la regla 9, 10, 12.

  1. Para cada entrada, si la salida a la que se hace referencia existe en cualquier otro tx en el grupo, rechace esta transacción.

  2. Para cada entrada, busque en la rama principal y el grupo de transacciones para encontrar la transacción de salida a la que se hace referencia. Si falta la transacción de salida para cualquier entrada, será una transacción huérfana. Agregue a las transacciones huérfanas, si aún no hay una transacción coincidente.

  1. Para cada entrada, si la salida a la que se hace referencia no existe (por ejemplo, nunca existió o ya se gastó), rechace esta transacción

Preguntas:

  1. Parte de lo que podría estar causando confusión es la definición de "gastado" en el explorador de bloques: cuando afirma que se gastó una salida, ¿esto equivale a "existe una transacción al menos en mempool que usa la salida como entrada"?
  2. La capacidad de transmitir un mensaje de tx que usa la salida de un tx no confirmado como entrada parece violar explícitamente la regla 9. ¿No es así?
  3. Las reglas 9 y 10 parecen estar en desacuerdo entre sí. La regla 9 dice que se rechace si la salida está en un tx en mempool, la regla 10 dice que se verifique la salida en mempool (como si fuera permisible). ¿no es así?
  4. Creo que los nodos completos mantienen un conjunto "UTXO" para validar algunos de estos criterios: ¿se actualiza el conjunto UTXO una vez que una transacción llega a mempool (es decir, no espera una confirmación)?
  5. ¿Mempool es relativo a un nodo? Es decir, si transmito una transacción y un nodo la acepta como válida, ¿entonces pasa la transacción para que otros nodos puedan agregarla a "su" mempool, o hay de alguna manera un "mempool central" que puede enviar cualquier transacción validada? a.
  6. ¿Es posible cancelar un mensaje de tx que se ha agregado a mempool? No estoy preguntando si el software típico tiene esta función, pero es teóricamente posible para un usuario avanzado o es un "comportamiento permitido" dentro del protocolo bitcoin.

Respuestas (2)

No existe una regla que requiera que una transacción tenga una confirmación antes de gastarse.

  1. Sí, el mempool importa. Así es también como se detectan los gastos dobles. Por lo tanto, es crucial que los nodos verifiquen el mempool y no solo los bloques anteriores.
  2. No, no viola la regla, se refieren a que se rechazan los gastos dobles si existe la MISMA salida en el mempool.
  3. IDK, ¿tal vez le preguntes al póster original qué significaba?
  4. Sí, no es necesario que ninguna confirmación se convierta en una salida de transacción no gastada.
  5. Los mempools de nodo a nodo no siempre son idénticos. Por ejemplo, algunos nodos tienen diferentes reglas de retransmisión mínima que pueden incluir transacciones con tarifas extremadamente bajas. No hay un mempool central.
  6. No precisamente. No lo he hecho recientemente, pero digamos que transmite una transacción con una tarifa de 0. La transacción probablemente se atascaría en el mempool y no se confirmaría. Después de 14 días, si no se incluye en un bloque, "caduca". Una vez que caducó/cayó, pude crear una nueva transacción usando los mismos UTXO que usé en el original.

Aquí hay una pregunta relacionada que probablemente le resulte interesante: ¿
Qué sucede con las transacciones en el mempool cuando vence su transacción principal?

Gracias, y también gracias por el enlace. Pensé que hice mi investigación antes de publicar, pero no encontré esa. Entonces, cuando los exploradores de bloques muestran el tamaño de mempool, ¿qué muestran? ¿Solo el mempool en relación con el nodo completo que están ejecutando, que se supone que es un buen representante del total de mempool?
Aunque asumo que es muy probable que muestren el mempool de su(s) propio(s) nodo(s).
Gracias, las suposiciones están bien para esa pregunta.

El punto 9 significa: en un mempool, si hay dos transacciones que tienen entradas que se refieren a la misma salida, entonces rechace la transacción que llegó más tarde. Técnicamente, cada nodo verifica esta condición antes de agregar la transacción en mempool. Esto evita el Doble Gasto.

El punto 10 simplemente almacena en el nodo esa transacción cuya entrada se refiere a la salida de una transacción no confirmada (es decir, presente dentro del grupo). Si el nodo no puede encontrar la transacción principal, la transacción actual se almacena en el grupo de transacciones huérfanas.

El punto 12 es igual que el punto 9 excepto que en este paso el nodo busca el bloque anterior para rechazar esta transacción en caso de verificación doble.

¿Cómo se puede gastar una salida mientras la transacción está en mempool?
RespuestasAquíPolítica de privacidad1y, 0v