Following the discussion at Devcon that involved initially me, @ligi, @p0s, @ricburton and @airgap we were looking to create a standard for Offline Signing currently supported by Walleth, Parity Signer, imToken Wallet and AirGap.
In order to achieve this there are 3 interactions that require URI standards for displaying QR Codes that can communicate between the online and offline device:
Main considerations to have when drafting these 3 new URIs are that they should clearly identity the chains that they are targeting (using chainID), potentially drafting a blockchain agnostic standard and also including message signing support would be beneficial.
Currently there is a Ethereum standard for formatting URIs - EIP 831 - which would be useful for this use-case but it needs to account for other blockchains compatibility to allow Wallets to support non-EVM based blockchains that might have this Offline Signing functionality.
Hey! I’m not in Paris, so I’ll just pitch in here.
I intend to post a standard proposal for offline wallets using QR codes that will be used by Parity Signer, which will also be extensible to non-Ethereum networks.
I’d strongly advise against using the URI. Couple reasons:
There is absolutely no reason why this format needs to be human readable. Nobody can scan a QR code with their eyes, you need an app to scan the QR, and if you’re already using an app, you can have the app decode the format used.
QR codes are very sensitive to the amount of data you want to show on them, with bigger loads producing higher resolution images that are problematic to scan with cheap cameras paired with low power CPUs. You want the format to be as concise as possible, especially since transactions on ethereum are variable length and can be large.
Given 1 and 2 - Ethereum already has a concise format for representing transactions: RLP. It’s well documented and libraries for handling it exist in plenty of languages, so there is no need to re-invent the wheel here.
RLP also guarantees that what we hash and sign will be exactly the same thing that will be then broadcast to the network. There is no ambiguity or room for error that could arise if we were to construct the RLP on the side of the signer form an intermediate format.
ERC-681 is hardly suitable for this task (it would require custom parameters to be attached, which could lead to implementation differences). ERC-831 is generic and could be adopted, but at this point we again have to invent a format that duplicates what RLP is already doing.
the issue with nod using an URI is that the user needs to be in the correct app/state to scan. By using an uri - the user can use a generic scanning app to initiate the process. So I strongly signal that using an URI for at least step 1 is considered.
You then have to have an option to paste the URI into your signer app somehow, which means that either:
The device that you are storing private keys on is online, or:
It’s offline, but for some reason you have another app for scanning QR codes next to it.
Also ERC-681 lacks the address with which you want to sign the tx, you’d have to pick that in the signer app, which is a UX hurdle, or add it as a custom parameter. Just the fact that chunks of the URI are optional and parameters can be custom goes against the “Unambiguous” part of the design - the whole signing is only valid if both apps produce the exact same RLP out of whatever flies over the QR.
not proposing to use erc-681 here - but something custom to this use case building on 831. Or even something completely custom (with a different/shorter prefix) so more bytes can be shoved off the QR code. Perhaps with a really short scheme like wc for walletconnect …
Yeah, my thinking always goes the same route. The requirements pretty much demand a custom solution, so if we are going to engineer one, why not do one that is actually designed for this use case specifically and address all the issues (QR code resolution constraint and size limits).
I’ll look at the walletconnect, but as far as I can tell it is a very different use case, where you are also more likely to use a new phone.
I’m really pushing for the small QR codes, because my current test device for development is a samsung galaxy s4 mini, which is comparable in price to a ledger, and scanning QR codes with that thing is a pain . I reckon if people are to build dedicated hardware for this (and some are planning to do something very similar already), they are not going to put 12-megapixel iPhone X cameras on it.
I totally love the push for small QR codes! This is often overlooked and then produces problems in real world use cases - totally on your side with this.
Still think leveraging URIs could be of benefit as it adds context of what this QR code represents and e.g. allows the use of 3rd party scanners.
WalletConnect was just an example of a short schema (wc) in order to save bytes.
So perhaps we can use ot: (offline transactions)
the initial qr-code could look like “ot:address@chain”
we can drop the 0x for address and make the chain hex to save bytes.
OK we still would have this 37.5% overhead - but I think this is OK as I think the added context is worth it.
Or you could go with Binary UTF-8 and use base64 or base58, both of which have (slightly) smaller overhead. Whichever you do though, at this point you have something so custom I don’t really see an advantage in using URI-compatible format over just prefixing things with raw bytes.
Ah, right, I see. So you could say slide into the default camera mode, scan the QR code and have it just open the signer app. We could use short a URI prefix and then keep everything else binary with base64/58/whatever.
I’d like to know if anyone has done any UX research if that’s something people are likely to do. I haven’t seen any users complain about it to us with the signer (which is using the non-URI JSON payload atm).
yea - but data URI’s are URIs - so there is no problem there.
With intent-filters I can match e.g. on a scheme - basically on parts of an URI. But I cannot inspect binary blobs or json. You cannot have custom code there - just matchers which are quite limited