Closed daira closed 4 years ago
One possible way to encode a payment request, {z-addr, memo}, is to extend BIP21 to include a "memo" parameter, i.e. zcash:<z-addr>?memo=<memo>
. This can then be displayed using a QR code. The encoding of the memo field itself would need specifying: it could simply be encoded using RFC 3986 percent-encoding, or alternatively it could be hex-encoded.
Note that BIP21-style Zcash addresses (both t- and z-addrs) are already in use "in the wild", e.g. the Wikileaks donation links (both the hyperlinks and the QR codes), but of course without use of a "memo" parameter (I haven't seen this used anywhere yet).
I've renamed this to "Specify payment request URIs" and assigned a ZIP number derived from BIP 21. Note that:
If there is an objection to either of these effects, speak up!
The payment request encoding may need to contain different information if the payment will be done using a secure channel instead of a recipient z-address (discussed in zcash/zcash#2432).
It would be nice to have a single encoding that supports both use cases.
Re https://github.com/zcash/zcash/issues/2319#issuecomment-321063481:
The Zcash Foundation grants platform also uses BIP21-style zcash:t3...?amount=...
payment request URIs.
Do we want support for these URIs in zcashd RPC?
Perhaps:
zcash-cli z_sendmany "t1M72Sfpbz1BPpXFHz9m3CdqATR44Jvaydd" '[{"request": "zcash:ztfaW34Gj9FrnGUEf833ywDVL62NWXBM81u6EQnM6VR45eYnXhwztecW1SjxA7JrmAXKJhxhj3vDNEpVCQoSvVoSpmbhtjf?amount=5.0&memo=squeamish+ossifrage"}]'
Or should the parsing be left to higher-level software?
What do other coins do (e.g., Bitcoin for BIP21)?
The just-funded Zcash Foundation grant for Zcash Point-Of-Sale will also use the zcash:saplingpaymentaddress?amount=0.12345678&memo=ordernumber
format (according to its discussion comments).
One possible way to encode a payment request, {z-addr, memo}, is to extend BIP21 to include a "memo" parameter, i.e.
zcash:<z-addr>?memo=<memo>
. This can then be displayed using a QR code. The encoding of the memo field itself would need specifying: it could simply be encoded using RFC 3986 percent-encoding, or alternatively it could be hex-encoded.Note that BIP21-style Zcash addresses (both t- and z-addrs) are already in use "in the wild", e.g. the Wikileaks donation links (both the hyperlinks and the QR codes), but of course without use of a "memo" parameter (I haven't seen this used anywhere yet).
I'd like to agitate for calling it anything other than memo
since that overloads the term with the memo
field.
I'd like to agitate for calling it anything other than
memo
since that overloads the term with thememo
field.
The precise intent of this is exactly that the contents of the "memo" parameter be inserted into the "memo" field of the shielded output in the generated transaction. This is so that the vendor can ensure that the purchaser includes an order ID in the memo field, for example. So it's not overloaded at all.
The ZIP doesn't include any sample use of the req-
prefix, so I wonder: is the req-
prefix considered part of the parameter name, or just an optional prefix that can be prepended to any already defined parameter?
For example, should my parsing implementation consider req-amount
to be an alias of the amount
parameter?
@AArnott At present, there are no required parameters specified. You'll notice that the reqparam
production is defined in the "forward compatibility" section. The reqparam
production was added to allow for future changes to the specification without explicit versioning; instead, if a parameter is added in the future where an existing parser might misinterpret the payment request and produce the wrong result, compliant parsers will produce an error instead. What this means is that your parser should look for variables having the req-
prefix, but if it encounters any at all (since none have yet been specified) your parser should report an error.
As an example of a potential future change that might necessitate the introduction of a req-
parameter, once ZSA functionality is active on the network it might make sense to introduce a req-currency
parameter that can specify the currency in which the payment recipient wishes to be paid. A parser that does not understand the req-currency
parameter will be unable to correctly interpret the payment request, and should therefore return an error.
Thanks. I think there is an opportunity for using it more. For example req-memo
could indicate that the memo field must be copied into the payment screen, and perhaps locked so the user cannot change it.
But I guess such a thing will need a follow-up ZIP.
Thanks. I think there is an opportunity for using it more. For example
req-memo
could indicate that the memo field must be copied into the payment screen, and perhaps locked so the user cannot change it. But I guess such a thing will need a follow-up ZIP.
The ZIP 321 specification is a living document, so changes and additions to it can be proposed via the ordinary pull-request process; zips PRs are reviewed and eventually approved or rejected by the ZIP editors.
Oh! I thought once ZIPs were ratified they couldn't be substantially changed. I do have an active PR that changes this ZIP and a few others, but it's just typo fixes.
Oh! I thought once ZIPs were ratified they couldn't be substantially changed. I do have an active PR that changes this ZIP and a few others, but it's just typo fixes.
It varies a bit by ZIP, based upon the character of the ZIP itself, but updating ZIPs is pretty common; for example, if you look at the "NU5 ZIPs" section at https://zips.z.cash/ you'll see a number of ZIPs were updated in order to facilitate NU5 deployment.
Speaking of which, @daira I think that ZIP 321 should probably be transitioned from Proposed
to Active
.
Issue by nathan-at-least Monday Nov 21, 2016 at 21:18 UTC Originally opened as https://github.com/zcash/zips/issues/94
A payment request is an opaque string which specifies details of a requested payment, such as recipient, amount, perhaps some details of the memo field contents, perhaps some UX prescriptions.
Originally posted as zcash/zcash#1877, here's that description quoted:
Note, this is distinct from [#2310] although they interact.