# Pastebin cRwyJViz --- layout: post title: Monero Address Upgrade Timeline summary: tags: [dev, core, crypto] author: [Justin Ehrenhofer](https://twitter.com/JEhrenhofer) --- # Monero Address Upgrade Timeline Monero currently offers several methods of payment for many use-cases. Many of these were temporary improvements that allow merchants to easily identify payments for invoices and deposits. However, the large number of options harms user experience and degrades privacy. The Monero community here outlines its timeline to streamline the Monero address system to the latest best-practices. TL;DR: the standalone payment ID will be deprecated in the next scheduled protocol upgrade in March or April 2019. The integrated address will be deprecated in the March or April 2020 upgrade. ### Explanation of Grievances with the Current System From the perspective of users, they can send different types of transactions: 1. Transactions to a normal address without a payment ID 2. Transactions to a normal address with a standalone 64-character payment ID 3. Transactions to an integrated address (address + built-in 16-character payment ID) 4. Transactions to a subaddress without a payment ID From the perspective of outside observers, they can see three distinct types, all approximately equally common today: 1. Transactions without a payment ID (those to a normal address or subaddress) 2. Transactions with a 64-character standalone, unencrypted payment ID 3. Transactions with a 16-character integrated, encrypted payment ID (those to an integrated address) As you can see, these several supported transaction types are complex for users to understand. Furthermore, there is a possibility that users do not fully understand the privacy protections offered by integrated addresses. Users may falsely assume that integrated addresses provide the same privacy protections as subaddresses (they do not). Even though subaddresses have some limitations, the protections are better than integrated addresses in every way. Having an ability to identify transactions as one of the three types lowers privacy somewhat, since there is another piece of metadata to identify users. For example, suppose an attacker is interested in payments to a specific merchant that accepts only addresses with standalone payment IDs. The attacker could only look at transactions of the one type. Luckily, Monero has enough daily transactions that even 1/3 is a large crowd to hide among even in these circumstances, but it's best to avoid this extra metadata if possible. Monero has a history of minimizing unnecessary metadata, including unusual ringsizes in the v0.13 "Beryllium Bullet" update in September 2018. Most importantly however, standalone payment IDs are extremely annoying. Users need to copy two strings to their wallet, and if they copy them incorrectly, they may lose their deposit or payment. Monero standalone payment IDs severely limit user experience and lead to complicated user interfaces. ### Considered Solutions Monero researchers and developers reviewed the following possible options for improving its address scheme. Some could be used in conjunction with others: 1. Removing standalone payment IDs. This improves privacy somewhat and substantially improves user experience. 2. Removing all payment IDs in favor of subaddresses. This improves privacy somewhat, limits the ability for users to accidentally forfeit their opsec, reduces transaction size slightly, and substantially improves user experience. However, it is more difficult than removing only the standalone payment IDs. 3. Mandatory encrypted payment ID. This would make this metadata component for all transactions to normal addresses appear identical to outside observers, improving privacy somewhat. However, this would slightly increase blockchain bloat by 34 bytes per transaction, and more importantly, it could confuse users who expect to receive transactions without payment IDs. 4. Removing standalone payment IDs from the official wallets (CLI + GUI) and recommending that other wallets do the same. This encourages services that expect payments from most wallets to upgrade, though it could cause user confusion. It would not require a consensus change. Ultimately, the Monero community considered options 1, 2, 1+3, and 3+4. ### Determination Process The Monero community decided to adopt this upgrade timeline following extensive conversations over several months with a variety of stakeholders. * Alex from [LocalMonero](https://localmonero.co) introduced the idea in the [March 10 Coffee Chat](https://www.youtube.com/watch?v=Q4ezlumuZLc). * It was briefly discussed the following day during the [March 11 DevMeeting](https://monerobase.com/article/devmeeting_2018-03-11). * The topic was discussed in more detail during the [May 6 DevMeeting](https://monerobase.com/index.php/article/devmeeting_2018-05-06). * Justin opened a [GitHub issue on May 7](https://github.com/monero-project/monero/issues/3772) outlining a preliminary update timeline. It received a lot of positive comments from the community, including services and independent Monero wallet developers. There was more generally positive discussion on [Reddit](https://www.reddit.com/r/Monero/comments/8hp5r4/discussion_proposal_to_deprecate_the_standalone/). * [Monero Integrations](https://monerointegrations.com), a popular tool, announced they removed standalone payment IDs during the [June 9 Community Meeting](https://getmonero.org/2018/06/09/logs-for-the-Community-meeting-held-on-2018-06-09.html). * Monero v0.13.0 "Beryllium Bullet" [introduced a warning](https://getmonero.org/2018/10/11/monero-0.13.0-released.html) when using unencrypted payment IDs. * This release went live in early January 2019, leaving months for Monero services to meet the first April or May deadline. Ultimately, standalone, unencrypted payment IDs were the primary targets for their terrible user experience. Encrypted payment IDs were the secondary target, since subaddresses offer an improvement over any payment ID process. The Monero community outlined as many benefits when using payment IDs over subaddresses as possible to determine if the change to subaddresses is worthwhile. While subaddresses improve privacy for the sender and allow the receiver to more easily manage their opsec, they are more difficult to implement and slightly costlier to maintain. Generating new subaddresses take a few extra milliseconds each, and merchants need to use their private view key (not the private spend key) to generate new subaddresses. While there are some hurdles to overcome, since generating a payment ID is simpler than a subaddress, we feel that these limitations are outweighed by the benefits of subaddresses. Furthermore, the upgrade timeline for subaddress-only is quite generous. ### Upgrade Timeline For the April or May 2019 scheduled upgrade, Monero will deprecate standalone payment IDs. Transactions that need to be identified must be sent using more convenient and superior integrated addresses or subaddresses. For the April or May 2020 scheduled upgrade, Monero will deprecate all payment IDs, including integrated addresses. Transactions that need to be identified must be sent using superior subaddresses. ^^^^^ use this link when previewing above image instead: https://i.imgur.com/WJS7WjI.png ### Further Resources You can learn more about Monero and its development process by using the following resources: The #monero-dev Freenode IRC channel, also available on [Mattermost](https://mattermost.getmonero.org/monero/channels/monero-dev). [Moneropedia Payment ID page](https://getmonero.org/resources/moneropedia/paymentid.html) [MoneroDocs page on integrated addresses](https://monerodocs.org/public-address/integrated-address/) [Monero StackExchange questions with the `Payment ID` tag](https://monero.stackexchange.com/questions/tagged/payment-id)