Info collection about Jamtis addresses, with focus on the issue of their length

TL;DR

Jamtis addresses as now designed double the length of current Monero addresses and approach 200 characters. Much thought and much discussion among Monero Research Lab members went into this, that length increase did not "just happen", and the new addresses solve quite a number of long-standing issues with the current CryptoNote style Monero addresses. While going through everything I did not meet any good way for a significant length reduction without losing important added functionality. With the increased length on the negative side, I try to argue that so many improvements are on the positive side that it's worth to "swallow this toad" and it's a good way forward to start thinking how to build good user interfaces and achieve a good user experience for them.

The Issue

If we implement Jamtis as currently designed, Monero addresses will get longer. Their length will increase from 95 to nearly 200 characters.

As addresses are of course a fundamental element of the cryptocurrency that all of its users will have to deal with, doubling their length is certainly a serious issue.

In this text I try to explain how that comes to be and what positive effects we get in exchange of the length increase as a clearly negative effect.

The Status Quo

Monero addresses currently are 95 characters long. These may already be the longest cryptocurrency addresses in wider use today. They are a feature of CrypoNote, the system that Monero inherited when it forked code back in 2014, and this part was never modified as far as the length and the content of the addresses is concerned.

Here an example of such an address:

4BJL9uzgcMkLEPTQMDSjRJAMwnNhoDt96UkSJoYsm5CQfJxgix
18vBjYNzWTMUnhyYg2jFsEPW5M2N34K58d3uLCMbvLNEY

The "alphabet" used here consists of 58 digits and letters. This encoding system is called Base58, see e.g. here for details and how it compares to other such encodings.

Already these 95 characters are too long to display Monero addresses in full in most parts of the user interface in wallet apps. They usually resort to only display parts of addresses. The Monero GUI wallet would, with a small size of its window, use the 4 first and the 4 last characters to display the sample address in lists of transactions done as:

4BJL .. LNEY

With a larger window it would add 2 such groups of 4 characters and display:

4BJL 9uzg .. CMbv LNEY

As it's very unlikely to have 2 addresses with the same 4 first and 4 first last characters, it is usually considered "good enough" to display them this way in lists.

It seems unlikely that people really type in 95 characters frequently when they want to send XMR somewhere, as that would clearly be a pain, and also hard to get right on first attempt. Typically you cut and paste such addresses, or read a QR code to get them.

Thinking about it I wonder why I never read any serious complaints about the length of current Monero addresses, and no FAQ along the line of "95 characters are too long. Can't you make that shorter?". Seems to me people cope mostly fine today.

The Proposed Jamtis Addresses

Jamtis tries to solve quite a list of serious issues with the current CryptoNote system that became clear over the years. I will detail the relevant ones further on. As far as addresses are concerned it proposes a quite radical break with the past and arrives at clearly different, and much longer, addresses.

Here an example of a Jamtis address that I took from @j-berman 's excellent and highly recommended presentation about Seraphis and Jamtis (direct PDF download link here):

xmr1majob1977bw3ympyh2yxd7hjymrw8crc9kinodkm8d3wdu
8jdhf3fkdpmgxfkbywbb9mdwkhkya4jtfnod5h7s49bfyji193
6w19tyf396ypjo9n64runqjrxwp6k2s3phxwm6wrb5cob6c1nt
rg2mugeocwdgnnr7u7bgknya9arksrj

This sample address does not yet reflect a recent modification that makes addresses a bit longer still and pushes them to almost 200 characters, but that does not matter too much, as you get the right impression nevertheless.

I followed design work on Jamtis in 2021 and 2022 and took away the impression that all important aspects of these new addresses are well thought out, and they were discussed among MRL members to quite some extent. In the following I will try to argue that those addresses don't just happen to be so long, and that you could not make them shorter without losing important features.

The Case for Base32

You may notice that Jamtis addresses use a different "alphabet": The mix of uppercase and lowercase letters of Base58 is gone, all letters are lowercase. It's called Base32 because only 32 different characters are used. You find details e.g. here.

