This is a proposal for a URI scheme to be used in the Proof of Payment
process.
== Motivation ==
To make a Proof of Payment, the party that wants the proof needs to
transfer a Proof of Payment request to the wallet software of the
other party. To facilitate that transfer, a new URI scheme
representing the PoP request is proposed. This URI can then be encoded
in QR images or be sent over NFC in order to transfer it to the wallet.
== Specification ==
The specification is the same as BIP0021, with the following
differences:
* The URI scheme is <tt>btcpop</tt> instead of <tt>bitcoin</tt>
* The path component, i.e. the address part, is always empty.
* A mandatory <tt>p</tt> parameter whose value contains the destination for the PoP. This could for example be a <tt>https:</tt> URL or a <tt>mailto:</tt> URI.
* A mandatory <tt>n</tt> parameter representing the nonce, base58 encoded.
* An optional <tt>txid</tt> parameter containing the Base58 encoded hash of the transaction to prove.
Just as in BIP0021, elements of the query component may contain
characters outside the valid range. These must first be encoded
according to UTF-8, and then each octet of the corresponding UTF-8
sequence must be percent-encoded as described in RFC 3986.
All parameters except <tt>p</tt> and <tt>n</tt> are hints to the
wallet on which transaction to create a PoP for.
The extensibility of BIP0021 applies to this scheme as well. For
example, a <tt>date</tt> parameter or a <tt>toaddr</tt> parameter
might be useful. <tt>req-*</tt> parameters are also allowed and obey
the same rules as in BIP0021, clients not supporting a <tt>req-*</tt>
parameter must consider the URI invalid.
=== Keep URIs short ===
Implementations should keep the URIs as short as possible. This is
because it makes QR decoding more stable. A camera with a scratched
lens or low resolution may run into problems scanning huge QR
codes. This is why the <tt>txid</tt> parameter is encoded in Base58
instead of the classic hex encoded string. We get away with 44
characters instead of 64. Also, the <tt>nonce</tt> parameter is Base58
encoded for the same reason.
== Interpretation ==
=== Transaction hints ===
The wallet processing the URI must use the hints in the PoP request to
filter its transaction set. The <tt>label</tt>, <tt>amount</tt> and
<tt>message</tt> parameters must, if present in the URI, exactly match
the data associated with the original payment according to the
following table:
{|
| <tt>btcpop:</tt> URI parameter || <tt>bitcoin:</tt> URI parameter || BIP70 PaymentDetails data
