¿Los canales de micropagos siguen sujetos a maleabilidad después de BIP65?

Hay una variedad de formas diferentes de construir un canal de micropagos, pero hay dos diseños que creo que son particularmente relevantes para su pregunta sobre "canales de micropagos simples y unidireccionales":

• Canales de micropagos estilo Spillman: este era un diseño de canal de micropagos comúnmente descrito antes de BIP65 ( OP_CHECKLOCKTIMEVERIFY, CLTV). Los canales de estilo Spillman fueron descritos por primera vez por Jeremy Spillman en abril de 2013 e implementados en la biblioteca BitcoinJ en 2013 .

• Canales de micropago estilo CLTV: esta es una nueva forma de construir un canal de pago que se hizo posible cuando CLTV entró en vigor a mediados de diciembre de 2015. Los canales estilo CLTV fueron descritos por el autor de BIP65, Peter Todd, como parte de ese BIP e implementados en dos1- pitón en febrero de 2016 .

Las siguientes dos secciones describen cómo la maleabilidad se relaciona con esos dos tipos diferentes de canales de micropagos.

Maleabilidad en canales de micropagos estilo Spillman

BIP65 no cambia la forma en que la maleabilidad afecta los canales de micropagos estilo Spillman, por lo que la siguiente descripción era cierta antes de que se aplicara BIP65 y ahora (al menos para las transacciones que no usan segwit).

Un canal de micropagos al estilo Spillman se construye utilizando la siguiente secuencia de eventos entre el Comerciante (que recibe los fondos) y el Cliente (que gasta los fondos):

1. El Comerciante entrega su clave pública al cliente.
2. El Cliente usa su clave pública y la clave pública del Comerciante para construir una dirección P2SH multisig[1] que requerirá las firmas tanto del Comerciante como del Cliente para gastar los fondos pagados a esa dirección.
3. El Cliente genera (pero no transmite) una transacción que paga la dirección multisig P2SH.
4. El Cliente genera una segunda transacción que devuelve la primera transacción a una de las direcciones del Cliente, otorga a esta transacción un tiempo de bloqueo (para que no se pueda agregar a la cadena de bloques hasta cierto momento) y firma esta transacción.
5. El Cliente entrega esta segunda transacción al Comercio (sin entregarle la primera transacción), y el Comercio la firma y devuelve la transacción firmada al Cliente.
6. Ahora el Cliente podrá usar esta segunda transacción, llamada transacción de reembolso, para reclamar un reembolso si el Comerciante no hace nada antes de que se alcance el tiempo de bloqueo.
7. Con un reembolso de respaldo asegurado, el Cliente transmite la primera transacción (llamada transacción de depósito ) para que se agregue a la cadena de bloques.
8. Ahora el Cliente puede firmar alternativas (llamadas transacciones de pago ) a la transacción de reembolso que no tienen tiempo de bloqueo y, por lo tanto, se pueden agregar a la cadena de bloques de inmediato, excepto por el hecho de que también requieren la firma del comerciante. Al dárselos al Comerciante, quien puede cofirmarlos (sin devolverlos al Cliente), el Comerciante puede estar seguro de que puede agregarlos a la cadena de bloques en un momento anterior a cuando la transacción de reembolso sea válida.

El problema con la maleabilidad ocurre en el séptimo paso anterior, cuando se transmite la transacción de depósito. Si la transacción que se agrega a la cadena de bloques no es byte por byte idéntica a la transacción de reembolso que el Comerciante firmó en el quinto paso, entonces la transacción de reembolso ya no es válida porque intenta gastar una transacción con un txid diferente que la transacción de depósito.

El Comerciante aún puede trabajar voluntariamente con el Cliente para devolver el dinero del Cliente, pero esto significa que no tenemos los canales de micropagos de estilo confiable que queremos.

