Supongamos que transmito una transacción A con una tarifa muy baja (o cero). Normalmente, tomaría mucho tiempo para confirmar. Supongamos que luego transmito otra transacción B que gasta una salida (aún no confirmada) de la primera transacción A e incluye una tarifa normal o superior a la normal. Supongo que la transacción B solo se puede minar en el mismo bloque o en un bloque posterior al de la transacción A. ¿La tarifa más alta de la transacción B motivaría a los mineros a minar la transacción A también?
O, dicho en otras palabras, ¿puedo facilitar la confirmación de una transacción de tarifa baja gastando su producción usando una transacción de tarifa alta? En caso afirmativo, ¿qué cliente de Bitcoin me permitiría hacer eso?
Hay 3 casos.
Caso 1a: si Fee(Tx 1 ) < Dust Fee, los nodos que no ofrecen la política de retransmisión gratuita descartan Tx 1 . Entonces, todas las demás transacciones que dependen de las salidas de Tx 1 nunca se comprometerán con la cadena de bloques, aunque las transacciones descendientes pueden o no aceptarse en el mempool de un subconjunto de nodos en la red.
Caso 1b: si Tarifa (Tx 1 ) > Tarifa por polvo y tarifa (Tx 1 ) < Tarifa de Tx recomendada , mempool aceptará Tx 1 pero el compromiso final está en riesgo. En este caso, es posible aumentar la tarifa de la tarifa contribuyendo con más tarifas de transacción, como se describe en 2quick 4u usando CPFP, donde Tx 2 contendrá una tarifa de transacción más alta que Tx 1 , elevando la tasa de tarifa media que incluye la transacción principal, Tx 1 .
Caso 2: si Fee(Tx 1 ) > Dust Fee && Fee(Tx 1 ) >= Tarifa de Tx recomendada , los nodos aceptan Tx 1 . Todas las transacciones dependientes que dependan de las salidas de Tx 1 deben eventualmente comprometerse con la cadena de bloques, siempre que la tarifa de la raíz y las transacciones dependientes sean lo suficientemente altas competitivamente para ser seleccionadas y comprometidas con la cadena de bloques. La razón por la que deberíaestá en negrita es porque una tasa de tarifa competitiva cambia constantemente en función de la demanda en la red. Por lo tanto, uno esperará que la tarifa sea significativamente más alta cuando la red esté ocupada y viceversa. Además, suele haber un límite de 72 horas para las transacciones pendientes que se encuentran en el mempool. Una vez que hayan transcurrido 72 y aún no se haya confirmado una transacción, se eliminará del mempool.
Que yo sepa, no existe una práctica generalizada de los mineros para hacer esto, pero ciertamente se puede programar.
A medida que las tarifas de transacción continúan aumentando y este tipo de transacciones atascadas se vuelven más problemáticas, esperaría que más mineros estuvieran dispuestos a escanear el mempool y verificar las entradas para usarlas en transacciones posteriores (con tarifas más altas).
Este concepto de CPFP debería volverse mucho más fácil de implementar para los mineros pronto: https://github.com/bitcoin/bitcoin/pull/7600
Vladímir Reshetnikov
Jestin
muro
rny
amaclin
rny