path: root/86/1039e16e17898fb9d6a107c23ae936e197f3cf

Return-Path: <ty@rubix.io>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7153FC0881
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Dec 2019 03:26:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 633DF8527F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Dec 2019 03:26:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id aCMiilL6IdDu
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Dec 2019 03:26:41 +0000 (UTC)
X-Greylist: delayed 00:06:22 by SQLgrey-1.7.6
Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com
 [209.85.214.193])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 6C36284FC0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Dec 2019 03:26:41 +0000 (UTC)
Received: by mail-pl1-f193.google.com with SMTP id g6so7953842plt.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 Dec 2019 19:26:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=rubix-io.20150623.gappssmtp.com; s=20150623;
 h=from:content-transfer-encoding:mime-version:subject:message-id:date
 :to; bh=Bg1y4P5lVntS3W1JXrWAMTJduE2R3RBdcEoOdWCFpSs=;
 b=sr1hHVi+/4G+Kq3G/lZu5ak7FyfFlKiu4PHL+iJAziqn1W5ikx+33S6d160Hsy+BVg
 2+tw4YOUJa3MEJ4kFjeB9DH2AUZWVGJTtOYvyJak5vMTYegXBN67p05itC/w4K+vUEGt
 C4boDpaiCju+cXNa1PpjJnsds0XqAx07zCJGn6257f0jcFHND3c1khAJ4tCXlCfgH12I
 5GSEwLIvWLmz3HqsMwTIMoaEr+npN0I/DQjkkwz+2rigkL1LFL9M+OIMNKxb3qrtSyef
 pqmRE/OLQEjJnKzomSAmlnM/IBPhFMwC1II86WdhVyGNk+q+t34wUyr1miMguNFFvkBl
 qPmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:content-transfer-encoding:mime-version
 :subject:message-id:date:to;
 bh=Bg1y4P5lVntS3W1JXrWAMTJduE2R3RBdcEoOdWCFpSs=;
 b=bTTyRfV7c8Uu7fZuHiKxRROlAuJh+McszgUEZ7NTB4Egi1vO5bzqPIMKHPWGD+jz31
 mUx+wlc67W6BISbVNgkjySotkLi1PdZQUTdN6PzIYL8G6MOkeU52z0HxJ7gnEchy0y5g
 ocb8P69IYOHoe1cmXvCA+Kxbs0MSMwcSBOU7tFyQ+3DB0oZkPqWgPIqJvnFRVyhS4T0+
 QxYSK7znEVHadH3qx53qXaOJG8K+J2Rl8o0feZXZlW/vDdzAY6A1PorJ7soBgqZJKtwZ
 3aIhlfq+19pknJUP8wFe2//sFYg2uNrahlrL7kt+8Dz1jYIhaLAcfuAq722a6QgrXQH+
 4X+g==
X-Gm-Message-State: APjAAAUn6/S4/6c9ywp7tKsSNEFhzL7Wd3Ue7JvUIZBzcKveyg8e7vI0
 +N66LMGbQe23sUc6FRxUM3wC+AHU6Go=
X-Google-Smtp-Source: APXvYqypYMJZ+0dJXiBW0ZNZwbBCWV95APwDXEjJECbz7zAL0xlzqonGqGvl0XUpNV9XoeN39jx78Q==
X-Received: by 2002:a17:902:aa46:: with SMTP id
 c6mr34413625plr.200.1577157617313; 
 Mon, 23 Dec 2019 19:20:17 -0800 (PST)
Received: from [192.168.1.3] (96-41-147-233.dhcp.mdfd.or.charter.com.
 [96.41.147.233])
 by smtp.gmail.com with ESMTPSA id x197sm27059639pfc.1.2019.12.23.19.20.15
 for <bitcoin-dev@lists.linuxfoundation.org>
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 23 Dec 2019 19:20:16 -0800 (PST)
From: Ty Everett <ty@rubix.io>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Message-Id: <D538E88C-4F34-4456-9803-EF6A40CBD8AE@rubix.io>
Date: Mon, 23 Dec 2019 19:20:15 -0800
To: bitcoin-dev@lists.linuxfoundation.org
X-Mailer: Apple Mail (2.3608.40.2.2.4)
X-Mailman-Approved-At: Tue, 24 Dec 2019 03:32:36 +0000
Subject: [bitcoin-dev] [New BIP]: Universal Addresses
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Dec 2019 03:26:43 -0000

