Relevo de Paquetes

  • La noticia de este mes es que Bitcoin Core v28-rc1 (que acaba de ser etiquetado) incluye la retransmisión de paquetes, y Gloria Zhao, quien escribió la característica, ha logrado que una transacción sin tarifas sea minada en testnet4.
  • El BIP se fusionó en abril de este año.

¿Por qué necesitamos la retransmisión de paquetes?

  • En varios protocolos, existe la necesidad de que una transacción sea confirmada lo más rápido posible. Algunos ejemplos incluyen:
    • HTLC-Timeout en LN-Penalty
    • Cancelación de Unvault en Revault
    • Transacción de Reembolso en Contratos de Logaritmo Discreto (DLC)
    • Actualizaciones en LN-Symmetry (anteriormente “Eltoo”)
    • Transacciones de Reclamo en PeerSwap
  • Queremos poder usar CPFP para confirmar estas transacciones, ya que nunca podemos predecir con certeza cómo será el entorno de tarifas por adelantado.
    • Todos estos protocolos usan transacciones creadas y retenidas sin ser transmitidas, a veces durante semanas o meses antes de finalmente ser transmitidas.
    • Siempre pueden haber picos repentinos en las tarifas de los mineros debido a ataques de spam, etc.
  • Debido a esto, queremos poder dejar una “salida de anclaje” de baja tarifa (o incluso de tarifa cero, también conocida como “ancla efímera”) y luego gastar esta salida en el mismo momento en que transmitimos nuestra transacción de “cierre forzoso”.
    • Es decir, queremos poder transmitir nuestra transacción de cierre forzoso, que está diseñada específicamente para ser utilizada con otra transacción “hija” que gasta nuestra “salida de anclaje” predeterminada, para incluir las tarifas del minero en la transacción hija y permitir que la transacción hija pague las tarifas de la transacción de “cierre forzoso”.
    • Esto nos permite crear protocolos fuera de la cadena donde las transacciones se crean mucho antes de ser transmitidas, sin conocer las tarifas por adelantado, y luego incluir las tarifas necesarias de manera urgente dentro de la transacción hija.

¿Por qué no podemos hacer esto ahora?

  • Actualmente, no hay forma de transmitir dos o más transacciones simultáneamente, donde la transacción madre paga tarifas por debajo del límite de expulsión del mempool, pero la transacción hija paga una tarifa lo suficientemente alta como para cubrir tanto a la madre como a la hija. Esto se debe a que las transacciones se evalúan para su inclusión en el mempool de forma individual.
    • Supongamos que transmites primero la transacción madre.
      • Como contiene cero tarifas, es rechazada inmediatamente porque está por debajo de la tarifa mínima de retransmisión de 1 sat/vbyte.
      • Este límite podría ser incluso mayor si tus pares están expulsando transacciones por encima de 1 sat/vbyte.
        • Esto comienza a suceder una vez que hay más de 300 MB de transacciones en el mempool.
      • Luego intentas transmitir la transacción hija.
        • Como sus entradas gastan salidas desconocidas (ya que la madre ha sido rechazada del mempool), la transacción hija también es rechazada.
  • Incluso si intentas transmitir ambas transacciones una justo después de la otra, sin la retransmisión de paquetes, la primera transacción siempre será rechazada, lo que hará que la segunda transacción también sea rechazada.
  • La única forma de evitar esto es permitir que el remitente transmita ambas transacciones simultáneamente como un solo “paquete”.
    • Esto permite a los nodos de retransmisión ver que, aunque la tarifa de la transacción madre es demasiado baja para ser incluida en el mempool, la transacción hija contiene suficientes tarifas para cubrir tanto a la madre como a la hija, por lo que ambas pueden incluirse de manera segura en el mempool y retransmitirse a otros pares.

Preguntas

  • ¿Qué es CPFP?
  • ¿Cuáles son algunos usos de la retransmisión de paquetes?