diff --git a/zip-0321.html b/zip-0321.html index a266fb44..bdaf0669 100644 --- a/zip-0321.html +++ b/zip-0321.html @@ -46,7 +46,7 @@ License: MIT zcashparam = [ addrparam / amountparam / memoparam / messageparam / labelparam / reqparam / otherparam ] NONZERO = %x31-39 DIGIT = %x30-39 -paramindex = "." NONZERO *DIGIT +paramindex = "." NONZERO 0*3DIGIT addrparam = "address" [ paramindex ] "=" zcashaddress amountparam = "amount" [ paramindex ] "=" 1*DIGIT [ "." 1*8DIGIT ] labelparam = "label" [ paramindex ] "=" *qchar @@ -58,11 +58,13 @@ License: MIT qchar = unreserved / pct-encoded / allowed-delims / ":" / "@" allowed-delims = "!" / "$" / "'" / "(" / ")" / "*" / "+" / "," / ";"

Here, ALPHA, unreserved and pct-encoded are as defined in 3. "base58" is defined as in 6. "base64url" is defined as in 7 with padding omitted. (Note that this uses a different alphabet to the usual base64; the values 62 and 63 in the alphabet are encoded as - and _ respectively.)

-

A ZIP-321 URI represents a request for the construction of a transaction having one or more payments. In the case that only a single payment is being requested, the recipient address MAY be included in the hier-part component of the RFC 3986 URI; otherwise, multiple recipient addresses can be specified using addrparam parameters with different indices.

+

A ZIP-321 URI represents a request for the construction of a transaction having one or more payments. In the case that only a single payment is being requested, the recipient address SHOULD be included in the hier-part component of the RFC 3986 URI; otherwise, multiple recipient addresses can be specified using addrparam parameters with different indices.

Addresses, amounts, labels, and messages sharing the same paramindex (including the empty paramindex) are interpreted to be associated with the same payment for the purposes of payment construction. A paramindex MUST NOT have leading zero(s). There is no significance to the ordering of parameters, and paramindex values need not be sequential.

+

Due to fundamental restrictions on transaction construction described in 8, there may be no more than 2109 distinct payments requested by a single ZIP-321 URI.

A URI of the form zcash:<address>?... MUST be considered equivalent to a URI of the form zcash:?address=<address>&... where <address> is an instance of zcashaddress.

If there are any non-address parameters having a given paramindex, then the URI MUST contain an address parameter having that paramindex. There MUST NOT be more than one occurrence of a given parameter and paramindex.

Productions of the form 1*x indicate one or more successive instances of the production x. Productions of the form <n>*<m>x indicate at least <n> and at most <m> instances of production x.

+

Note that this grammar does not allow percent encoding outside the productions that use qchar, i.e. the values of label, message, reqparam, and otherparam parameters.

Transfer amount

If an amount is provided, it MUST be specified in decimal ZEC. If a decimal fraction is present then a period (.) MUST be used as the separating character to separate the whole number from the decimal fraction, and both the whole number and the decimal fraction MUST be nonempty. No other separators (such as commas for grouping or thousands) are permitted. Leading zeros in the whole number or trailing zeros in the decimal fraction are ignored. There MUST NOT be more than 8 digits in the decimal fraction.

@@ -75,6 +77,7 @@ License: MIT
+

The amount MUST NOT be greater than 21000000 ZEC (in general, monetary amounts in Zcash cannot be greater than this value).

Query Keys

@@ -106,13 +109,18 @@ License: MIT zcash:?amount.1=1.234&amount.1=2.345&address.1=tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU"

Also invalid; duplicate amount= or amount.1= fields

+ 
zcash:tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1%30
+zcash:tmEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?%61mount=1
+zcash:%74mEZhbWHTpdKMw5it8YDspUXSMGQyFwovpU?amount=1
+

Invalid; percent encoding is only allowed in qchar productions, which do not include addresses, amounts, or parameter names.

Forward compatibility

Variables which are prefixed with a req- are considered required. If a parser does not recognize any variables which are prefixed with req-, it MUST consider the entire URI invalid. Any other variables that are not recognized, but that are not prefixed with a req-, SHOULD be ignored.

Backward compatibility

-

As this ZIP is written, several clients already implement a zcash: URI scheme similar to this one, however usually without the additional req- prefix requirement or the facility to specify multiple payments using paramindex. Thus, it is RECOMMENDED that these features not be used in a mission-critical way until a grace period of 6 months from the finalization of this ZIP has passed, in order to allow client developers to release new versions, and users of old clients to upgrade.

+

As this ZIP is written, several clients already implement a zcash: URI scheme similar to this one, however usually without the additional req- prefix requirement or the facility to specify multiple payments using paramindex. These implementations also generally do not support URIs, even with a single payment, where the address is specified as an address= query parameter rather than in the hier-part of the URI. They may also not support the memo parameter, or may not treat it as base64url-encoded.

+

Thus, it is RECOMMENDED that these features not be used in a mission-critical way until a grace period of 6 months from the finalization of this ZIP has passed, in order to allow client developers to release new versions, and users of old clients to upgrade.

References

@@ -172,6 +180,14 @@ zcash:?amount.1=1.234&amount.1=2.345&address.1=tmEZhbWHTpdKMw5it8YDspUXS + + + + + + + +
8Restrictions on number of outputs in Zcash transactions