I=E2=80=99d like to propose a new BIP for universal, multi-currency =
addresses. Until a BIP number is assigned, we can substitute it with =
${BIPNUM} wherever it is used. In the examples, I=E2=80=99ll use 3301 as =
the value for ${BIPNUM} when required to demonstrate BIP32 derivation.

```
BIP: ${BIPNUM}
Layer: Applications
Title: Universal Addresses
Author: Ty Everett <ty@rubix.io>
Status: Draft
Type: Informational
Created: 2019-12-23
License: BSD-2-Clause
Requires: 32, 43, 44
```

Abstract

A universally recognized and accepted cryptocurrency address format =
would allow merchants, exchanges and users to more easily coordinate =
transactions and conduct business. I propose a new address format not =
specific to any cryptocurrency that provides strong cryptographic =
security while maintaining or improving the level of transactional =
privacy specific to each underlying currency. BIP32 derivation permits =
compatibility with existing HD wallets, reducing implementational =
friction across the ecosystem. BIP44 numberings at the coin-selection =
level allow new coins to be used with the same Universal Addresses, =
while URL-style query parameters dictate which currencies a user prefers =
to receive.

As the Bitcoin and wider cryptocurrency community has matured, numerous =
address formats have been devised. Some projects use their own format, =
while others use base-58 or hex-encoded strings. Some even have =
identical addresses, creating confusion for users and a potential for =
the loss of funds. While each format has its unique set of advantages =
and disadvantages, they all have one thing in common: they are specific =
to a single currency and not to the user, who may or may not use and =
accept a great many currencies. I propose the use of BIP32 extended =
public key nodes as a Universal Address format, because no =
cryptocurrency project exists in a vacuum.

Copyright

This BIP is licensed under the BSD 2-Clause License.

Specification

Pre-requisite Knowledge

This BIP draws on concepts from BIP32, BIP43 and BIP44. The reader is =
encouraged to familiarize themselves with those BIPs before attempting =
to read and understand this BIP.

A Note on Annotations and Rationale in this BIP

Design decisions have been made with regard to many respects of this =
BIP. Where appropriate, annotations[1] have been added. Justifications =
can be found in the =E2=80=9CRationale=E2=80=9D section, along with a =
few explanatory Q&A-style points about potential implementation =
concerns.

A Note on Terminology Used In This BIP

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", =E2=80=9CSHALL =
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in =
this document are to be interpreted as described in RFC 2119.

Derivation Path Levels for Universal Addresses

Implementers of BIP${BIPNUM} MUST use the below BIP32 derivation path =
levels for Universal Addresses; apostrophe denotes hardened BIP32 =
derivation:

```
m / ${BIPNUM}=E2=80=99 / entity / coin / shield
```

Level 1: Denotes Use with Universal Addresses

The top-level derivation simply denotes the use of this node with =
Universal Addresses. Primarily, it=E2=80=99s purpose is to isolate this =
use-case from other uses of the same BIP32 node (notably BIP44 wallets).

Level 2: Recipient Determines Index of Address to Share

This is the level at which the Universal Addresses allocated by a =
recipient's wallet are to be split off; one for each sender to whom the =
recipient has given an address. Starting at index 1 (0 is reserved for =
future use), each Universal Address SHOULD be generated canonically. The =
keys generated at this level are the ones to be shared from the sender =
to the recipient. The recipient may then derive a level 3 key based on =
this key and the currency they wish to send. There is no need for the =
sender to obtain a new Universal Address from the recipient for each of =
their subsequent transactions.

Level 3: Sender Selects and Derives Address for the Currency They Wish =
to Send

