Exploring wallet connectivity

Direct payments benefit from having a fallback solution that always works, when the user has an internet connection, and wants to make a payment. But beyond that, there are unexplored areas I need to try and map out.

The goal is to try and come up with a more or less accurate picture of the possibilities. I’m not going to spend a lot of time on this, it just has to be good enough for me to feel confident it provides a good enough model. If you can help flesh out or correct the model, then please get in touch. Methods of contact are provided at the end of this article.

How do we communicate?

Let’s go with the following three steps. It might be that some methods of communication can be used for some of the steps, but cannot be used for other steps. This might mean we would use one technique for the first step, try other techniques for the second step, and settle on a final technique for the third step.

Determining how to communicate

We have two devices. One way is to have one device to tell the other device all the different methods of communication it supports. Another way is for a device to simply try all the different methods of communication, but this isn’t necessarily always possible.

Establishing communication

In the simplest case, a device has guessed and tried a suitable method of communication, and will proceed to exchange data with it. In the more complex case, a device has obtained all the methods of communication from the other device and will iterate through them based on an order of preference. It should be able to find a suitable method which it successfully uses to establish a communication channel, over which it will exchange data.

Exchanging data

Some methods of communication might be more suitable to aid in finding out about the methods that can actually support exchange of data.

Direct payments

The data needs for this are not just the negotiation of the payment. The payer will receive payment details from the payee, and will provide one or more transactions that meet the requirements. The payer may also have to provide headers that the payee does not have, and the transactions that include their inputs, and the merkle proofs for those transactions that link them to a block. I have no idea how much data this can come to, but it might be more than a little.

Arbitrary data

The wallet can use this mechanism to establish encrypted communication between the two parties, perhaps using their already know identities to secure it. There are many possible applications, and not all are simply direct payments.

In-person connectivity

How do two people that are in physical proximity make a direct payment? It is assumed that they wish to make it without using the internet, or the internet is not available. I think it’s an interesting question whether any of these options can be easier than using the internet-accessed servers to facilitate connectivity — especially for ElectrumSV in it’s current desktop form.

QR codes

QR codes are already supported. But this is awkward for desktop computers, consider what the users have to do to make it work. They would need to hold two laptops (or one laptop and a proper desktop) so each can see the other’s screen, cameras facing each other. Still, you can get 406 bytes of data in a QR code apparently, or up to 2953 bytes. That’s a decent amount and it just relies on screens and cameras being in proximity.

It is only slightly less awkward if used for the devices just to determine alternate ways of communication. If the desktop devices have to be held there and they need to flash more QR codes back and forwards, and they need user interaction, well, it’s getting somewhat ridiculous.

If one device is a handheld device, then perhaps this becomes not so ridiculous and almost acceptable, as the handheld device is readily movable when necessary. So perhaps in that case, using it for data exchange is practical — if the need arises where there is no better option.

A solution might be to make a mobile application that connects over Bluetooth to the desktop running ElectrumSV, and displays and reads the QR codes on it’s behalf. That would make the QR code communication a order of magnitude less awkward. Do we have the manpower to do this? Not at this time, but it’s an option. Likely any such application would not just do this, but further things to extend ElectrumSV to mobile devices — even if it wasn’t a full blown wallet itself.

One thing the QR code can do, which is very useful, is share a signed identity. This is important because it is less likely that if the identity is know beforehand, or established via a secure channel, that the connection can be intercepted.

Chirp

We do not currently support Chirp, and I am not sure if it is practical to do so, given that it is a licensed product. But if we did support it, given that two devices can communicate data using inaudible sound, how useful would it be? In theory, it could allow one device to tell another how to communicate and even perhaps a signed identity, without requiring physical lugging about and alignment of devices for QR code reading.

First let’s look at how it can be used to transmit data. At NFC range, it can transmit 125 bytes per second. At 3 meters range, it can transmit 18 bytes per second. Well, NFC range probably requires some of the awkwardness of QR codes. But two devices held next to each other might be able to get 80 bytes per second, just guessing. That’s workable for either exchanging connection details, but perhaps not exchange of data.

I’ve never used Chirp, and I am not sure if we can include it in ElectrumSV, but if we could it would add another tool to build on that could change the experience.

LAN

If there is a local area network, and both devices are on it or their users believe they are, then the devices need to discover each other.

The user reads and copies the addresses

A device can enumerate the addresses it is available on, and display them to the user. In the technically simplest but somewhat tedious scenario, the other user can type them in. The IPv4 address is tedious to type in, but not painfully so. The IPv6 address gets more painful, to read and type in.

The addresses are encoded in a QR code

Is it less painful to transfer these by typing them in and trying them, or to maneuver the devices around to let one read a QR code from the other? The chances are that one device is a laptop, so if it were me I’d probably just hold it up to the other computer to forgo typing.

Network discovery

The devices should be able to use some method to discover other devices on the LAN, and if they can do that, they can then easily identify if a device they are looking at is the one they want. You can get existing tools that detect an IP range for the network, and scan those IP addresses and try and analyse what is on them. Networks that support IPv6 may have some form of discovery, perhaps multicast based, that can be used first.

Final thoughts

I don’t really feel like there is a clean solution to this yet. All the solutions above are awkward. If the two devices are on a LAN, then perhaps network discovery is the simplest option.

How often will two people want to make payments using a desktop wallet anyway, where there isn’t a network connection?

Really, the path forward for non-internet wallet communication seems to be a mobile wallet for ElectrumSV. That adds a lot of new possibilities, for less awkward device connectivity. But it’s also not yet on the horizon.

Further discussion

As always you can contact us in the #electrumsv channel on either of Unwriter’s slack, or the Metanet ICU slack (if you are a member with access). Twitter is a painful platform to use for discussion, so do not expect any discussion initiated there.