Add expiry param support

[yashasvi-ranawat]

Should the URI support parameters for OP_RETURN and expiry of the payment request?

Pro:

1. Invoicing becomes easier with invoicing reference numbers passed as OP_RETURN.
2. No direct online interaction is needed between payer and payee; supports privacy.
3. With expiry information in the payment request, the indirect way of interacting becomes safer.

Example:

bitcoincash:<address>?s=1234&opr=0b696e766f69636520353436&e=1686573082&m=electricity%20bill

Here, the payer needs to send a tx with an OP_RETURN output of locking byte: 6a0b696e766f69636520353436, an output sending 1234 sats to bitcoincash:<address>, by 1686573082 unix time.

[jonas-lundqvist]

My opinion: No.

Unless it is 100% adopted a service can't show such an URI and be fully confident that the users wallet won't silently drop the opr parameter without the user knowing what's going on and still send money.

I think these "advanced" use-cases should be deferred to BIP-70/JPP.

[yashasvi-ranawat]

I think these "advanced" use-cases should be deferred to BIP-70/JPP.

No they can't, BIP-70/JPP requires a direct communication between payee and payer; which I'd want to avoid.

But I think, if URI doesn't match BIP21, i.e. no amount para; then the wallet has to check CHIP-2023-05-PayPro support. Then opr and e can be safely added to this CHIP, only when amount parameter does not exist.

[bitjson]

Thanks for opening this issue @yashasvi-ranawat! I 100% agree on an expiration parameter, just an oversight in my first draft!

It was a multimillion dollar mistake to not include this as an option back in 2012. It would have been extremely helpful for reducing support burden at BitPay and for BitPay merchants. BitPay was eventually forced to altogether turn off support for payments not using one of the payment protocols in part for lack of this parameter; I'm sure this issue wasted significant time and resources among other companies and projects too.

Looking back, the only reasoning against inclusion was lack of support in a few now-defunct clients. This remains a silly reason: 1% support would have been better than nothing at reducing payment errors, and support for a useful feature can be expected to grow over time. The best time to plant this tree was 11 years ago, the second best time is now. It's fine if it's not 100% reliable for a few years.

We also have a rare opportunity to fix this issue with nearly complete coverage in new clients (which might implement support at the same time as the token related changes) – fixed in d802521.

[bitjson]

I split the OP_RETURN part of this issue into #7 so each can be independently referenced.