[Discussion] Proposal to deprecate integrated addresses

LocalMonero commented 3 years ago

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.

selsta commented 3 years ago

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).

LocalMonero commented 3 years ago

@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.

selsta commented 3 years ago

All transactions have an encrypted dummy payment id so on chain there is no difference between regular and integrated address.

LocalMonero commented 3 years ago

@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.

sethforprivacy commented 3 years ago

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.

SamsungGalaxyPlayer commented 3 years ago

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.

One-horse-wagon commented 3 years ago

Since it simplifies the codebase and few, if any people use it, it should be deprecated as requested. Good idea.

selsta commented 3 years ago

few, if any people use it

How did you come to that conclusion?

shopglobal commented 3 years ago

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 .

One-horse-wagon commented 3 years ago

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.

LocalMonero commented 3 years ago

@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.

selsta commented 3 years ago

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.

t-900-a commented 3 years ago

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.

SamsungGalaxyPlayer commented 3 years ago

We can just have an active user update a table here on github, or update a github project board

rbrunner7 commented 3 years ago

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.

serhack commented 3 years ago

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.

One-horse-wagon commented 3 years ago

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.

LocalMonero commented 3 years ago

@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.

rbrunner7 commented 3 years ago

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).

Cactii1 commented 3 years ago

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?

busyboredom commented 3 years ago

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.

LocalMonero commented 3 years ago

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.

busyboredom commented 3 years ago

@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 commented 3 years ago

@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.

One-horse-wagon commented 3 years ago

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?

selsta commented 3 years ago

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

jeffro256 commented 3 years ago

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.

LocalMonero commented 3 years ago

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.

jeffro256 commented 3 years ago

@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.

LocalMonero commented 3 years ago

@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.

jeffro256 commented 3 years ago

@LocalMonero Correct me if I'm wrong, but that's where the payment IDs come into play with integrated addresses. You can easily distinguish between senders with a high-entropy encrypted bit string. IMO this is a much stronger solution for differentiating payments than what you can do with subaddresses. You could try to put some special code in the wallets to encode information in the dummy payment ID, but that's sorta hacky.

LocalMonero commented 3 years ago

Integrated addresses = base address + payment ID combined into one address. You generate different payment IDs to differentiate customers, resulting in different integrated addresses.

Just in the same way, you can generate different subaddresses from the same base wallet to differentiate customers. When your wallet processes payments it knows which subaddress received which payment. You differentiate by the receiving subaddress.

jeffro256 commented 3 years ago

Sorry, I should have been more specific. Yes, integrated addresses are just a way to encode a base address + a payment ID. But since the base address can remain permanent for the lifetime of a merchant, with only the payment ID changing often, any integrated address can be verified to belong to a certain base address. The same cannot currently be said for subaddresses, which is a valuable use case IMO.

cirocosta commented 3 years ago

@jeffro256 [...] any integrated address can be verified to belong to a certain base address. The same cannot currently be said for subaddresses, [...]

I don't think that arguments holds - for that proof you're talking about, I believe you'd have to record the payment ID somewhere, right? Well, subaddresses are made out of a major and a minor index, which, as long as stored somehow (just like you would for payment ID), once used will deterministically derive a given subaddress, thus, letting you prove that a subaddress "belongs" to a base address.

jeffro256 commented 3 years ago

You'd have to record the payment ID somewhere, right?

If you've ever sent to an integrated address, you might notice that they are longer than normal addresses. This is because there is a payment ID tacked onto the end of the address. Much like how normal addresses are just a way to encode (public view key, public spend key), integrated addresses are just a way to encode (public view key, public spend key, payment ID). There is also a field in every tx that stores a payment ID, whether it is used or not (see this comment).

Well, subaddresses are made out of a major and a minor index, which [...] let[s] you prove that a subaddress "belongs" to a base address.

The problem is that a sub address is not just derived from the hash of an index, but also the hash of the private view key. Here is the formula to derive subaddresses:

Ks,i = Ks + H(kv,i)*G
Kv,i = kv*Ks

where i is the subaddress index, 
          Ks,i is the ith public spend key,
          Kv,i is the ith public view key,
          Ks is the base public spend key,
          kv is the base private view key,
          H is a hash function,
          and G is the generator.

As you can see, it in order to deterministically prove that a subaddress belongs to a base address, you would need to divulge the base private view key, which is not ideal for a merchants. However, if there was a way to create a zero-knowledge proof for this scenario, then subaddresses would be easily able to replace integrated addresses in a merchant environment IMO. Until then, I think integrated addresses prove too useful to deprecate.

cirocosta commented 3 years ago

