From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7153FC0881 for ; 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 ; 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 ; 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 ; Tue, 24 Dec 2019 03:26:41 +0000 (UTC) Received: by mail-pl1-f193.google.com with SMTP id g6so7953842plt.2 for ; 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 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Dec 2019 19:20:16 -0800 (PST) From: Ty Everett 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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=