The sender receives the level 2 key from the recipient formatted as a =
Universal Address (see Serialization Format section below). Based on the =
BIP44 coin assignment number for the coin the sender would like to send =
(maintained by Satoshi Labs as SLIP44), the sender makes the appropriate =
derivation at this level.

Level 4: Sender Increments Shield Counter to Improve Privacy =
(=E2=80=9CEnhanced Privacy Mode=E2=80=9D)

The shield counter starts at child #1 (#0 is reserved for future use). =
If a higher level of privacy is desired, the sender MAY increment the =
shield counter once per transaction. In this way, individual addresses =
are not re-used. Additionally, the sender MAY split a payment into =
multiple separate transactions, each destined for a different =
blockchain-level address[2]. If the sender does not increment the shield =
counter for every transaction, the sender MUST always use child #1 as =
the public key component of the blockchain-level address.

Reservation of ${BIPNUM} as a BIP43 Purpose

I define that the first level of BIP32 derivation to be used in =
Universal Address allocation from the root BIP32 node SHALL be =
${BIPNUM}, which conforms to the BIP43 recommendation that top-level =
derivations be based on the number assigned to a BIP. The BIP43 purpose =
for this BIP is =E2=80=9CUniversal Addresses.=E2=80=9D

Serialization Format

The serialized address format for BIP${BIPNUM} Universal Addresses SHALL =
be the same format described in the =E2=80=9CSerialization Format=E2=80=9D=
 subsection of the =E2=80=9CSpecification: key derivation=E2=80=9D =
section of BIP32, subject to the following considerations:

- Implementers of BIP${BIPNUM} Universal Addresses MUST encode Universal =
Addresses using the same base58 format as current extended public keys =
for interoperability with existing software.

- For additional privacy, implementers of BIP${BIPNUM} Universal =
Addresses SHOULD substitute the 32-bit =E2=80=9Cparent key =
fingerprint=E2=80=9D with 0x00000000 before disclosing the Universal =
Address to the sender. In these cases, the recipient has the sole =
responsibility of keeping track of the true parent key fingerprint if =
they find it useful.

- For additional privacy, implementers of BIP${BIPNUM} Universal =
Addresses SHOULD substitute the 32-bit =E2=80=9Cchild number=E2=80=9D =
with 0x00000000 before disclosing the Universal Address to the sender. =
In these cases, the recipient has the sole responsibility of keeping =
track of the true child number if they find it useful.

URL-Style Query Parameters for Denotability of Recipient-Specified =
Currency Acceptance Preferences

When the recipient wishes to specify which currencies it prefers to =
receive, a URL-style query parameter MAY be appended to the end of the =
Universal Address. If provided, the query parameter MUST have the =
property of lowercase =E2=80=9Caccept=E2=80=9D and its value MUST be a =
comma-delimited list of one or more SLIP44 currency symbols. Future BIPs =
MAY propose new query parameters that can also be appended. All such =
parameters are strictly OPTIONAL in this specification. Universal =
addresses with no appended query parameters MUST be regarded as valid.

When a sender wallet encounters a Universal Address with an appended =
=E2=80=9Caccept=E2=80=9D URL-style query parameter, it SHOULD show a =
list of currencies in its user interface that correspond to the ones =
denoted by the value of the parameter. The sending wallet SHOULD also =
remove currencies from the list that it does not support.

The sender wallet MAY auto-select a currency for the sender if there is =
only one common currency between the =E2=80=9Caccept=E2=80=9D list and =
the =E2=80=9Csupported currencies=E2=80=9D list of the sender wallet. =
Auto-selection based on the sender=E2=80=99s balance or other factors =
MAY also be performed.

Future Possibilities for Backwards-Compatible Improvements to Universal =
Addresses

