0005 XLS-5.1d NetworkID extension to X-Addresses

[RichardAH]

  XLS-5.1 - XRP Ledger Proposed Standard #5.1

  Title:        Tagged Addresses with NetworkID
  Author:       Richard Holland (XLS-5.1)
  Affiliation:  XRPLF, XRPL-Labs
  Created:      2023-11-02

  Base Standard:  https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0005-tagged-addresses (Nikolaos D. Bougalis)

Introduction

X-Addresses provide a way to encode all relevant payment endpoint information (r-address, destination tag / no destination tag) in a single user-friendly, checksum-protected address format. This is primarily intended to prevent users sending funds to exchanges without including the correct destination tag.

However, with the recent release of the Xahau network and planned further expansion of the XRP Ledger Protocol ecosystem, there is now an additional, highly relevant, piece of payment endpoint information: destination NetworkID. Without this information users (or their wallet software) could accidentally send to the same endpoint but on the wrong network.

Extension

The XLS-5 standard is base58 encoded packed binary containing a destination account ID, destination tag (or deliberate absence of a destination tag), and a flags field. In this updated standard we now provide a way to encode the Network ID.

To signal a NetworkID has been included as a little endian encoded UINT32 as the final 4 bytes of the packed data we now set the most significant bit (0x80) on the flags UINT8 high.

Further, we deprecate the T prefix mode of X-addresses. Thereafter all X-addresses that lack NetworkID are assumed to refer to XRPL Mainnet (NetworkID = 0).

Finally, we deprecate the 64bit destination tag flag, to make parsing easier for libraries and because no implementation of the XRPL protocol supports 64bit tags.

[← 2 byte prefix →|← 160 bits of account ID →|← 8 bits of flags →|← 32 bits of tag →|← 32 bits of NetworkID →]

Revised Format Table

For ease of lookup here is the complete revise format table:

Byte Offset	Length	Field Name	Value	Explanation
0	2	Identifying prefix	0x0544	This produces a leading X when encoded
2	20	Account ID	<20b AccountID>	The destination Account ID
22	1	Flags		Information about the format as below
			0x00	No destination tag. No NetworkID.
			0x01	Destination tag present. No NetworkID.
			0x80	No destination tag. NetworkID present.
			0x81	Destination tag present. NetworkID present.
				All other flag combinations are invalid.
23	4	Destination Tag	<4b dest tag>	Little endian. If no destination tag is specified by flags, this must be 0x00000000
27	4	Network ID	<4b NetworkID>	Little endian. If no Network ID is specified by flags, this must be 0x00000000

[mvadari]

Why remove the X vs T prefix? I like that I can tell at-a-glance if this account holds real funds or fake test funds.

[sublimator]

Definitely see the value of that in principle - but ideally can be sure the visuals match what's actually encoded

[sublimator]

but ideally can be sure the visuals match what's actually encoded

Hrmmmmmmmm

[sublimator]

You all are planning to support addresses that work across networks eh? Is that really wise? I mean you have NetworkID/Sequence transactor level protections but still ?

Without a clear disambiguator for ANY network family at the front, what's the point of disambiguating the class of network?

Cause you're going to need to show the network in the UI somehow anyway? Assuming you support multiple XRP based chains?

It's a question of "does the sending network id (surely shown and/or selected in the UI) match the recipient network id ?" 

[WietseWind]

@sublimator Network should either be visible in the UI, indeed, or the app & audience completely abstracts it away for the end user & the app would know what context to use based on the address with the network being encoded. In those cases the address will probably even be abstracted away anyway using any of the million naming/resolve schemes.

Crypto context: app switches to the right network & offers the right context based on the address.

Retail context: app takes care of everything. Address most likely passed with some human readable / QR / BLE / ... & then resolved / ... - if app supports and moves on with a retail friendly flow. It's not unlikely a certain app+end user interaction touches multiple networks. A destination address in those cases signals where to deliver, not even specifically which network it has to come from.

[sublimator]

I think the only thing I can say without thinking about it more (and playing with some UIs) is that it seems somewhat pointless to have "human readable" prefixes unless they are meaningful and can be trusted? Ideally the prefix would visibly encode the network id. Devil's in the details though.

not even specifically which network it has to come from.

Interesting

[MarvinSunday]

It's a good and it will help avoid sending funds to wrong network now that the XRPL Community is expanding.
Great work!