Add support for an OP_RETURN parameter?

[bitjson]

Breaking this out from #6 by @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.

[bitjson]

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

Response by @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 again for the issue @yashasvi-ranawat.

So I understand, what use cases do you see for the OP_RETURN-requesting parameter? Does the OP_RETURN/data-carrier output get appended to the transaction in addition to the output defined by all the other parameters?

It seems like certain application-specific clients could support publishing simple messages on-chain using the typical non-standard extension strategy (e.g. a d parameter for data/data-carrier output), and non-supporting clients would safely ignore the extra parameter. If publication was required, clients could omit the address and/or define a higher-level "template" parameter of some sort to indicate requirements for multiple inputs or outputs.

Would it be reasonable to have this be a separate CHIP/specification focused on your particular use case(s)?

[yashasvi-ranawat]

what use cases do you see for the OP_RETURN-requesting parameter?

For example, if a service sells tokens (eg event ticket tokens), as cashtokens, then it can specify a static URI with an OP_RETURN requesting parameter. This way the back-end service can differentiate the kind of tokens requested by a payee without the need to support a direct communicating channel with the payee. This utilises the BCH network as a payment and communication network for accepting payments. This way the service can host a static ipfs website, with payment URIs and mitigate downtime due to heavy payment channel traffic.

Does the OP_RETURN/data-carrier output get appended to the transaction in addition to the output defined by all the other parameters?

Yes.

(e.g. a d parameter for data/data-carrier output)

I like this approach too.

Would it be reasonable to have this be a separate CHIP/specification focused on your particular use case(s)?

I think the other way would be to use BIP21's req- parameter (so a "req-d", for example).

[bitjson]

I'm not sure if I follow, doesn't the user already have a direct line of communication with the server in this instance? It seems much more complicated to scrape information from P2P network transactions than to accept a POST request in addition to the GET requests that the user has presumably made in order to receive the URI in the first place.

I definitely expect matching of buyers and sellers entirely on-chain to be a big use case (I'll call "over-the-blockchain"/OTB trading). That can be done without a backend though, just requires wallets to support the required covenant system(s) and UTXO selection.

Anyways, I think my preferred solution here is something like in #3 (comment):

I think a better solution for this general problem is to define (in another CHIP/specification) a "template" parameter of some sort that specifies a set of complex requirements for multiple inputs and outputs, maybe across multiple transactions. Should consider both one-way and bidirectional communication, e.g.:

• one-way: the requester can ask for an on-chain publication using a particular bitauth identity (a particular UTXO) with an OP_RETURN of some content,
• bidirectional: the requester can contribute some input(s) for a payjoin transaction.

With something like this, it would be possible to make the trade be a PayJoin transaction in which the web service actually offers some UTXO(s) with the tokens in question, letting the user contribute their UTXOs, and the swap being made in an atomic transaction (which also happens to both prevent payment fraud and reduce privacy loss). It would also coincidentally be possible to request even multiple OP_RETURN outputs in a single transaction via the one-way communication option.

[yashasvi-ranawat]

I'm not sure if I follow, doesn't the user already have a direct line of communication with the server in this instance?

Not really, when the website is static and hosted on ipfs.

I think the other way would be to use BIP21's req- parameter (so a "req-d", for example).

I see that the CHIP also removes req- parameter from BIP21. I don't think that's the best way though.

[yashasvi-ranawat]

#3 comment is reasonable. This issue can be closed.

[bitjson]

Not really, when the website is static and hosted on ipfs.

Ah, I see! Yeah, I think a transaction templating parameter/protocol would work particularly well in that case.

Thanks again for the issues! I'll close this issue for now, but feel free to comment if we should re-open.