A future BIP MAY specify a URI-style format (e.g. =E2=80=9Cpay:=E2=80=A6=E2=
=80=9D) and, if a URI-style format for Universal Addresses is proposed, =
the proposing BIP SHOULD consider removing unnecessary fields (version =
bytes, depth, parent key fingerprint and child index) from the =
base58-encoded string. However, to reduce the friction for adoption of =
Universal Addresses by the community and to promote compatibility with =
existing software, those changes are not proposed as part of this BIP. =
BIP${BIPNUM} Universal Addresses can be converted to a new, shorter =
format in the future[6]. Libraries, wallets and BIPs building on top of =
and claiming support for BIP${BIPNUM} Universal Addresses MUST maintain =
seamless backwards-compatible support for the use of standard =
BIP32-serialized extended public keys as BIP${BIPNUM} Universal =
Addresses.

BIP${BIPNUM} Universal Address Validity Checks

A serialized BIP32 extended public key string that is encoded in base58 =
format with a valid 32-bit checksum SHALL be regarded as a valid =
BIP${BIPNUM} Universal Address if the following are true:
1). The string meets the BIP32 requirement that the specified point lies =
on the secp256k1 curve, and is otherwise representative of a valid BIP32 =
public node.
2). The version bytes are equal to 0x0488B21E for the key[3].
3). The depth byte is equal to 0x02.
4). Notwithstanding the above, validity assertions SHALL NOT take into =
account the contents of the 32-bit parent key fingerprint or the 32-bit =
child number, except that these fields MUST be present in some form and =
that the final double-sha256 checksum MUST be correct.

Implementation Notes

BIP44-compliant wallet Implementers SHOULD use the same BIP32 root node =
as is presently in use for each of their users. This generally reduces =
complexity and maintains compatibility with existing software.

This BIP mandates that it is absolutely REQUIRED that the community =
agree on SLIP44 designations for each coin. Project leaders MUST apply =
for SLIP44 allocations if they have yet to do so and want their projects =
to be compatible with this BIP[4].

Universal Address Sharing

Universal Addresses SHOULD be viewed as having two possible security =
models: they can be fully public or they can be kept secret between the =
recipient and exactly one sender. Fully public addresses are OK, because =
Universal Addresses do not claim to provide confidentiality about the =
amounts and currencies received by the recipient. Fully private =
addresses, where the recipient allocates a new address for every sender =
(such that each sender has their own designated Universal Address for =
the recipient, but no sender may learn the Universal Address of any =
other senders to the recipient) are also secure and have other =
benefits[2]. However, other security models have inherent weaknesses[5] =
and SHOULD definitely be avoided.

Balance Calculation Algorithm

Similar to current extended public key-based wallets, inquiring about =
the balance of a Universal Address involves querying for transactions =
related to the blockchain-level addresses derived from the root node. =
The only difference with Universal Addresses is that wallets SHOULD =
query all blockchains for which a known balance is desired. Higher =
zero-use gap toleration decreases the likelihood of missing coins. =
Wallets SHOULD keep track of the Universal Addresses they allocate.

Examples

Three situations that utilize Universal Addresses will be described; the =
first from the perspective of a recipient and the second two from the =
perspective of senders.

Example 1: Recipient Usage

A user generates a BIP32 private root node and wants to give out a =
Universal Address:

```
=
xprv9s21ZrQH143K2eR2vYd9i6YvrFUojaL3ecK2hY4zfabMgu6okTk2s6WxnQmPYA45apCKWi=
UnHrQsdvh6ER4Leaaa7ehDx5KZtDUbAcgfGBy
```

The user will perform a hardened level 1 derivation to find private =
child #${BIPNUM} of their root node:

```
=
xprv9umttUfc6MFTxANAkz8fWE4hHN99xra5GwiP9Er91M69mBso9hAhAgYu2tXfvXaAs5AHWA=
PwZCSUT4SzkgBqtuNYdHLcp1tSsPDGmAg9ugW
```

The user will perform a public derivation to arrive at the #1 child, as =
this is their first Universal Address:

```
=
xpub6A6MPF2tU1tML7JJa98pzmSgDr7V8JuaKCrYu4tjgq4ZLFKTvF4eW7y3c28ye3db9nk3XV=
vPBTwDA7VB7hch4aj1aQKrCj7FoW78vTJw8zj
```

