¿Son los pagos de tarifas fuera de banda para confirmar una transacción de cierre relámpago la única forma de gestionar una situación en la que los sat/kw de un compromiso tx firmado previamente están simplemente por debajo del mercado?
Si se pudieran agregar entradas/salidas adicionales, las tarifas podrían ajustarse fácilmente a la tarifa de la tarifa durante el cierre del canal y no en el momento en que se firmó el tx...
Distingamos un par de casos:
En el caso de un cierre cooperativo, los dos socios de canal pueden acordar cualquier transacción que deseen. Por lo tanto, pueden elegir la tarifa de la tarifa en el acto. Como es probable que las dos salidas no tengan ningún límite de tiempo, cualquiera de las partes podría usar child-pays-for-parent (CPFP) para impulsar la transacción de cierre inicial. Incluso podrían emitir una transacción RBF inicialmente y actualizarla más tarde si no se confirma lo suficientemente rápido.
La parte que inicia la transacción de cierre tiene sus fondos bloqueados para permitir que la contraparte aplique su remedio de incumplimiento si se publicó un estado anterior. Esto significa que, tradicionalmente, solo la contraparte puede hacer uso de CPFP para acelerar el cierre de la transacción. Esto es un inconveniente, porque no habría necesidad de un cierre unilateral a menos que la contraparte no cooperara actualmente.
Las notas de la versión reciente de lnd 0.7.0 mencionan que se realizaron mejoras en sus procedimientos de cierre de transacciones para admitir RBF y CPFP.
¿Son los pagos de tarifas fuera de banda para confirmar una transacción de cierre relámpago la única forma de gestionar una situación en la que los sat/kw de un compromiso tx firmado previamente están simplemente por debajo del mercado?
Sí, tendrá que hacerlo fuera de banda, ya que no podrá utilizar una tasa de tarifa superior a la última transacción de compromiso firmada en el marco del protocolo Lightning Network. El BOLT #2 establece que cuando el financiador envía un closing_signedmensaje, el fee_satoshiparámetro debe ser menor o igual que la tarifa base de la transacción de compromiso final. El receptor debe fallar en la conexión si no cumple con este criterio.
Sin embargo, las reglas anteriores se pueden eludir. @Murch explicó la primera solución a través de CPFP y RBF. El segundo se puede hacer dentro del marco del protocolo Lightning Network. El financiador puede enviar un update_feemensaje (antes del shutdownmensaje) actualizando su tarifa a una más alta. Sin embargo, el financiador debe pagar la nueva tasa de tarifa en la transacción de compromiso actual del nodo receptor o el par que recibe el mensaje fallará en el canal. Luego puede enviar una transacción ficticia (digamos 1 satoshi) a través de ese canal a su par. Ahora, envíe un closing_signedmensaje con la misma fee_satoshitarifa actualizada y su transacción puede realizarse dentro de los límites del protocolo Lightning Network porque fue esta tarifa la que se utilizó para la última transacción de compromiso.
Si se pudieran agregar entradas/salidas adicionales, las tarifas podrían ajustarse fácilmente a la tasa de tarifa durante el cierre del canal y no en el momento en que se firmó el tx
Sería un arma de doble filo y podría crear el problema de la confirmación de la transacción. Digamos que una parte firma con SIGHASH_SINGLEy luego espera a que la otra parte firme y transmita la transacción. La otra parte puede agregar varias direcciones a las que desea el pago. Debido a estas salidas añadidas, feerate_per_kwserá inferior a lo que la contraparte acordó en el momento del open_channelmensaje y, por lo tanto, el tiempo que se puede tardar en confirmar esta transacción será superior a lo que esperaba el nodo de la contraparte. Esto se puede usar aún más para ataques DoS, donde abro el canal con los participantes, pero luego agrego tantas salidas que la tasa de la tarifa cae por debajo de lo que los mineros considerarían para incluirla en el bloque, bloqueando así los nodos de sus fondos.
La pregunta originalmente se refería a cierres de canales unilaterales, podría haberlo dejado más claro.
Sighash single no funciona ya que solo puede iniciar/cerrar sesión en el mismo índice.
Una idea propuesta por los desarrolladores de Lightning ha sido agregar ganchos de salida (consumibles por cada contraparte) con montos bajos o nulos que pueden gastar las transacciones secundarias que elevan la tarifa de toda la cadena de transmisión (CPFP).
Esto tiene el problema de que una cadena larga (maliciosa) de tarifa baja puede maximizar el límite de descendientes y anclar al padre en la parte inferior del mempool, evitando así cualquier CPFP por parte de la contraparte (Esta propuesta tendría 2 ganchos por transacción de compromiso) .
La solución para esto es la exclusión de mempool en el núcleo (fusionada en julio de 2019), que se aplica cuando se alcanza el límite descendiente (configurable por el usuario). En este caso, aún se puede aceptar un solo niño en el paquete de tx, que es utilizado por la parte no malintencionada para aumentar la tarifa del paquete de tx.
james c
singlemúltiples pares de entrada/salida, que comparten la misma entrada multisig, dado que los índices entre la entrada y la salida diferirían con todos los pares excepto uno.