Base32 needs somewhere between 15% and 20% more characters to encode the same information than Base58. So what's on the positive side of 35 or so characters more?

With using Base32 Jamtis follows a very carefully designed "second-generation" system for addresses called Bech32 that comes from the Bitcoin world. You find info about it e.g. here.

One advantage of the reduced alphabet is better QR codes. As you can read here QR codes have several so-called input modes. If you use uppercase as well as lowercase letters you have to use binary input mode with 8 bits per character. If you don't need casing you can use alphanumeric input mode with ony 5.5 bits per character. (Of course there are no "half bits", 2 characters go into 11 bits.)

So with Base32 you can either make the QR code quite a bit smaller, or you can use better error correction if you keep the same size.

A second important advantage is the possibility to use a better algorithm for the checksum. As the linked Bech32 page mentions, most of the research on error-detecting codes only applies to character-set sizes that are a prime power, which 58 is not (but 32 is, being a power of 2, a prime). Jamtis addresses can use a checksum based on polynomials that are quite easy to calculate, in any case easier than hashes that are used for current Monero addresses, but still allow very good error detection. Readers interested in technical details find them e.g. here.

You may see the trade-offs "more characters versus better QR codes and better checksums" differently than the Jamtis designer and the MRL members, but the important points to take away in my opinion are that as already mentioned much deliberation went into this design, and changing it would have a number of consequences.

The Third Key

Current Monero addresses contain 2 public keys of 32 bytes of information each. Jamtis addresses contain a third such key which contributes to the increased address length to quite some degree.

As you can read in the MRL issue 92 about address schemes the third key was born to mitigate Janus attacks. (With Jamtis we are on the Janus B line of that table listing possible address schemes.)

In short, a Monero wallet can have several addresses where ideally there would be a water-tight guarantee that it's impossible for any outsider to determine whether two addresses belong to the same wallet or not. As Janus attacks show it's not possible to give such a guarantee for current Monero. The third key in Jamtis addresses closes the "hole" in the system and so increases privacy.

Subsequent work on Jamtis and Seraphis showed that this new key can also be used to achieve other solid advances like faster scanning of the blockchain and making third-party scanning services possible that can't see the amounts of the enotes they find on behalf of users.

Again, nobody just threw in 32 bytes more in the form of a third key because they thought that might be cool, without caring about the length increase. The third key allows significant improvements, and dropping it would cause a lot of things to slide and need a significant re-work of the design.

Address Tags

Jamtis addresses as currently proposed contain an address tag of 18 bytes that like the third key is a significant factor in the length increase.

Originally only 8 bytes, a quite long discussion to widen it to 18 bytes starts here in the comment section of the Jamtis design "paper".

What do we get in exchange for so many bytes?

With current Monero there is a potential problem with receiving funds to subaddresses that are "far away" from the "highest" subaddress that is currently used (the wallet may never see them and they might as well not exist), and in general a wallet internally has to generate a quite large so-called look-ahead table of potential subaddresses to check for incoming funds even if everything goes as expected, which complicates matters. Those 18-bytes address tags completely eliminate the potential receive problem and the need for complicated "look ahead".

When merchants have to track payments from customers the advice for a long time already is to use a separate subaddress per order or at least per customer. Generating subaddresses as part of a software for merchants has proved to be anything but trivial however. For example with current Monero you can't just randomly generate subaddresses because you would run into the mentioned receiving problem, and the space of possible subaddresses is not big enough to guard against generating the same subaddress twice by bad luck to a sufficient degree. You have to track what you generated already which can get quite hairy if e.g. you need multiple servers for a high-traffic system. (These are reasons why integrated addresses are still around despite being declared "deprecated" by the Monero dev community.)

Again, the wide address tags fully do away with these problems, and there are no integrated addresses anymore in Jamtis, because no longer needed. Merchant systems can almost trivially generate subaddresses at random with a similar protection against duplicates as the well-known GUIDs and can be sure to receive any funds sent to those without any difficulty.