This is the Universal Address. Assuming the user is OK with accepting =
any SLIP44 cryptocurrency, they can share the Universal Address with any =
sender or publish it online.

Optionally, they can append URL-style query parameters to denote one or =
more currencies they prefer to accept with this address. Other query =
string parameters may be proposed by future BIPs. This BIP only reserves =
the =E2=80=9Caccept=E2=80=9D parameter for use as a comma-delimited list =
of SLIP44 currency symbols, as defined in the =E2=80=9CURL-Style Query =
Parameters for Denotability of Recipient-Specified Currency Acceptance =
Preferences=E2=80=9D subsection of the =E2=80=9CSpecification=E2=80=9D =
section above.

Example 2: Multi-currency Wallet

A user sees a BIP${BIPNUM} Universal Address on a website:

```
=
xpub6A6MPF2tU1tMQXuhyAAXLDWKMuw3GRwZEFUAXXwHuykZoUcyUn24gN7RPuy5xZXj6zSqWX=
FcVjTJEnnX5Qh4pjJMnGbjZkuXHFKFy4U22AX?accept=3DBTC,LTC
```

The user=E2=80=99s wallet notices that the address indicates a =
preference for either Bitcoin or Litecoin, so the UI presents a choice. =
The user selects Litecoin, so the wallet searches for LTC in the SLIP44 =
currency list and therefore derives the #2 child node of the Universal =
Address:

```
=
xpub6D76wrzT2eTJH5EaMdcK8Wkej36nBakXFwMr79HLJMxga4giaehK8RLFiCTiAkBt9W8sai=
vsX4n2ot9reUt4ePbSUhEFHK1NGkKiPhWhQZH
```

This particular wallet does not support "Enhanced Privacy Mode", so it =
will simply derive the #1 child of the Litecoin node instead of =
calculating the correct shield value:

```
=
xpub6E9man3MPJXdrgjHDqhkJuSjG3j9TBfESbxppRA1fF5pq9KEDCQegPfa76e9BT3Nnhwpy9=
krXrLTRsYx8ccFXrMKTuz6hH2ZEanhG1tC59a
```

The Litecoin address corresponding to the derived node is:

```
LXDxiYDVosUg3hKwJ4yP24EfdkRuNumLs5
```

The user completes their transaction with Litecoin.

Example 3: "Enhanced Privacy Mode" and Universal Address Reuse

In a (semi)-private chat, a user receives a Universal Address:

```
=
xpub6AJUhNSZRaZS7d9eJ2jyyuNMbkMWQgHNEgDt9rC3WJfkXvQDAKu9LZLhMhVkeot66EtEtB=
JK48Ca3qNfrjBH1otkBc2CNPwaTMeHSh3TvL1
```

The user received this particular Universal Address some months ago[7], =
and has used to for 17 previous Bitcoin transactions and 2 Litecoin =
transactions to this recipient.

The user wants to send 2 BTC to the recipient. The user=E2=80=99s wallet =
has two unspent outputs in different places; the first for 1.5 BTC and =
the second for 1 BTC.

The wallet notices that the recipient=E2=80=99s Universal Address =
indicates no preference for which currency to receive. Thus, the UI =
presents a list of all supported currencies for which the sender has a =
balance. The sender selects Bitcoin, so the wallet searches for BTC in =
the SLIP44 currency list and therefore derives the #0 child node of the =
Universal Address:

```
=
xpub6CUu5jU1UVXsB3zstbr6MDZcmZy9SAEfsTtm81iR2foAtRZ34cb9jnr4D1jcQxKG9y9fMh=
VeqYy9kC3j4jidyhbrRuX6nXiYgSdQSwZmzVi
```

Since the sender=E2=80=99s wallet supports "Enhanced Privacy Mode", it =
will increment the Bitcoin shield counter starting at child #1 and =
querying the blockchain for each shielded address to see if it has ever =
been used[8]. The wallet sees that the shield counter is at #17[9]. =
Since the wallet uses =E2=80=9CEnhanced Privacy Mode=E2=80=9D, it MUST =
NOT use shielded children less than child #18. For privacy, the wallet =
MAY also split the payment into two or more transactions[11]. The wallet =
will now derive the #18 and #19 children of the Bitcoin node:

