In an ideal world, users of ElectrumSV could participate in IP to IP transactions directly. This is a more natural model, as ElectrumSV is not a hosted wallet service — like the other wallets are. Our users cannot use a central service, as a relaying service or point of contact, because we don’t have one.
If ElectrumSV users can connect directly to each other to do IP to IP transactions, then they can also use this connectivity mechanism to do direct payments, building on or if it comes to it, bypassing Paymail. Ryan X Charles, who has a better memory than I, recalled the references made to IPv6 by Craig Wright, and suggested it might be useful as a solution for something like this.
Is IPv6 ready?
After doing quite a bit of reading of related material, I thought I might try a few things out. So the first step is to see if my computer had an globally accessible IPv6 address.
Nothing there, let’s look directly at the internet connection.
This is the key problem with IPv6. I need it to work everywhere, and I need the users to not even know it is being used. And it isn’t there yet. This means that any IPv6 support becomes a luxury feature that we use in addition to the real solution that actually works everywhere.
This relegates IPv6 to a nice to have feature, that comes second fiddle to the must have features that actually do the job. From this point on, any research is just for the sake of education. We’re looking for an solution that an application can build on, and this isn’t it — yet, at least.
How might IPv6 be used?
Ideally, what I would want from IPv6 is the ability to allocate temporary addresses. And that’s actually one of the things it promises, but this reinforces my suspicion that IPv6 is mainly intended for the benefit of servers and not applications. When a server creates a new address, it does so authoritatively and does not need permission to do so. When an application wants to create a new address, it requires permission to do so.
IPv6 calls the ability to allocate addresses stateless address autoconfiguration (SLAAC). One example of this in use, is in IPv6 Battleships. But one thing you’ll note, is that it requires root permissions. Now multiply that requirement by five, one time each for MacOS, Linux, Android, iOS and let’s not forget Windows. I suspect MacOS is not alone in requiring administrator access to be able to allocate extra IPv6 addresses. It’s not looking good for applications being able to build on this.
One aspect of IPv6 talked about by Craig, is cryptographically generated addresses (CGA). In theory you can use a Bitcoin key to generate an IPv6 address. But that’s a bonus feature, and besides it isn’t really supported either.
It’s not looking good for IPv6. At worst it is an act of charity, burning time contributing to the IPv6 ecosystem so that something is there waiting to be used in 2046 when the rest of IPv6 ecosystem is ready to use it. And at best, maybe it can be the a minimally used first option to try from a list of more reliable fallback options for direct connectivity between ElectrumSV users. And that’s assuming that we forgo our limited development time being spent on something else, to spend it on the undependable IPv6 option instead. IPv6 becomes a luxury, and if the “fallback” options work well enough why would we bother even implementing it.
Source address selection
If we were able to allocate ad-hoc addresses, then something to consider is what if other applications went to make an outgoing connection, and the operating system used them instead of the one it allocated itself. If we are adding addresses for privacy reasons, we want to reserve usage of them for those purposes.
On Linux, this appears to be enforced with aliases. Your primary address, I guess, is not an alias. And the custom ones would be created as aliases, excluding them from source address selection.
For Windows, this appears to be a specific parameter. If the Powershell commands are used, then the SkipAsSource option can be passed to ensure that they are excluded from source address selection. It is likely that non-Powershell options have the same option available to them as well.
Moving forward with or without IPv6
In the unlikely situation your machine has a global IPv6 address, and the other person’s machine has a global IPv6 machine, then you can in theory talk directly to each other. Add the cases where you have local addresses on the same network. And that should be pretty straightforward for us to try, just exchange addresses and make a connection attempt. So if we do direct wallet to wallet connections using something that is dependable and ubiquitously available, then before we try that — we could try IPv6 first.
Even if we build a solution on IPv4 that does it’s best job at working around whatever the standard problems NAT causes, chances are that we’d need a server to relay messages for those people whose connections we can’t work around. And this more and more pushes us towards needing to run a server for this and more.
So IPv4 research is next. If you’re an expert on reliably connecting to users who are behind firewalls, get in touch. Last I heard IPFS still required nodes that relayed between firewalled parties — so I don’t have much faith that this is a solved problem.
Here’s another question, what is the most common situation where users will want to do IP to IP transactions? Is the internet the best method of communication between their wallets? What if it is where two people are standing close to each other, if so maybe Bluetooth might be a better investment in time. Or NFC. That’s another area that would benefit from research. Although maybe for a desktop wallet, the internet is actually our best place. Mobile and browser versions of our wallets are way down the list.