Join GitHub today
Signature Malleability #1129
If elliptic curve signatures have the property that:
digest(transaction) + signature => pulbic_key
Then given a transaction signed with signature, you could create two identical transactions (transaction that execute the same operations) that each transaction has a different ID because the hash of the signatures would be different.
The block chain currently only checks for duplicates of transaction ID and not duplicates of digest(transaction).
Under this assumption then all transactions need to withdraw at least 51% of full balance and deposit change back to a new balance record or the receiver could replay the transaction with the modified signature and execute a double spend (within the expiration window of the transaction).
If the above property is true of elliptic curve crypto then a hard fork will be required to change how the transaction ID is calculated.
The first form of malleability is in the signatures themselves. Each signature has exactly one DER-encoded ASN.1 octet representation, but openssl does not enforce this, and as long as a signature isn't horribly malformed, it will be accepted. In addition for every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message.
So maybe we'll leave uniqueness check on
How quickly can we make a new release and get delegates to upgrade?
Is this serious enough that we should recommend merchants / exchanges to shut down and transact their entire balance to themselves until we fix it?
Still buggy; unique transaction cache isn't populated properly on startup since
Dupe feed update seems to have slipped in 3 days ago: 9a24317
Haven't figured out whether we are still vulnerable but it was in all likelihood due to the poor transaction cache handling that is still in master branch. This code has been rewritten in bitshares branch which is what revealed the above dupe.