```
=
xpub6EvkmcciNXPHVoiSP4sV21mgAWi3MAzJtvwRFXoNuUusADN1KU9eZ9REkuD7PgtRDR1ggK=
RSvci8L6uhegmcoNwSP8QDfSqRH66iC6oGYWs -> =
1F2idiEsCTBN6ZrzkLE7JTddaJPubYet5m
```

and

```
=
xpub6EvkmcciNXPHWR7ZLh8XJz74CZh8NDszKBzEBMS7xFDgTB7aoLbJwtzwV1CdKM6JvwrGow=
U1FoMpf1uZuUfBqX4BpHqMGQocTPev98qZ3Wf -> =
1PpcyFv46NvqJusLwfrv6dkw3K9z434hJV
```

The wallet will now spend the first of its outputs (1.5 BTC) entirely to =
child #18, and 0.5 BTC from the second output will be spent to child =
#19. The remaining 0.5 BTC from the second output will be sent back to a =
change address. In this way, it is impossible for an observer to =
correlate that the two outputs originally belonged to the same sender or =
were part of the same payment[10].

Motivation

Addresses are a tedious part of living in the cryptocurrency-enabled =
world. With hundreds of contacts and dozens of popular currencies, =
keeping track of which people provided which addresses for which coins =
makes life all the more difficult. Widespread adoption of a Universal =
Addressing format would allow users to share one address and accept many =
cryptocurrencies in the same wallet. As merchants and exchanges support =
and use new currencies, new addresses do not need to be exchanged among =
users. When sender wallets support =E2=80=9CEnhanced Privacy Mode=E2=80=9D=
, a substantial gain in transactional privacy is also obtained by the =
use of Universal Addresses.

Rationale

References from the above text:

[1]: This is the example annotation appearing in the =E2=80=9CA Note on =
Annotations and Rationale in this BIP=E2=80=9D subsection of the =
=E2=80=9CSpecification=E2=80=9D section.

[2]: For certain blockchains that do not implement transactional =
=E2=80=9Cinputs and outputs=E2=80=9D, this permits transactions to be =
made in a way that permits single-use addressing. For these coins, when =
the original recipient wishes to spend the received coins which are in =
multiple addresses, they may do so in one of two ways:
1). If the original recipient wishes to send all received coins out as =
one blockchain-level transaction and from one blockchain-level address, =
they may first create many blockchain-level transactions collecting the =
coins into a single =E2=80=9Cchange address=E2=80=9D and then spend the =
coins all at once from that address to the next recipient.
2). If the original recipient wishes to spend using multiple addresses =
(i.e. the next recipient also uses Universal Addresses), the original =
recipient may simply empty each of the addresses they would like to =
spend from; the original recipient may either choose to forward all =
coins in a given address to the next recipient, or to forward some of =
the coins to the next recipient and the rest to a new =E2=80=9Cchange =
address.=E2=80=9D This same model can apply to Bitcoin. In any case, the =
advantage is that it makes for better privacy because =
multi-transactional payments do not permit correlation of any of the =
outputs to any single user. It is also possible to send one transaction =
on blockchain A and another transaction on blockchain B as part of the =
same payment.

[3]: Private keys are never used, and since the Bitcoin Testnet =
(normally 0x043587CF) is covered by level 3 SLIP44 derivation, no other =
version prefixes are needed.

[4]: Not all cryptocurrency projects will be initially compatible with =
BIP${BIPNUM} Universal Addresses out of the box. Does that make these =
addresses non-universal? How non-universal is UPnP? This BIP defines a =
standard that works for most use-cases and most currencies most of the =
time. If enough people adopt it, non-compliant projects MAY find a way =
to join the standard.