Possible Hardware and Software Limitations

While discussing the long Jamtis addresses in the No Wallet Left Behind Matrix room the question came up whether there is hardware that is so memory-constrained that we will run into trouble. Two candidates mentioned are NFC tags and hardware wallets.

It seems that there is a bewildering array of standards for NFC tags and corresponding actual hardware. See e.g. here. The impression I got is that while low-end tags may indeed lack the necessary 200 bytes to hold even a single Jamtis address other tags can do so comfortably, with room to spare. It may be a question to choose the right tags if you want to implement something Monero related then.

How it looks with hardware wallets is hard to say. They probably don't have problems already with merely addresses, but maybe with firmware capacity to hold the code for supporting Seraphis and Jamtis in general. If that really was the case, and if we put high priority on hardware wallet support, the ultimate consequence would probably be to postpone the hardfork altogether until hardware wallets have grown powerful enough. This seems like something hard to get consensus for to me.

Anyway, if I look at the just introduced Ledger Stax hardware wallet, I think there is hope that in two years' time there will be a healthy choice of hardware wallets capable of supporting the "new" Monero.

Two other things that we probably should keep an eye on are DNS TXT entries for https://openalias.org/, the system that lets you use nice names instead of Monero addresses, where a single such TXT entry has a maximum length of 255 (but multiple entries are possible), and transport of unsigned transactions for "cold signing" using QR codes (multiple are needed today per transaction, but probably more will be needed with Seraphis and Jamtis).

RIDs

According to the Jamtis spec RID stands for recipient ID. For every Jamtis address you can calculate such an RID which looks like this:

regne-hwbna-u21gh-b54no-8x36q

Despite their short length it's very improbable to have two different addresses that have the same RID by chance, and it's very hard for an adversary to actively find a second such address e.g. as part of an attempt to scam you.

Instead of comparing Jamtis addresses over their full length of nearly 200 characters which is of course a pain, and instead of only comparing a few characters coming from the start and the end of the addresses which may not be reliable enough, you can safely and easily compare the RIDs of two Jamtis addresses to see whether they are identical or not.

They can't replace Jamtis addresses however; you can't send XMR using the RID instead of an address.

You could say that an RID is a human-friendly checksum for Jamtis addresses.

Compared with deeply ingrained parts of the Jamtis spec like the third key and the long address tags we might be able to explore other ways of arriving at such a human-friendly checksum without causing havoc, if needed, but in any case it looks confirmed there are suitable ways to have something short enough that we can display as part of wallet user interfaces.

My Personal Conclusion

As mentioned seems to me already our current 95 character addresses are rarely ever typed, and mostly transported using the clipboard or QR codes. You can easily do that with addresses that are two times current length or even longer so no fundamentally new approach to handle them is needed. We have almost weekly posts about Monero problems like slow sync or wrong restore height in the Monero subreddit, but hardly anybody ever complaining about our long addresses which in my opinion wants to tell us something.

The textual representation of my public PGP key is over 1600 characters long, but nobody seems to see such keys to be a serious UI/UX obstacle.

Of course it would still be pretty dumb to burden ourselves with addresses that are 200 characters long if we could get the same benefits with substantially shorter addresses, or if the added benefits turn out to be less great than assumed so far. But after going through much of the available info in preparation of writing this text I encountered no good to way to shorten significantly, and no candidates for features that we could take out of the spec again to arrive at shorter addresses.

My personal take on this matter is therefore: Let's swallow that toad and use features like RIDs and perhaps additional ones not yet invented to arrive at good user interfaces for wallet apps and websites to deal with 200-character Jamtis addresses as currently designed.

But for sure I am just a single voice in the Monero community, and I hope that the material presented here can serve as a good base for discussion and arriving soon at some "loose consensus" how to go forward regarding addresses.

seraphis-migration / wallet3