Estoy tratando de entender el ataque de transacción maleable, ya que me parece que solo un operador bastante descuidado sería vulnerable en primer lugar, como se describe a continuación.
Principalmente para aclarar mis propios pensamientos, permítanme describir el ataque tal como lo entiendo. Dramatis personae: Alice es el atacante, y Bob es un "banquero" (operador de cambio, monedero web; alguien que tiene monedas a cuenta de Alice).
Alice : Hola Bob, tengo 1 BTC en mi cuenta y me gustaría retirarlo. Por favor envíelo a la dirección 1Alice1.
Bob : Bien, generé una transacción, su hash es 123abc. Lo acabo de publicar en la red p2p. Gasta la salida 3 de la transacción anterior 987def y envía 1 BTC a 1Alice1. Su cuenta ha sido debitada por 1 BTC y su nuevo saldo es 0.
Alice : Gracias, veo la transacción. Esperaré a que se confirme.
Ahora Alice construye una transacción "mutante", con el mismo efecto que 123abc; todavía gasta la salida 3 de 987def y envía 1 BTC a 1Alice1, y la firma aún se verifica, pero el mutante tiene un hash 456bca diferente. De alguna manera, Alice obtiene 456bca en la cadena de bloques en lugar de 123abc. Tal vez simplemente está mejor conectada en la red p2p que Bob, o tal vez soborna a Polly, un operador de grupo de minería, para que dé prioridad a 456bca. Dado que 123abc entra en conflicto con 456bca, 123abc nunca se confirmará.
Pasa algún tiempo.
Alice : Hola Bob, ¿recuerdas que se suponía que debía obtener 1 BTC? La transacción nunca se confirmó.
Bob : Déjame comprobar. Sí, ya veo, no existe una transacción como 123abc en la cadena de bloques. Bueno, supongo que nunca recibiste tus monedas; lo lamento. Voy a volver a acreditar su cuenta; su nuevo saldo es de 1 BTC.
Alicia : Gracias. Ahora que tengo 1 BTC nuevamente en mi cuenta, me gustaría volver a intentar retirarlo. Envíalo a 1Alice2.
Bob : Vale, he generado una transacción, su hash es 246fed. Lo acabo de publicar en la red p2p. Gasta la salida 7 de la transacción anterior 369dbc. Su cuenta ha sido debitada y tiene saldo 0 nuevamente.
La transacción 246fed se confirma normalmente.
Alice : ¡Te tengo, Bob! Su transacción original se realizó después de todo, solo en forma mutante como 456bca. Ahora lo tengo junto con la nueva transacción, y te acabo de robar 1 BTC. Mwa ja ja!
Bob : ¡Ay de mí!
Sin embargo, parece ser que este ataque requiere una contabilidad bastante descuidada por parte de Bob. Incluso si Bob no tiene idea de que existe tal cosa como una transacción maleable, sabe que generó 123abc y lo puso en la red, y por lo que sabe, todavía está flotando por ahí. Entonces, creo que antes de volver a acreditar la cuenta de Alice, el sentido común debería dictar que Bob se asegure de que 123abc no se pueda confirmar en una fecha futura, tal vez haciendo una nueva transacción (963dad) que gasta la misma entrada (trans 987def salida 3) a uno de sus propias direcciones (1Bob1), y esperando que 963dad confirme. Por supuesto, en el escenario actual, 963dad nunca lo confirmará (porque 456bca lo reemplaza), y Bob eventualmente se cansará de esperar e investigará más.
O, alternativamente, cuando Alice solicite retirar 1 BTC por segunda vez, la nueva transacción de Bob (678bbb) a Alice debería gastar nuevamente la misma entrada (987def: 3), asegurando que Alice no pueda confirmar 123abc más tarde. Esto también frustra el ataque, porque 678bbb ha sido invalidado por 456bca.
Además, dado que la transacción mutante de Alice 456bca de hecho gastó la entrada de Bob (987def:3), ¿no debería el software cliente de Bob informarle que esta entrada ya no está disponible para él y ajustar su saldo en consecuencia? Aparentemente, Bob cree que 123abc falló y, por lo tanto, todavía controla esa entrada y, por lo tanto, esto debería desequilibrar sus libros y alertarlo de que algo anda mal.
Tengo entendido que los Bobs del mundo han respondido al problema quejándose de que las "transacciones maleables" son un oscuro error de protocolo que no se esperaba que anticiparan. Sea cierto o no, me parece que para haber sido vulnerable, las prácticas contables de Bob ya tenían que ser negligentes, por lo que realmente no tiene defensa de ninguna manera.
O, si Bob vio las señales de alerta pero no entendió la situación y acreditó la cuenta de Alice de todos modos en interés del servicio al cliente, todavía es difícil sentir mucha simpatía por él.
¿Es esta cuenta esencialmente precisa, o me he perdido algunos detalles cruciales?
Gracias, y perdón por la extensión.
Si bien la mayor parte del proceso que describe es preciso, hay algunos detalles en los que creo que sus suposiciones no coinciden con la realidad y, por lo tanto, pueden llevarlo a ser (ligeramente) más crítico con Bob de lo que realmente se merece:
El hecho de que tx 123abc sea conocido por la red no significa necesariamente que Bob, aunque desconozca 456bca, tenga que temer que 123abc pueda arrepentirse. De alguna manera, sus transacciones, después de todo, continuaron, lo que para un alto volumen de transacciones como una billetera centralizada generalmente significa que la transacción no gastada 987def que ingresa a 123abc mientras tanto se gastó (y se confirmó). Bob puede decir esto incluso sin investigar qué transacción tomó el lugar de 123abc con solo ver la confirmación de transacciones posteriores. Pero, por supuesto, la acción que uno esperaría que tomara Bob, investigar qué tx reemplazó a 123abc (en lugar de suponer naturalmente que su software de billetera caliente solo podría haber generado otros tx válidos), debería haber evitado el fraude.
Además de otras razones que potencialmente impiden que se lleve a cabo una transacción, tal vez no incluyeste suficientes tarifas o estabas formando una transacción que a los pares no les gustó lo suficiente como para propagarla o a los mineros para incluirla, no es irrazonable. hacer que una billetera caliente recurra automáticamente a la resincronización con lo que se incluyó en la cadena de bloques, esencialmente gastando el doble del tx 987def anterior de modo que al menos se puedan manejar otros clientes. Por supuesto, el manejo adecuado marcaría internamente esta ocurrencia, para el manejo manual de la transacción fallida, que en este exploit de Alice estaría ausente y, en un proceso ideal, alertaría a Bob de que algo andaba mal.
En los sistemas distribuidos, no siempre existe un estado global común. Lo que debe parecer natural si hubo, digamos, una pausa de una hora en la operación de la billetera caliente, comparando el saldo real de Bitcoin y la contabilidad propia, no es tan trivial como cuando el sistema está continuamente en el estado de tener muchas transacciones aún sin confirmar. . Eso no debería ser una excusa porque un proceso de conciliación de cuentas y auditoría bien diseñado debería ser capaz de lidiar con eso, pero, nuevamente, es concebible que un proceso menos elaborado que antes funcionaba no pueda lidiar con el problema de muchas no confirmaciones. actas.
Estoy de acuerdo en que, en retrospectiva, Bob manejó la situación bastante mal y no con el tipo de diligencia que esperaría de alguien a quien se le confían los bitcoins de otros. Pero es realmente difícil diseñar procesos, especialmente en una operación de varias personas las 24 horas del día, los 7 días de la semana, para lidiar con lo que un concepto erróneo te hace pensar que es absolutamente imposible. De hecho, es posible que Bob haya estado operando con algún tipo de proceso alternativo para lidiar con su implementación de billetera caliente que no proporciona un registro adecuado de las transacciones que normalmente no se propagan.
En esencia, ha replicado el argumento de que nadie debe preocuparse por este problema, que ahora sabemos que es falso. Es por esa misma creencia que tenemos el lío que tenemos ahora.
Un detalle crucial que pasó por alto es que cuando gasta los resultados de una transacción anterior, debe especificar su ID de transacción en su nueva transacción. Así que hay muchos otros posibles escenarios de falla.
Por ejemplo, supongamos que forma solo transacciones que gastan sus propios productos, por lo que puede suponer que sus transacciones definitivamente tendrán éxito eventualmente y, por lo tanto, puede encadenar transacciones sin esperar confirmaciones. Hasta hace poco, esta se consideraba la forma correcta de generar grandes volúmenes de transacciones.
Pero ahora entendemos que no puede porque la cadena puede romperse por completo si alguna transacción en la cadena tiene su ID cambiada. La próxima transacción que se refiera a cualquiera de esas salidas nunca se confirmará, ya que tendrá una ID de transacción incorrecta especificada en una de sus entradas. Las transacciones posteriores que gasten de esa transacción también fallarán y tendrá un lío profano.
Originalmente iba a expresar esto como un comentario, pero tengo la confianza suficiente para arriesgarme a los votos negativos con una respuesta:
Lo que Bob debería haber hecho fue gastar las entradas originales nuevamente (posiblemente simplemente retransmitiendo su txn original). Si el txn alternativo ya estaba en la cadena de bloques, el nuevo txn se rechazaría correctamente como un gasto doble, lo que alertaría a Bob de que las monedas habían cambiado de manos.
Espero aprender cómo mi explicación simple es incorrecta :)
Mire este video que supuestamente demuestra un truco de maleabilidad en mtgox:
https://www.youtube.com/watch?v=WfKy3DEiOwY
Parece que gox volvió a acreditar automáticamente su cuenta después de la transacción fallida, lo que explicaría tanto la discrepancia fiduciaria (vender sus monedas pirateadas por fiat) como la discrepancia de monedas.
Ahora la verdadera pregunta es:
¿Cómo no se dieron cuenta esos idiotas de Gox?