Hey @jeffro256, yes! thanks for pointing that out, totally agree that divulging the private view key is far from ideal - I think I miscommunicated here though.

The point I was going for was just that with a combination of a pool of pre-generated subaddresses (like suggested before in this thread), if it's of one's concern the necessity of proving that a given subaddress is indeed derived out of a given base, one could maintain in their database alongside the subaddress the indices that were used to get there, which can then, if necessary, be used to do that proof if necessary in a warm/cold way.

If you don't mind me asking, what's your current need when it comes to verifying that an address comes from a particular base? Is it to prove to customers that the subaddresses they're given are based of a particular base address (1), or for the sys admin to make sure nothing is funky with the addresses being handed to the customers (2)? I've been commenting here under the assumption of (2).

Cheers, mate!

jeffro256 commented 3 years ago

@cirocosta Thanks for the clarification! Yeah I guess we were sort of misunderstanding. For the purpose of (2), pregenerating a large list of subaddresses would work fine enough for sever-side validation. I was talking more of the first case (i.e. customer protection). Monero transactions are irreversible, and there is no central authority to arbitrate disputes, so it's a great thing that integrated addresses exist and allow customers to self-validate who they are sending to. If a customer messes up the payment ID, (e.g. resending to the same payment ID), as long as the base address is the same, then they know who to talk to about refunds. Also if a merchant is hit with a address-replacement attack, the customer will be able to instantly verify that it happened and prevent transferring funds to an attacker.

iamamyth commented 3 years ago

I was talking more of the first case (i.e. customer protection). Monero transactions are irreversible, and there is no central authority to arbitrate disputes, so it's a great thing that integrated addresses exist and allow customers to self-validate who they are sending to. If a customer messes up the payment ID, (e.g. resending to the same payment ID), as long as the base address is the same, then they know who to talk to about refunds. Also if a merchant is hit with a address-replacement attack, the customer will be able to instantly verify that it happened and prevent transferring funds to an attacker.

How many users understand what you described regarding address continuity and address replacement attacks? It seems to me the minimum capability bar for every user would be "copy and paste text, triple check it's correct". Anyone capable of following that process, who happens to also understand the threat of address replacement attacks, could likely mitigate such attacks via a secondary communication channel.

How would the mitigation you described provide any likely benefit in a plausible threat model? For a first-time sender who doesn't know the address, the subaddress and integrated are effectively the same. In subsequent cases, the sender needs an address book to know that anything has changed. But, if the sender has an address book, then a change in recipient address would be equally obvious with either addressing format, so the only possible difference here would be the remediation step. If anything, subaddresses would make the user more conservative (just don't initiate the transfer without secondary confirmation), which seems a desirable result. The only scenario I can see which subaddresses materially impact would be rotating the recipient's address while keeping the same base address, but why would the recipient do that in the first place? I suppose the options for out of band address confirmation increase with integrated addresses (e.g. ask someone you know who's done business with the merchant to confirm the address), but I suspect few, if any, avail themselves of such options.

jeffro256 commented 3 years ago

@iamamyth This is a great point, and this is where we would start geting into the gritty details. Obviously no one is gonna manually inspect the base address of every integrated address they send to because it's such a PITA. And you also have to bootstrap that trust in the first place as you mentioned. In the same way, we don't validate the authenticity of each and every connection to a website we make; we leave that up to HTTPS and certificate authorities. We don't manually filter every outgoing request from our browser for ads and tracking sites; we leave that to adblocks. This client-side authentication of recipients would ideally be done through a seamless automated system, and integrated addresses give us the ability to do that.

iamamyth commented 3 years ago

This client-side authentication of recipients would ideally be done through a seamless automated system

My point remains: Integrated addresses provide a vanishingly small usable surface for any such automated system, as compared to subaddresses. Is it exactly zero? No, I suppose not. Is it exceedingly close to zero, so as to be inconsequential? In my view, yes. All of which doesn't necessarily mean integrated addresses should be deprecated, there are other tradeoffs to consider, but I think it helps to focus discussion of feature deprecations on actual and near-term likely usages. Put differently, what you've outlined seems like a rounding error in a cost-benefit analysis.

HoverHalver commented 2 years ago

any integrated address can be verified to belong to a certain base address. The same cannot currently be said for subaddresses,

Verifying if a given subaddress belongs to a file of pregenerated subaddresses uses less than 10 lines of code in PHP.

spirobel commented 2 years ago

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.

wouldnt it be possible to ask customers to only withdraw to subaddresses?

jeffro256 commented 2 years ago

Verifying if a given subaddress belongs to a file of pregenerated subaddresses uses less than 10 lines of code in PHP.

