Glosario / Transacciones y comisiones
Maleabilidad de transacciones
También se conoce como Maleabilidad.
- ¿Qué es la maleabilidad de transacciones?
- La maleabilidad de transacciones es el defecto que permitía a un tercero cambiar el ID de una transacción sin cambiar adónde iba el dinero, volviendo a codificar los datos de firma que contenía.
Se especifica en el BIP-66.
El pago seguía funcionando; solo cambiaba su nombre. Bitcoin cerró el agujero por etapas entre 2015 y 2017, y SegWit terminó el trabajo para las entradas que guardan las firmas en el testigo. Las entradas heredadas (legacy) siguen siendo maleables, lo que es una razón más para conservar las monedas en una dirección que empieza por bc1.
Cómo funciona
Un ID de transacción es un hash de los bytes de la transacción, así que alterar cualquier byte produce un ID distinto, y en una entrada heredada la firma forma parte de esos bytes.
Tres tipos de laxitud hacían posible una alteración sin romper nada.
La primera es aritmética. Una firma ECDSA es un par de números, r y s, y para cada s válido existe un segundo valor igual de válido: el orden de la curva menos s. Cualquiera que observe la red puede cambiar un valor por el otro y la verificación sigue saliendo bien.
La segunda es la codificación. Las firmas iban envueltas en DER, y la biblioteca de la que dependía bitcoin aceptaba variantes descuidadas: bytes cero a la izquierda sobrantes, marcadores de longitud no canónicos, un relleno que ningún codificador cuidadoso emitiría. Cada variante daba, al calcular su hash, un ID distinto.
La tercera es el script de desbloqueo que rodea a la firma. Apilar un elemento adicional inofensivo dejaba idéntico el resultado del script y distintos los bytes serializados.
Las correcciones llegaron capa por capa. BIP66 convirtió la codificación DER estricta en una regla de consenso a la altura 363.725, el 4 de julio de 2015, una activación que se recuerda sobre todo porque varios grandes pools de minería construían sobre encabezados que no habían validado y produjeron esa tarde una bifurcación de seis bloques. Bitcoin Core 0.11.1, publicada en octubre de 2015, convirtió los valores bajos de s en una regla de política de retransmisión, documentada más tarde como BIP146. BIP62, un intento de enumerar y prohibir todas las fuentes restantes, se abandonó por inviable y conserva hasta hoy el estado Withdrawn (retirado). Lo que zanjó la cuestión fue SegWit, activo desde la altura 481.824, el 24 de agosto de 2017: las firmas pasaron al testigo, el ID se calcula sin el testigo y, en una entrada SegWit, sencillamente no queda nada que alterar.
Dónde aparece
La maleabilidad nunca causó robos; causó fallos contables, y esa sigue siendo la forma que tiene el riesgo.
A un custodio que hacía el seguimiento de los retiros por el ID que había difundido se le podía mostrar una transacción confirmada con un ID distinto, y podía concluir que su propio pago había fallado y volver a enviar las monedas. Ese patrón causó pérdidas reales en exchanges en 2014, y es la razón por la que los operadores serios concilian por dirección de salida y monto, y no solo por ID.
Las transacciones encadenadas fueron la otra víctima. Una transacción hija que gasta una transacción padre sin confirmar la identifica por su ID, así que una transacción padre alterada por maleabilidad deja a la transacción hija imposible de gastar para siempre. Cualquier protocolo que firmara un reembolso antes de que se difundiera la transacción de financiación, lo cual es exactamente lo que hace la apertura de un canal Lightning, no se podía construir con seguridad hasta que los ID se volvieron estables.
Para quien compra y conserva, un solo hábito lo cubre todo. Un ID sin confirmar no es un hecho. Todavía puede cambiar por maleabilidad en las entradas heredadas, y ahora cambia de forma rutinaria por un motivo que no tiene nada que ver, porque Bitcoin Core retransmite por defecto el replace-by-fee completo y un remitente que aumenta la comisión publica un ID nuevo. Espere una confirmación y después comunique el ID a quien se lo pida.
Maleabilidad de transacciones frente a doble gasto
La maleabilidad mueve la etiqueta; un doble gasto mueve el dinero. En una transacción alterada, las mismas monedas llegan a la misma dirección por el mismo monto, y solo el software que memorizó el ID antiguo se da cuenta de que ha pasado algo. En un doble gasto, una transacción rival envía esas monedas a otro lugar y una de las versiones acaba sin valor. Confundir las dos cosas enseña a la gente a desconfiar de los pagos confirmados, y esa es la lección equivocada: un ID confirmado nunca ha sido maleable, porque la maleabilidad solo se aplicaba mientras una transacción seguía sin confirmar.