monero
monero copied to clipboard
monero-project
[Discussion] Proposal to deprecate integrated addresses
A natural progression from #3772
Integrated addresses are a serious problem for entities that batch their outgoing transfers. When a bunch of withdrawals are batched together, they may include no more than one integrated address, since a tx may include no more than one payment ID. This causes unnecessary congestion through artificial scarcity, which probably contributed to the recent events of major exchanges suspending their XMR withdrawals.
There exist subaddresses which may be batched together without limit, and the overwhelming majority of the network already uses them exclusively.
Additionally, eliminating integrated addresses would further increase the homogeneity of the network (improving privacy), reduce blockchain growth as there will no longer be a need to store payment ID data, make the UX simpler due to lesser variations in address types, and make development (both XMR protocol development and ecosystem development) easier due to having to account for less variations.
We recommend the following:
Remove support for integrated addresses (using subaddresses instead) by October 2022 (assuming that's when the v16 protocol upgrade happens).
Announce intent for these changes to be made as soon as consensus as reached.
Theoretically integrated addresses should only be used by services / merchants / exchanges so that for e.g. LocalMonero payouts it should be fine to only allow regular addresses.
For example the GUI can't even generate an integrated address for this reason exact reason (it's not something the end user should use).
@selsta the fact that integrated addresses are mostly only used by services/merchants/exchanges only increases the severity of the standing out of these transactions from the general mass of txs and makes it easy for chain analysis to assume that any tx that has a payment ID in it is linked to a service/merchant/exchange/pool.
All transactions have an encrypted dummy payment id so on chain there is no difference between regular and integrated address.
@selsta the dummy payment ID will no longer be necessary, reducing blockchain growth. Off-chain data will also be homogenized, increasing privacy. This is not taking into account the lack of the integrated-address-imposed bottleneck on transfer batching and the other benefits mentioned in the first comment.
I, for one, am all for this.
Unifying address formats is better for privacy, can reduce complexity of codebases around wallets, and simplifies UX for end-users.
At present, the UX around integrated addresses can be confusing and even outright dangerous, like how the Ledger always displays the underlying address instead of the integrated address, making address verification difficult or impossible depending on the application.
Subaddresses are superior and should be the only allowed alternate to main addresses IMO.
Note on the timeline: if accepted, this would probably be merged with the larger proving system updates. If Monero goes the Seraphis route, for example, that will naturally be a time to revisit address UX since we would need to change the addressing system anyway.
Since it simplifies the codebase and few, if any people use it, it should be deprecated as requested. Good idea.
No, I disagree and I believe that deprecating integrated addresses would be terrible. There's no sound reason to remove the functionality as it provides a basic function to combine public wallet with payment id. It's used widely in exchange and wallet configurations. It's good for liquidity pools. It's got pros and cons against using subaddresses and that adds value to Monero as a protocol not just XMR
So I vote to keep integrated addresses.
On Wed, Aug 25, 2021, 7:15 PM selsta @.***> wrote:
few, if any people use it
How did you come to that conclusion?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/monero-project/monero/issues/7889#issuecomment-905937777, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADBQBZYJ6EY4477F5ZB5CJTT6V2QXANCNFSM5CW6SAWQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
few, if any people use it
How did you come to that conclusion?
I don't have any figures but integrated addresses are seldom mentioned in comparison to sub-addresses. Therefore, I concluded there isn't much interest.
@selsta @One-horse-wagon based on our own withdrawal stats we can attest to integrated addresses being used in less than 10% of the cases.
What would be interesting is how many services / exchanges / shops use integrated address vs subaddresses.
@LocalMonero Your number seems to be in regards to end users, which is unsurprisingly low as most wallets don't even allow you to generate an integrated address.
Few considerations to add to the discussion ....
MyMonero, openMonero, monero-lws do not have support for subaddresses. By the time integrated addresses are deprecated a lightweight wallet server should have support for subaddresses.
Examples of useful software that utilizes integrated addresses
https://github.com/bitrequest/bitrequest.github.io/issues/2
Example of software that should be using subaddresses, but doesn't
https://github.com/monero-integrations/monerowp/issues/56
A taiga board or other central place could be used to record the various projects & exchanges that need to adopt subaddresses.
We can just have an active user update a table here on github, or update a github project board
Under the assumption that we don't switch to something like Seraphis which brings changes regarding addresses anyway, thus under the assumption that we are free in our decision to leave everything as it is (supporting both integrated addresses and subaddresses versus dropping integrated addresses and continue subaddresses only), I lean towards keeping integrated addresses for now, i.e. not yet announce a fixed cut-off date.
When forming this opinion I did not look at details, but tried to look at the "bigger picture". If we remove them I think we lean a little bit too much on the technical side of things where we concentrate on making the coin and its technology better, and ask a little too much from the part of the Monero ecosystem that has a need of "sender identification" in some way.
Or, formulated a little more drastically: It's alright to force the whole ecosystem through frequent hardforks, through changing this, through deprecating that, through introducing this and this new mechanism, and so on, in the intererest of improving technology, privacy, fungibility, performance, etc, - but up to a certain point. In a certain sense a cryptocurrency is also there to serve its users and the ecosystem surrounding it, and there stability can be important.
Already now Monero is a much more difficult coin to support for shops, exchanges, etc. than other coins, for various reasons. We should not add still to that difficulty without careful consideration. Worst case a significant part of the overall cryptocurrency universe will find Monero not worth the bother given all those difficulties.
I would not consider integrated address as a deprecated feature of Monero. Until we have a better alternative (or a new huge change such as Seraphis), I prefer not to kill that. For my point of view: subaddresses seems fine, but not for all the use cases of adoption. The main difference between a subaddress and an integrated address is who can generate them. Subaddress generation requires to know at least the private view key, while integrated address requires only the public address (or the public subaddress) and a random payment id.
Anyway, for any decision we take, I'll provide all my support to switch subaddress on monerowp and the others payment gateways I've coded. Integrated addresses are helpful for some merchants, and someone even implemented integrated address based on subaddress index.
@t-900-a: the support of subaddresses for monerowp is experimental and can be found on subaddress.php. It's a little bit slow even on servers that are powered by latest hardware.
Already now Monero is a much more difficult coin to support for shops, exchanges, etc. than other coins, for various reasons.
I wouldn't under estimate the ability of people to use Monero. A market on the dark web for instance, not only uses Monero, but they also want customers to use PGP, which is even more difficult to understand than Monero. If their numbers are to be believed, they claim to have over 350,000 active users and another 350,000 gawkers.
@rbrunner7 For all the reasons mentioned in the OP, integrated addresses are more of an obstacle than a feature. Subaddresses do what integrated addresses do, but better. Most of the ecosystem have already upgraded to them, and those that haven't probably won't upgrade until the protocol is changed. This is the same situation as it was with the separate payment IDs back in 2018.
While serhack is correct that integrated addresses have the advantage of being generated from a public key, one can easily sidestep this problem for subaddresses by pre-generating a bunch of them and storing them and then topping up the database as needed.
In our view, primarily because this has massive impact on batching outgoing transfers which causes unnecessary extra transactions (congestion) and blockchain bloat as well as the off-chain privacy leak, this is a band-aid that needs to be ripped off eventually, and the earlier it's done - the better.
I wouldn't under estimate the ability of people to use Monero. A market on the dark web for instance, not only uses Monero, but they also want customers to use PGP, which is even more difficult to understand than Monero. If their numbers are to be believed, they claim to have over 350,000 active users and another 350,000 gawkers.
Interesting. I was however more referring to technical difficulties, not difficulties in handling. How, for example, a shop plugin for Monero leads to a more complicated setup because monero-wallet-rpc has to run somewhere whereas a BTC plugin can directly interface with the Bitcoin blockchain itself because everything is so much simpler technically, or how Monero multisig is currently almost impossibly complex to implement for many environments (I studied this in detail for OpenBazaar).
While serhack is correct that integrated addresses have the advantage of being generated from a public key, one can easily sidestep this problem for subaddresses by pre-generating a bunch of them and storing them and then topping up the database as needed.
This makes it more difficult to rotate your wallets. Every time you rotate a wallet you'd have to generate a bunch of new subaddresses and update your database of available addresses. If you want to keep historical information it's much more difficult to keep track of which wallet the subaddresses came from too.
I like integrated addresses, they are very easy to use and implement. Monero is already very difficult to program for, so why make it even harder?
Creating a database of pre-generated subaddresses doesn't solve the issue of synchronizing a list of active subadresses between threads in a multi-threaded or actor-based payment processor. Each thread needs up-to-date info on subadresses currently in use, so that two customers are never given the same subaddress at the same time.
With integrated addresses, threads are free to generate a random 64-bit payment ID on the spot without worrying about conflicts. To get the same non-locking system using subaddresses, you'd need to be pulling random subadresses from a database with 2^64 subaddresses in it.
Creating a database of pre-generated subaddresses doesn't solve the issue of synchronizing that database between threads in a multi-threaded or actor-based payment processor. Each thread needs up-to-date info on subadresses currently in use, so that two customers are never given the same subaddress at the same time.
With integrated addresses, threads are free to generate a random 64-bit payment ID on the spot without worrying about conflicts. To get the same non-locking system using subaddresses, you'd need to be pulling random subadresses from a database with 2^64 subaddresses in it.
@busyboredom That's just a question of adding a uniqueness constraint to the address column in the database that stores the pending payments. Get the next address from the subaddress db if currently selected one is already used.
This makes it more difficult to rotate your wallets. Every time you rotate a wallet you'd have to generate a bunch of new subaddresses and update your database of available addresses. If you want to keep historical information it's much more difficult to keep track of which wallet the subaddresses came from too.
@Cactii1 If you rotate wallets you may store the subaddress in one column and the base address associated with it in another column of the db to achieve the same effect.
I like integrated addresses, they are very easy to use and implement. Monero is already very difficult to program for, so why make it even harder?
Because the downsides may outweigh the upsides. Integrated addresses:
- create extra blockchain bloat from the payment ID field;
- create unnecessary bloat and congestion due to inability to batch them, forcing services that process withdrawals to send out more txs than necessary;
- make ecosystem DX worse by having to account for more variations in addresses both when receiving and when sending;
- make core development more complicated;
- make UX worse by causing confusion over the address being much longer than the standard length;
- allow the ability to link different accounts to the same identity, causing an off-chain privacy leak: A major point of Monero is making privacy simple by default for the end user. Integrated addresses stand in opposition to that, both when used by the end user, and when implemented as the default customer differentiation mechanism by services.
It's hard to deny that there are some particular use cases where integrated addresses are easier to use. The question is whether those use cases justify the corresponding loss of privacy and increase in bloat and congestion for the network, as well as the increased complexity of the protocol and UX.
@LocalMonero is there a performant and open-source payment processor using subadresses that you would recommend I look at? Maybe seeing a good existing implementation would put my mind at ease.
@LocalMonero is there a performant and open-source payment processor using subadresses that you would recommend I look at? Maybe seeing a good existing implementation would put my mind at ease.
Perhaps @sausagenoods and @stnby from @moneropay, an open-source Monero payment processor project that use subaddresses, could offer some input on that.
Two more points. Are not integrated addresses distinguishable by looking at the tx_extra field in the JSON representation of transmission. If so, it's a potential exploit on the fungibility of Monero.
And second, the tx_extra field should be deprecated along with integrated addresses at the same time, IMO. This was extensively discussed previously but I don't believe any decisions were reached?
Are not integrated addresses distinguishable by looking at the tx_extra field in the JSON representation of transmission. If so, it's a potential exploit on the fungibility of Monero.
This was fixed a while ago, see https://github.com/monero-project/monero/issues/7889#issuecomment-904695256
A lot of great discussion in this thread. One more point to add:
Integrated addresses can be generated once and used for multiple customers. This allows groups to compile "safelists" and/or certification authorities for merchants' addresses, which I think would help consumers feel safer sending their precious money to long random strings of characters. You can't easily do this with subaddresses.
Integrated addresses can be generated once and used for multiple customers. [...] You can't easily do this with subaddresses.
What makes you say that? You can assign a single subaddress to multiple customers.
@LocalMonero But then the processor has to guess the sender on other information: time of tx, amount, reuse, etc, which is unreliable. Imagine the pain of trying to deal with partial payments/refunds when 1000 other customers are sending to the same subaddress. Alternatively, the processor can have the customer send in a send-proof but that's bad for UI. Integrated addresses work really well for authenticating merchants IMO.
I would be 100% onboard for deprecating integrated addresses if there was a way to generate a zero-knowledge proof that subaddress S is a subaddress of primary address P. Then if customers can trust one address P, they can verify that they are sending to the right place for any subaddress given to them.
@jeffro256 there's some confusion here. If you provide a single integrated address to multiple customers you have to guess all the same information that you listed.
What you seem to be saying is that you can provide the customers with a base address and then have them generate the integrated address by themselves, correct? Sounds like creating extra steps instead of just giving them a dedicated subaddress.