QR support for UOS

[pmespresso]

• - QrView: would not change. However in its usage for displaying addresses, it is expected to be in UOS introduction format, with extra information at the end (either a chainId or a genesisHash)
• - QrScanner:
  • - convert rawBytes from RNNative to U8a (Unit Tested)
  • - strip padding, length, frame info (Unit Tested)
  • - parse address, crypto (if substrate), payload, data as per UOS specification (Unit Tested)
  • - encode address from bytes to ss58 (Unit Tested)
  • - merging in from the identicon PR thank you @Tbaut for this one!
  • - decode SCALE payload
    • - Cold Signer SHOULD decode the transaction details from the SCALE encoding and display them to the user for verification before signing. (Unit Tested)
      • payload MUST be the SCALE encoding of the tuple of transaction items (nonce, call, era_description, era_header).
      • payload_hash MUST be the Blake2s 32-byte hash of the SCALE encoding of the tuple of transaction items (nonce, call, era_description, era_header).
      • immortal_payload MUST be the SCALE encoding of the tuple of transaction items (nonce, call).
    • - Cold Signer SHOULD attempt to decode the message as UTF-8 encoded human readable string by whatever heuristics it finds suitable (Unit Tested) and display it to the user for verification before signing.
    • - Cold Signer SHOULD warn the user that signing a hash is inherently insecure, in the cash of type 01.
    • - Cold Signer SHOULD (at the user's discretion) sign the message, immortal_payload, or payload if payload is of length 256 bytes or fewer.
    • - If payload is longer than 256 bytes, then it SHOULD instead sign the Blake2s hash of payload.
    • - Cold Signer SHOULD display all account id values in SS58Check encoding. [Substrate accounts management #293 - It should be stored in AccountStore as such]
• - ScannerStore:
  • - setDataToSign with appropriate native method based on network type, i.e. was crypto field defined (substrate) or not (eth) (Unit Tested)
  • - setTxToSign with appropriate hashing method based on network type. keccak for Ethereum, sr25519 or ed25519 for Substrate.

[maciejhirsz]

I don't think this will work for you, as @parity/qr-signer depends on web APIs for the webcam.

[pmespresso]

### Sign Message	### Sign Hash	### Sign Extrinsic Payload

[pmespresso]

Multipart will be a separate PR, though the logic is there I have no way to test them atm

[hanwencheng]

Could you please rebase the project on master so the commits on master will not be shown here? Then it will be clear to check the differences.

[pmespresso]

yes, doing this now

[maciejhirsz]

Found one issue, some other grumbles.

[maciejhirsz]

Tip: you can silence capturing groups with ?: inside parenthesis. With regex /^(\w+(?: \w+)*)?((?:\/\/?[^/]+)*)(\/\/\/(?:.*))?$/ you can then simply do [, phrase = '', derivePath = '', password = ''].

[maciejhirsz]

Merging artifact

[maciejhirsz]

password here includes the /// (if it exists), but every time you construct a suri you also add the slashes. This means the slashes will be included in the suri, which will lead to //////password. Edit: my mistake, slashes are stripped.

I'd recommend having two functions here: one to convert a suri string to an object, and another to convert the object to a suri, next to each other so the logic that does the conversion is contained next to each other in a single file, is easy to audit. Avoid constructing the suri string in any other places for security. This is pretty critical, people can lose money if their derivations don't work as expected.

[pmespresso]

moved to #325