Una nota sobre el testigo segregado (segwit): debido a que segwit elimina el tipo de maleabilidad que permitiría a alguien cambiar el txid de la transacción de depósito sin el permiso del Cliente, las transacciones que usan segwit pueden usar canales de micropagos al estilo Spillman sin riesgo de maleabilidad. causó problemas. Al momento de escribir este artículo, segwit no está implementado en la red principal, pero espero que lo esté tarde o temprano, así que lo describo aquí para los futuros lectores de esta respuesta. Tenga en cuenta que segwit es una característica opcional que el Cliente ya debería estar usando para eliminar la maleabilidad en este caso, por lo que la activación de segwit por sí sola no elimina automáticamente la maleabilidad en los canales de estilo Spillman.

[1] También se puede usar bare multisig (multisig sin una dirección P2SH).

Maleabilidad en canales de micropagos estilo CLTV

Un canal de micropagos estilo CLTV se construye usando la siguiente secuencia de eventos entre el Comerciante y el Cliente. Estos pasos serán idénticos tanto antes como después de activar segwit.

1. El Comercio entrega su clave pública al Cliente.
2. El Cliente utiliza su clave pública y la clave pública del Comerciante para construir una dirección P2SH que requerirá el cumplimiento de cualquiera de los siguientes conjuntos de condiciones:
   1. Tanto el Comerciante como el Cliente firman cualquier transacción que gaste desde esta dirección P2SH.
   2. Solo el Cliente firma cualquier transacción que gaste de este P2SH, pero esas transacciones de gasto deben tener un tiempo de bloqueo mayor que el tiempo de reembolso.
3. El Cliente genera y difunde inmediatamente la transacción de depósito. El Cliente tiene asegurada su capacidad para generar una transacción de reembolso a pedido por la Condición 2.2 anterior.
4. Ahora el Cliente puede usar la Condición 2.1 anterior para medio firmar (firmar 1 de 2 firmas requeridas) transacciones de pago que pagan al Comerciante. El Comerciante puede generar la segunda firma (sin proporcionarla al Cliente) y estar seguro de que puede transmitir la transacción de pago final antes de que el Cliente pueda agregar una transacción de reembolso a la cadena de bloques que se generó según los términos de la Condición 2.2.

Este proceso elimina las preocupaciones con la maleabilidad en los canales de micropagos estilo CLTV, aunque no elimina la maleabilidad en sí. Debido a que el Cliente puede generar la transacción de reembolso en cualquier momento según la Condición 2.2 anterior, no necesita comprometerse previamente con un txid en particular; puede esperar hasta que la transacción de depósito se haya agregado a la cadena de bloques y su txid se haya vuelto casi inmutable antes de generar la transacción de reembolso.

Si, a pesar de esperar múltiples confirmaciones, la maleabilidad ocurre de todos modos, el Cliente siempre puede generar y firmar una nueva transacción de reembolso utilizando su clave privada. Eso es porque todo lo que se necesita, de acuerdo con la Condición 2.2 en la dirección P2SH, es una firma de la clave autorizada más un tiempo de bloqueo después de una fecha determinada.

El Comerciante puede verse afectado por la maleabilidad si el txid de la transacción de depósito cambia después de haber aceptado cualquier pago. Por esta razón, es mejor que el Comerciante espere a que la transacción de depósito reciba al menos una confirmación antes de que el Comerciante acepte cualquier transacción de pago (esperar más confirmaciones brindará más seguridad y se recomienda para valores altos). Dado que el Comerciante debe esperar a que la transacción de depósito reciba la confirmación de cualquier manera para evitar que el Cliente gaste el doble (que también es el caso en los canales de estilo Spillman), esta fuente de maleabilidad no afecta significativamente la seguridad. modelo.

Conclusión

BIP65 no arregló la maleabilidad para los canales de estilo Spillman más antiguos, pero hizo posibles los canales de pago de estilo CLTV que no se ven afectados negativamente por la maleabilidad de las transacciones. Segwit también corregirá la maleabilidad para los canales de estilo Spillman cuando todas las entradas en la transacción de depósito se gastan de las salidas de segwit.

Sí. Dado que no puede firmar una firma y las firmas en una transacción se utilizan al calcular un txid, por lo tanto, solo los testigos segregados o los txid normalizados arreglarían la maleabilidad de la transacción.