Handler:canApply can fail a transaction because of a case-sensitive check on publicKey

Describe the bug crypto/lib/handlers/transactions/handler.js line 27. There is a comparison : applicable = (transaction.senderPublicKey === wallet.publicKey) && enoughBalance

This check, will fail if either transaction.senderPublicKey is UPPERCASE and wallet.publicKey is lowercase or vice-versa, even if they’re equal. I ran into a scenario on my relay, where somehow the in-memory wallets found in Pool-Wallet-Manager(byPublicKey) became keyed by uppercase versions of the publicKey. So, on a subsequent transaction send, it would fail. This might have implications elsewhere where we do such comparisons.

To Reproduce I’m not sure how the in-memory wallets got keyed in uppercase, but I’d start in the transaction-pool and dig there. At any case, that shouldn’t cause the transaction to fail.

Expected behavior The two properties are equal in meaning, but not in casing. That shouldn’t be a deal breaker…

Screenshots

[vasild]

What a mess. The root of the problem is that we do machine operations on data that is presented in a human readable way, for humans to read, not machines.

Like, for example, trying to compare two dates by comparing their string representations and messing up trying to compare different human readable representations: Fri Nov 02 2018 08:20:40 GMT+0100 (Central European Standard Time) toString() and 11/2/2018, 8:20:40 AM toLocaleString() whereas the correct way would be to compare the machine readable variant (getTime() in this case).

That said, the correct way of doing things is to manipulate (store on disk, compare, send over the network) the public key in a binary buffer and only convert it to hex string when it is to be presented to humans. This way it will also take less space on disk, compare faster and use less bandwidth.

[paroxysm]

Yes @vasild , that is problematic and will mask hard to find bugs. We need to be pro-actively rooting such erroneous code before it comes back to bite us.

As far as storing publicKey as a binary buffer, I don’t view having it in hex form at runtime as a terrible thing, there’s some benefits(such as easier to debug, log analysis and write tests for). Devs just need to be cognizant when writing code of comparisons and equality, that there are casing issues.