¿Puede una transacción sin confirmar con una tarifa baja evitar las confirmaciones de las siguientes transacciones?

Para ser más precisos, considere la siguiente situación:

  1. La dirección A obtiene una entrada de 4 BTC.
  2. Intenta realizar una transacción de A a B con 1 BTC y una tarifa muy baja, lo que significa que no está confirmada durante mucho tiempo. Los resultados de la transacción son B y A (para dar cuenta del cambio de ~3 BTC después de las tarifas)
  3. Antes de esperar a que se confirme la transacción anterior, envía nuevamente de A a B, esta vez envía 2 BTC con una tarifa más alta, con la esperanza de que se confirme rápidamente.

Mi pregunta es, dado que la salida de la primera transacción es la misma dirección A, ¿deberá confirmarse primero para que la segunda transacción siga, porque la entrada de la segunda transacción es A?

En este ejemplo, utilicé montos para asegurarme de que haya "suficientes" bitcoins para cada transacción por separado (ya que si tiene 1 BTC e intenta enviarlo dos veces, intuitivamente verá por qué no debería funcionar).

Suponga que la billetera no genera direcciones adicionales automáticamente para manejarlo. Estoy hablando de este escenario específico de reutilización de direcciones.

Respuestas (1)

Sí, si la segunda transacción gasta la salida de la primera, entonces la #2 no puede confirmarse hasta después de que se confirme la #1. (Aunque se pueden confirmar en un solo bloque, siempre que el n.° 1 aparezca antes que el n.° 2 en ese bloque, en cuyo caso las confirmaciones son efectivamente simultáneas).

La mayoría de los mineros considerarán las transacciones sobre la base de que "el niño paga por el padre", de modo que una tarifa baja para el n. ° 1 podría compensarse con una tarifa alta en el n. ° 2. Las dos transacciones se considerarían como un único "bulto" con su tarifa combinada, y un minero las confirmaría si el conjunto combinado paga una tarifa más alta que la siguiente transacción (o conjunto) más lucrativa que podría llenar ese espacio.

Dos aclaraciones de seguimiento: (1) ¿Eso significa que puede bloquear efectivamente el uso de una billetera, ya que solo tuvo una transacción tonta con tarifas bajas y todos sus bitcoins llegaron utilizando una sola entrada en una sola dirección? (2) ¿Por qué importaría, si en mi ejemplo las 2 transacciones están flotando en el mempool, y puede confirmar cualquiera de ellas primero sin siquiera saber sobre la primera? ¿Los mineros verifican cada transacción que confirman contra cualquier otra transacción en el grupo también?
@AhiaCohen (1) No está permanentemente "bloqueado". Incluso si el n.º 1 nunca se confirma, aún puede crear una transacción n.º 1a diferente que gaste su entrada original de 4 BTC, enviándola a la dirección B o a cualquier otro lugar que desee. Este es un gasto doble, y es posible que a otros nodos de la red no les guste mucho si lo envía mientras todavía tienen el número 1 en su mempool (Bitcoin Core se desconectará de usted y prohibirá su IP por un tiempo, creo) , pero no está prohibido por el protocolo, y el #1a eventualmente podría ser confirmado en lugar del #1.
@AhiaCohen: (2) No puede confirmar el n.° 2 antes (o sin) el n.° 1, eso es lo que digo. Es una regla de protocolo que una transacción en un bloque solo puede hacer referencia a entradas que ya existen como salidas de transacciones anteriores. Cualquier bloque que contenga el n.° 2, si el n.° 1 no está ya en un bloque anterior de la cadena (o antes en el mismo bloque), es un bloque no válido y será rechazado por la red. Los mineros hacen y deben verificar esto.
Acerca de (2), pero dado que el número 1 aún no está confirmado, no está en la cadena de bloques. Y como entrada, el #2 puede llevar la entrada original a la billetera de 4 BTC, no (dado que el #1 no está confirmado, todavía hay un UTXO de 4 BTC en la dirección A).
@AhiaCohen: Ya veo. Sí, esa es la situación que describí en mi respuesta a (1); en ese caso, su #2 es lo que llamé #1a. Tiene todos los problemas habituales de un doble gasto. El software de Wallet normalmente no hará esto de forma predeterminada; preferirán gastar la salida de "cambio" del n. ° 1, ya que asumen que realmente desea que el n. ° 1 confirme si es posible.
Gracias, eso lo aclara un poco. Solo un bit final: ¿Puede la billetera elegir tomar como entrada para el n. ° 2, la salida del n. ° 1 aunque no esté confirmada? Asumí que solo puede tomar como salidas cosas que ya están registradas en la cadena de bloques, pero si no, entonces probablemente debería estar enojado con mi billetera por causar este lío.
@AhiaCohen: Sí, se puede, y las billeteras a menudo hacen esto. Esto se basa en el caso común de que el número 1 confirmará muy pronto y es posible que el usuario no quiera esperar antes de crear más transacciones. Si las tarifas son suficientes y el espacio de bloque no es escaso (que era el caso cuando se diseñó la mayoría del software de billetera actual), entonces es bueno poder poner en cola varias transacciones, y todas podrían confirmarse juntas en el bloque siguiente. .