[5]: In particular, situations where a group of entities know a single =
Universal Address for a member, and where the transactions of the =
members of the group which involve the known Universal Address are not =
intended to be public should be avoided. By publishing the known =
Universal Address, a single member of the group can compromise the =
privacy of the transactions of all group members involving the known =
Universal Address. Each recipient SHOULD take care to allocate new =
Universal Addresses for each entity with whom they intend to transact =
business; even if an allocated address never gets used by a sender, a =
completely new address SHOULD be allocated by the recipient for each =
potential sender when privacy is strictly required because the =
previously-designated sender can learn the transactional activity =
between the newly-designated sender and the recipient if addresses are =
reused.

[6]: Conversion can occur by simply deserializing the string, removing =
the unnecessary fields and re-serializing to the new format.

[7]: Since Universal Addresses can be reused, the user=E2=80=99s wallet =
could keep an associative list mapping names to Universal Addresses. =
Wallets MAY consider making this look like an address book, where the =
user can add their associates as contacts.

[8]: Wallets MAY use a binary search-style querying strategy to speed up =
this process as opposed to a linear search of the blockchain. The wallet =
MAY also cache the highest known-to-be-used shield counter for each =
previously-checked currency of each Universal Address it has seen in the =
past.

[9]: Wallets SHOULD always check shield counters even if cached data =
exists, because a publicly-known Universal Address could have been used =
by another sender. However, caching speeds up future checks because the =
wallet knows that the shield value is not less than the cached value.

[10]: In typical Bitcoin transactions, such correlations are possible =
and are widely used for =E2=80=9Cblockchain forensics.=E2=80=9D This new =
mode of wallet operation represents a substantial privacy improvement =
for Bitcoin and for all compliant[4] SLIP44 cryptocurrencies.

[11]: It is also possible for the sender to conduct a multi-blockchain =
payment. For example, the sender might send one Bitcoin transaction and =
two Litecoin transactions. The sender SHOULD only attempt this with =
communication and coordination with the recipient to avoid confusion. =
The sender always has an incentive to ensure the recipient properly =
receives the payment.

Other considerations:

The final set of design decisions made with regard to this BIP are =
documented below in a Q&A/interview-style format:

Q: Will it be easy to lose coins since an address is no longer =
associated with a single cryptocurrency?

A: This is a valid concern, but there are quite a large number of =
projects without unique address formats. Specifically, ERC20 coins use =
hex strings while Bitcoin SV and Bitcoin both use base58. Universal =
Addresses will be a net benefit because each project gets its own pool =
of address space. Additionally, the =E2=80=9Caccept=E2=80=9D parameter =
might only contain a single SLIP44 symbol, making Universal Addresses =
the de facto address format for many projects.

Wallets implementing Universal Addresses SHOULD append the =E2=80=9Caccept=
=E2=80=9D parameter, and senders SHOULD NOT send coins that are not =
listed by the =E2=80=9Caccept=E2=80=9D header when specified. Also, the =
money wouldn't actually be lost in these situations. Assuming the root =
private node is safe, derivation of the right path will make recovering =
coins fairly straightforward. Additionally, high quality multi-currency =
wallet implementations should consider scanning popular blockchains for =
transactions even if those chains are otherwise unsupported. This can =
alert the user in cases where unsupported coins were received.

Q: For split transaction payments, no single TXID exists. This makes =
accounting harder.

A: In the vast majority of cases, the sender should get the recipient to =
simply come up with an invoice number or =E2=80=9Cpayment ID=E2=80=9D =
that can be communicated to the sender for their records. Listing all =
relevant TXIDs is another possible solution. Calculating the bitwise XOR =
of all relevant TXIDs to create a single =E2=80=9CMTXID=E2=80=9D is also =
possible and could be the subject for a future BIP. In any case, it is a =
valid concern that =E2=80=9CEnhanced Privacy Mode=E2=80=9D deviates from =
the standard transactional model. If a single TXID is strictly required, =
a multi-transactional payment should not be used.

Q: It is the sender=E2=80=99s choice whether to use a split payment or =
=E2=80=9CEnhanced Privacy Mode=E2=80=9D. If they choose not to do so, =
can=E2=80=99t the recipient=E2=80=99s privacy be harmed?

