The micropayment channels protocol is designed so the client doesn't need
internet access to complete it. Thus, the client asks the server to broadcast
the contract transaction for it.
Unfortunately at that point the server can edit the transaction in such a way
that the signatures don't break, but the hash changes. This would render the
refund transaction unusable, allowing a malicious server operator to engage in
extortion.
It's a somewhat tricky attack to actually pull off repeatedly because the users
software obviously won't have any support for doing what the extortionist
needs, so they'd need to convince the user to download some alternative
software and on Android, that software wouldn't even have access to the keys
needed due to the package isolation. But for desktop uses, when the server has
some out of band way to communicate with the user, it could be an issue.
There's a quick fix and the right fix. The right fix is to change Bitcoin to
make more and more tx malleability approaches invalid (initially that means non
standard and later it means new hard-forking network rules).
The quick fix is to change the code so that when the client does have network
access, it broadcasts the contract transaction itself rather than hand it off
to the server. That forces the server to engage in a race that it might lose.
With double spend alerts, the client can wait a few seconds and be pretty sure
that it has the winning side of any race. Of course it doesn't help for the
internetless use case.
Original issue reported on code.google.com by hearn@google.com on 30 Sep 2013 at 12:49
Original issue reported on code.google.com by
hearn@google.comon 30 Sep 2013 at 12:49