bitjson
commented
1 year ago I think no – allowing URIs to specify requirements for multiple outputs quickly compounds the complexity of implementations. In the case of NFTs, wallets now need to optimally select UTXOs for these requirements (considering fees, privacy, etc.) which quickly gets into Knapsack problem territory.
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.
Anyways, I think I prefer to keep the base implementation for URIs as simple as reasonable. Right now we say:
A Bitcoin Cash Payment URI is:
- A request for a single transaction paying to an address using a single output, where all provided parameters modify the properties of the requested output, or
- Connection information for another protocol by which Bitcoin Cash and/or CashToken payment information is to be transmitted.
It would probably be good to clarify further that inclusion of repeated parameters should trigger an error (and I don't think we should treat commas in any special way vs. other characters for now). How does https://github.com/bitjson/chip-paypro/commit/db994afac75c95c50ed176887542ec49b9534dd6 look?
Could/should the URI support a request for multiple NFTs? If so, should there be many
nparameters (n=00&n=01) or onenparameter with comma separated values (n=00,01)?If it's not allowed the specification should state that the parser must produce an error.