A: In existing implementations, the sender can breach their own privacy =
in many ways by revealing participation in a transaction. The onus is =
always on the sender of a transaction to ensure that their privacy is =
protected since the recipient does not control whether the sender uses =
=E2=80=9CEnhanced Privacy Mode." With Universal Addresses, each sender =
makes their own choice about privacy and their decision does not effect =
the privacy of the recipient or any other senders. In any case, future =
BIPs might also propose recipient-controlled preferences for privacy =
modes using additional URL-like query parameters.

Q: Can=E2=80=99t a sender publish the recipient=E2=80=99s non-public =
Universal Address to compromise the recipient's privacy?

A: Recipients should only share the same non-public Universal Address =
with one sender. Thus, the impact of such a disclosure is limited to =
transactions strictly involving this particular sender. Refer to the =
=E2=80=9CUniversal Address Sharing=E2=80=9C subsection of the =
=E2=80=9CSpecification=E2=80=9D section and [5] for further details. It =
is also worth noting that by revealing the non-public Universal Address, =
the sender explicitly notifies the recipient that they have breached the =
recipient's implicit trust relationship. Since the recipient gave the =
non-public Universal Address solely to this sender and since the =
recipient knows that they were not the one to have published it, the =
recipient can be certain that the sender published the address. The =
sender will lose the implicit trust of the recipient to maintain =
privacy.

Q: Suppose a recipient publishes their own previously-undisclosed =
non-public Universal Address. Would this reveal that two or more spent =
outputs were from the same sender?

A: Even if the Universal Address is publicly revealed, it does not prove =
that any two transactions sent from different source addresses are part =
of the same payment or even that they came from the same sender. =
Notwithstanding the above, the sender should understand that their =
privacy is determined by their own actions, not the actions of the =
recipient. If the sender failed to re-use addresses and then the =
recipient published the Universal Address revealing a pattern of the =
sender=E2=80=99s single-address activity, the recipient is not liable =
for the sender=E2=80=99s negligence.

Q: Universal Addresses are long. What can be done to shorten them?

A: Elimination of version bytes, parent fingerprint, child number and =
node depth in combination with the creation of a URI prefix would =
decrease length and would also make for another great BIP.

Q: Is it likely that people will get Universal Addresses mixed up with =
normal BIP32 extended public keys?

A: As they are currently used, extended keys are generally distributed =
at the root level. People may attempt to differentiate them because the =
node depth will always be 2 for Universal Addresses. Additionally, an =
extended public key is probably a Universal Address if its parent =
fingerprint and child index have been zeroed, but Universal Addresses =
may also exist with these values populated. A future BIP proposing a =
URI-denoted identifier (=E2=80=9Cpay:=E2=80=A6=E2=80=9D) would also =
solve this problem. Ideally such a BIP would also reduce the length of =
Universal Addresses. In any case, the likelihood for mistakes is small =
considering that BIP32 extended public keys are typically only used by =
advanced users.

Q: Should the version bytes defined in BIP32 be removed or changed for =
use with this BIP?

A: BIP43 recommends that version bytes do not change across use-cases. =
If a new URI scheme is proposed for Universal Addresses in a future BIP, =
the effective result would be that such an identifier could replace the =
version bytes, because it would serve to identify the resource as a =
Universal Address. Version bytes are maintained by this BIP to create =
full backwards-compatibility with BIP32 extended public keys.

Q: XYZCoin is incompatible with this BIP because BIP32 derivation will =
not work with Ed25519 or some other cryptography

A: BIP${BIPNUM} Universal Addresses were designed to work well for most =
people and most cryptocurrency projects most of the time. Since anyone =
is free to start a new project, it is entirely possible that existing or =
future projects are non-compliant with this BIP. Consideration should be =
given to past projects which existed before this BIP=E2=80=99s =
publication, since they could not have known about this BIP at the time =
of their inception. However, the benefits to users and the wider =
cryptocurrency ecosystem in implementing a standard address format MUST =
NOT be underestimated.

References

- BIP32
- BIP43
- BIP44
- SLIP44
- RFC-2119=