LNURL, Not PayString

The Travel Rule Protocol (TRP) working group, of which we are a leading contributor, designed an elegant solution for the address- and VASP- discovery problem, an important challenge in any Travel Rule solution. In short, the problem can be summarized to the question: How can an originating VASP discover to what address and what beneficiary VASP it needs to send coins? TRP solved this with the Travel Address, which is based on the LNURL standard.

Often there are questions about why LNURL was chosen as the solution and not one of the alternatives such as PayNym, BIP75, OpenAlias or PayString. Why indeed an existing standard at all?

The goal of the TRP working group is to provide a minimal, pragmatic solution for the FATF Travel Rule guidance. Off-the-shelf standards like InterVASP IVMS 101 fit the requirement. In a similar vein, the group set out to find an existing standard fitting the requirements instead of re-inventing the wheel.

Of all the existing alternatives, PayString and LNURL were close contenders. Both have existed for some time, and both do what we need them to do; they facilitate the exchange of a piece of text for a cryptocurrency address and a beneficiary VASP.

A PayString looks like this:

1
bob$digitalwallet.com

While a LNURL looks like this:

1
LNURL1DP68GURN8GHJ7UM9WFMXJCM99E3K7MF0V9CXJ0M385EKVCENXC6R2C35XVUKXVS89HM

Both are very different from the looks of it, but the similarities are significant. A PayString looks like a URL and can be transformed into one. The LNURL does not look like a URL but can be transformed into one nonetheless. An LNURL is merely a bech32 encoded URL!

Advantages of LNURL over Paystring

Encoding

While the human-readable format of PayString might seem like an advantage, it is not. Having a human-readable format lends itself to reuse, which is not always desirable. A beneficiary VASP might want to restrict the validity of a URL to one time due to its risk assessments. A human-readable format also opens up the possibility of nefarious substitutions like this one: bȯb$digitalwallet.com. Note the tiny dot on the letter ‘o’! This is a common attack when using URLs on the web, and although we think it is harder to pull off in this use case, we felt that the upside of a human-readable format did not outweigh the potential security risk.

Interactivity and Fallbacks

The conversion of a PayString into a URL involves an interactive protocol between the originator VASP and the beneficiary VASP. While simple and supporting a fallback mechanism in case the interactive protocol is unavailable or fails, it is undeniably an additional complexity. With an LNURL, the originator simply decodes the LNURL from which it will arrive immediately on the final URL. No interactivity is required, nor secondary fallbacks.

Adoption

Finally, the LNURL standard is widely used in the Lightning Network, Bitcoin’s layer 2 network. This ensures ongoing development of the standard, and security issues are monitored by many. PayString, on the other hand, seems to enjoy little popularity outside the Ripple network, thus lacking the features LNURL enjoys.

Hence, LNURL was the chosen technology to facilitate Travel Rule information transactions. That is not to say that individual VASP can't agree on something else. TRP facilitates this with its flexible extensions mechanism.

* Since the conception of the Travel Address, the TRP working group - of which we are part - has worked at improving its design and functionality. Initially, the Travel Address was inspired by the LNURL standard but has since been reworked. 

Now, the Travel Address is a base58check encoded unique URL with a string prefix of “ta”. Base58check results in shorter strings than bech32 (used in LNURL), and it does not have a maximum length limit. Additionally, with the prefix LNURL in the Travel Address, parties not familiar with the LNURL standard automatically linked the LNURL Travel Address to the Lightning Network, which was not accurate.