La #Bitcoin # Lightning Spec Part 3/8: Protocolo de pares para la gestión de canales

[Index , anterior , siguiente ]

Estas son 19 páginas de detalles básicos sobre el formato de los mensajes y cómo responder a ellos. No hay nada muy sorprendente si está familiarizado con alguna implementación anterior: configuración del canal, operación del canal y cierre del canal.

También hay una sección importante que destaca los riesgos de los tiempos de espera HTLC que quizás le interese leer.

Esta parte de la especificación en realidad no especifica e cómo generar las firmas, las claves o las transacciones (eso es BOLT # 3), pero puede ver algo extraño en eso enviamos varias firmas en cada mensaje “commitsig”, y también firmas en “revoke_and_ack”. Esto se debe a los HTLC de dos etapas …

Salidas HTLC de dos etapas: transacciones HTLC

Mats Jerratsch señaló un problema de externalidad con el esquema de transacción de compromiso en mi artículo relámpago desplegable y propuso una solución.

Aquí está el problema: anteriormente, las salidas HTLC ofrecidas por mí eran una prueba de tres vías:

Tenga en cuenta que el pago que se me debe devolver se debe retrasar un poco (“para autorretrasarse”); esto te da la oportunidad de usar la preimagen de revocación para tomar los fondos y penalizarme si intento gastar una transacción anterior.

Esto significa que el retraso real antes de que pueda finalizar el pago es el mayor de la altura del bloque de tiempo de espera y la altura del bloque actual más ese ‘retraso automático ‘. Al reenviar un HTLC, tengo que permitir esto y aumentar el tiempo entre el vencimiento del HTLC saliente y el vencimiento del HTLC saliente. En toda la red, esto significa que cada salto agrega ese “retraso a sí mismo”, aumentando el tiempo de espera de extremo a extremo en el peor de los casos.

La solución de Mats se remonta al borrador original del relámpago: permitimos que se agote el tiempo de espera de los HTLC o que se realicen correctamente a través de otra transacción, que realiza ese tiempo de espera para uno mismo. Para hacer esto, la salida HTLC se puede gastar en una “transacción HTLC” dedicada previamente firmada, que contiene el “retraso automático”. Fundamentalmente, la preimagen de revocación también permitiría a la otra parte robar esta transacción HTLC si ha sido revocada.

Tadge Dryja refinó esto aún más: no hay necesidad de que el script de salida HTLC original permita el uso de la preimagen de revocación: esa lógica se puede hacer por completo en las transacciones HTLC de segunda etapa. Esto significa que la otra parte necesita las firmas para enviar los HTLC con tiempo de espera a este segundo estado (de ahí las firmas en “revoke_and_ack”) pero ahorra espacio en la cadena.

La desventaja es que necesitamos calcular (o validar) una firma para cada HTLC en progreso en el paso de confirmación: eso es 52 y 63 microsegundos cada uno en mi computadora portátil, luego otro cálculo / validación para revoke_and_ack durante aproximadamente la mitad del HTLC (los que ofrecí).

Tarifas de Bitcoin: ¿quién paga?

Las tarifas de Bitcoin no son triviales: debe asegurarse de que sean suficientes para obtener una transacción en un bloque, quizás en algún momento en el futuro, pero tampoco desea pagar de más. Mi prototipo tenía un mecanismo para dividir las tarifas, y las tarifas para ambas partes se establecían de forma independiente.

En Milán, ganó la simplicidad: el lado que solicita la creación del canal paga las tarifas y puede establecer la tarifa. La otra parte puede simplemente abortar si considera que la tarifa es demasiado baja. Sin duda, esto se revisará en una versión futura de la especificación a medida que ganemos experiencia.

Sin embargo, una nota al margen: ¿qué tarifa utilizamos para las transacciones HTLC que agregamos? Esta arruga no se consideró en Milán, por lo que la especificación utiliza lo más simple, que es usar la misma tarifa que la transacción de compromiso. Desafortunadamente, esto significa que incluso si no está pagando la tarifa en la transacción de compromiso, está pagando la tarifa en sus transacciones HTLC, por lo que ahora le importa si es demasiado grande o demasiado pequeña.