Support multiple destinations in make_uri and parse_uri

[woodser]

monero-wallet-rpc supports make_uri and parse_uri which can be used to create a request for payment which the sender can parse to pay.

These calls currently only support a single destination address and amount.

This issue requests supporting multiple destination addresses and amounts to accommodate multi-output requests which can be used in a variety of applications or to prepare wallets with available outputs.

An encoding scheme is needed to support multiple addresses and amounts. The format should be small in order to accommodate limited capacity of QR codes.

[erciccione]

There is a $500 bounty on this issue. See haveno-dex/haveno#83 for details.

[benevanoff]

I’ll take a stab :p

[woodser]

Example encoding scheme supported on IRC (originally proposed by @benevanoff):

monero:46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em,46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em?amount=239.39014,123.55423&description=donation,example (note description text needs escaped).

For backward compatibility, make_uri should produce the old format if using a single destination and address and this new format for multiple destinations and addresses.

[trasherdk]

Positional parameters, description field optional.

monero:<addr1>,piconero,base64(desc):<addr2>,piconero,base64(desc)

[benevanoff]

I like @trasherdk 's suggestion better

[selsta]

@trasherdk's solution will use more characters overall because you will have e.g. "?amount=" multiple times.

[trasherdk]

I would not use ?, amount, description and =.

Using : as delimiter for separate transactions. monero:<transaction1>:<transaction2>
where a transaction is <addr1>,piconero,base64(desc) making description optional.

[selsta]

@trasherdk Ok I understand now. Your proposed format is nicer than what we currently have, though it wouldn't be backwards compatible as far as I can see.

19:24 <moneromooo> In any case, it'd be nice if it was backward compatible.
19:24 <moneromooo> ie, passing one address/amount with the new rules yields an URI that old rules parse correctly.

I guess it can be discussed if having backwards compatibility is more important than a cleaner format.

[benevanoff]

I’m personally in favor of just biting the bullet and changing it. The payment ID field should already be deprecated iirc so I’d think that can go and having a recipient tag as well as a transaction description tag seems rather redundant since they’re both just free forms.

[benevanoff]

Actually now that I think about it more, it’d probably be a headache for 3rd part wallets so maybe not the best idea

[trasherdk]

I would think it would be easier (less code) to parse my version ❓

[woodser]

Long payment IDs should still be supported afaik.

The old call should be backward compatible for a single address/amount, but it could produce the new format for multiple addresses/amounts, or we could create new RPC calls like 'create_payment_request' and 'parse_payment_request'.

[selsta]

Long payment IDs should still be supported afaik.

Integrated addresses are fine. No need for external payment id field.

[hyc]

Using : as delimiter for separate transactions. monero:<transaction1>:<transaction2>
where a transaction is <addr1>,piconero,base64(desc) making description optional.

URI syntax only allows for '?' and ';' as delimiters within a single URI. Please let's not invent
solutions that would break all existing URI-processing software.

[elibroftw]

The tricky part is that the bade of the Uri is an address. This makes processing additional addresses that much more annoying. The problem with the solution I'm about to propose is that wallets will have to append a query to the base address list. Which is 2 lines of code.

monero:addr1?
addr=addr2&amt=val1&addr=addr3&amt=val2

Any competent Uri parser should be able to retrieves values as a list from a Uri.

[selsta]

@elibroftw there is a PR for it already #7737

[elibroftw]

@elibroftw there is a PR for it already #7737

Yeah I realized. Too late for me 😅

[erciccione]

#7737 has been abandoned. Anyone willing to recover it can claim part of the bounty: haveno-dex/haveno#83

[woodser]

@darkdrag00n It's no longer needed in Haveno, but multiple destinations in Monero payment URIs is still a valid use case that would be good to support long term. We would still honor the bounty.*

*Reduced the bounty to $350.

[NorrinRadd]

I will take this @woodser