See https://github.com/monero-project/monero/issues/7889#issuecomment-908676511

tevador commented 2 years ago

FYI, the current proposal for the future Seraphis addressing scheme includes the removal of integrated addresses and encrypted payment IDs.

To compensate for this removal, a new type of wallet is proposed that enables the generation of subaddresses without the private view key.

If a merchant is watching this discussion, we would like to hear feedback on the merchant-related features.

https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024

SamsungGalaxyPlayer commented 2 years ago

We need to be able to non-interactively pass at least a short string to a static address for identification for the Thorchain integration to work.

The issue above says 16 bytes, but it's actually 16 characters (8 bytes).

If Thorchain had their way, they would put the whole string in the tx_extra. This is a compromise to allow those with view keys (the public) to be able to decrypt the 16 character payment ID and compare it to the hashes of the payment requests.

It's extremely important to allow users to non-interactively pass through a reference string of sufficient length.

rbrunner7 commented 2 years ago

@SamsungGalaxyPlayer wrote:

We need to be able to non-interactively pass at least a short string to a static address for identification for the Thorchain integration to work. [...] It's extremely important to allow users to non-interactively pass through a reference string of sufficient length.

My first immediate thoughts when reading this: Did somebody with the necessary knowledge already check whether what Thorchain proposes / wants here is A) a solution for a real problem, B) an appropriate solution for said problem, C) without a simpler alternative, and D) not threatening the privacy of Monero users that don't use and don't care about Thorchain ("Look! There in the Monero blockchain. One of those Monero txs connected with Thorchain use" as a consequence of this would be unfortunate all around).

I am not able to come up with an immediate alternative way to solve the problem to associate a "transaction intent" with the transaction itself as mentioned in the Thorchain issue you link to, but maybe people with better knowledge of Monero's internal workings can have a look.

SamsungGalaxyPlayer commented 2 years ago

@rbrunner7 I'm confused, what do you mean by is this a solution to a real problem? This is a real use-case that Cake is investing in heavily since it provides a simple UX like an instant exchanger in a more decentralized manner. It's a valid use-case we wish to support.

The requirement to convey a transaction intent as initiated by the sender is a use-case that payment IDs currently allow for, and I want to make sure that remains.

I'm not clinging to a specific implementation, but this functionality is important and should remain in some reasonable form.

Edit: Firo is planning on encrypting a memo with the amount with Spark, which is an example of a different way of accounting for the same use-case. We don't need to be daft and make it 512 bytes or whatever, but a small memo (like 8 bytes) is quite manageable for the flexibility it allows.

rbrunner7 commented 2 years ago

I'm confused, what do you mean by is this a solution to a real problem?

Agreed, maybe point A) is trivial to answer with "yes, of course", and we can continue already to the probably much harder point B) of mine.

But still, as I said I don't know much about Thorchain, but is it really an absolute "must" that the intent is published before the transaction? No way to reverse that? Because if you can do the tx first and the intent second, you could of course trivially include the tx hash in the intent and associate that way.

Maybe that would mean bigger changes in the Thorchain code base, as you would have to do a reverse search to find the intent if you only hold the tx, but perhaps doable. "Thinking outside the box" can sometimes find surprising solutions. And maybe we still could get rid of those problematic payment IDs.

rbrunner7 commented 2 years ago

I realized that my proposal to send the tx first and the intent second might be pretty dumb if between intent and tx there has to happen an "offer acceptance" of any sort for the system to work, but I would love to have that argued convincingly by somebody with solid knowledge of how Thorchain works.

tevador commented 2 years ago

We need to be able to non-interactively pass at least a short string to a static address for identification for the Thorchain integration to work.

Related: https://gitlab.com/thorchain/thornode/-/issues/919

The issue above says 16 bytes, but it's actually 16 characters (8 bytes).

If Thorchain had their way, they would put the whole string in the tx_extra. This is a compromise to allow those with view keys (the public) to be able to decrypt the 16 character payment ID and compare it to the hashes of the payment requests.

It's extremely important to allow users to non-interactively pass through a reference string of sufficient length.

Firstly, there is a big difference between 16 hex characters (64-bit security) and 16 bytes (128-bit security). The former one is insecure as it is feasible to generate two payloads that will hash to the same value. You will need at least 12 bytes to achieve any meaningful security.

Secondly, we should consider if bloating the chain to enable one specific feature not everyone will use is worth it.

I see at least 2 better options:

communicate the hash value off-chain or using another blockchain
pass the encrypted hash in tx_extra (this will make the transactions somewhat stand out, but at least it won't affect the size for everyone)

monero-project / monero

[Discussion] Proposal to deprecate integrated addresses #7889