Hi

Following earlier posts on Proof of Payment I= 9;m now proposing the following BIP for a Proof of Payment URI scheme (To r= ead it formatted instead, go to https://github.com/kallerosenbaum/poppoc/w= iki/btcpop-scheme-BIP).

Regards,
Kalle Rosenbaum

<p= re>
=C2=A0 BIP: <BIP number>
=C2=A0 Title: Proof of Payment = URI scheme
=C2=A0 Author: Kalle Rosenbaum <kalle@rosenbaum.se>
=C2=A0 Status: Draft
=C2=A0 Ty= pe: Standards Track
=C2=A0 Created: <date created on, in ISO 8601 (yy= yy-mm-dd) format>
</pre>

=3D=3D Abstract =3D=3D

T= his is a proposal for a URI scheme to be used in the Proof of Payment
pr= ocess.

=3D=3D Motivation =3D=3D

To make a Proof of Payment, t= he party that wants the proof needs to
transfer a Proof of Payment reque= st to the wallet software of the
other party. To facilitate that transfe= r, a new URI scheme
representing the PoP request is proposed. This URI c= an then be encoded
in QR images or sent over NFC in order to transfer it= to the wallet.

=3D=3D Specification =3D=3D

The specification= is the same as BIP0021, with the following
differences:

* The UR= I 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 desti= nation 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 fir= st be encoded
according to UTF-8, and then each octet of the correspondi= ng UTF-8
sequence must be percent-encoded as described in RFC 3986.
<= br>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
exampl= e, a <tt>date</tt> parameter or a <tt>toaddr</tt> p= arameter
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.
=
=3D=3D=3D Keep URIs short =3D=3D=3D

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 p= roblems scanning huge QR
codes. This is why the <tt>txid</tt>= ; parameter is encoded in Base58
instead of the classic hex encoded stri= ng. We get away with 44
characters instead of 64. Also, the <tt>no= nce</tt> parameter is Base58
encoded for the same reason.

= =3D=3D Interpretation =3D=3D

=3D=3D=3D Transaction hints =3D=3D=3D
The wallet processing the URI must use the hints in the PoP request t= o
filter its transaction set. The <tt>label</tt>, <tt>= amount</tt> and
<tt>message</tt> parameters must, if p= resent in the URI, exactly match
the data associated with the original p= ayment according to the
following table:

{|
| <tt>btcpop= :</tt> URI parameter || <tt>bitcoin:</tt> URI parameter |= | BIP70 PaymentDetails data
|-
| <tt>label</tt> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 || <tt>label</tt&= gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|| <tt= >merchant_data</tt>
|-
| <tt>amount</tt> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|| <tt>amount</tt&= gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 || <tt>su= m of outputs.amount</tt>
|-
| <tt>message</tt> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 || <tt>message</tt&g= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|| <tt>memo= </tt>
|}

The <tt>txid</tt> parameter value must= match the transaction hash of
the payment.

After filtering, the = resulting transaction set is displayed to the
user who selects one of th= em to prove. An implementation could also
automatically select a transac= tion in the filtered set, but
there must still be a way for the user to = select freely among the
matching transactions. If the filtered set is em= pty, no transaction
fits the hints and a message about that is presented= to the user. If
the filtered set contains exactly one transaction, whic= h is
preferable, that transaction can be automatically selected.

= As a fallback, there must also be a way for the user to select any
trans= action from the wallet regardless of the transaction hints. This
can be = useful if the metadata of the wallet is lost, possibly due to a
restore = from backup.

=3D=3D=3D PoP destination <tt>p</tt> =3D=3D= =3D

The <tt>p</tt> parameter value is the destination wh= ere to send the
PoP to. This destination is typically a <tt>https:= </tt> URL or a
<tt>http:</tt> URL, but it could be any= type of URI, for example
<tt>mailto:</tt>. To keep <tt&g= t;btcpop:</tt> URIs short, users should
not make their <tt>p= </tt> parameter unneccesarily long.

=3D=3D=3D=3D <tt>htt= p:</tt> and <tt>https:</tt> URLs =3D=3D=3D=3D

Wall= et implementations must support the <tt>http:</tt> and
<t= t>https:</tt> schemes in which case <tt>POST</tt> meth= od must be
used. The content type of the POST request must be set to
=
=C2=A0Content-Type: application/bitcoin-pop
=C2=A0Content-Transfer-E= ncoding: binary

=3D=3D Examples =3D=3D

Send PoP for a transac= tion with label "video 42923" to
<tt>https://www.example.com/pop/352</tt>, us= ing nonce <tt>0x73 0xd5
0x1a 0xbb 0xd8 0x9c</tt>:

=C2= =A0btcpop:?p=3Dhttps://www.example.com/pop/352&n=3DzgWTm8yH&lab= el=3Dvideo 42923

Send PoP through mail using
<tt>mailto= :pop@example.com?subject=3Dpop444<= ;/tt>, amount is 13370000
satoshis, nonce is <tt>0x6f 0xe 0xfb = 0x68 0x92 0xf9</tt>. Note that
the <tt>?</tt> before &= lt;tt>subject</tt> is OK according to RFC3986,
since the query = part starts from the first <tt>?</tt>:

=C2=A0btcpop:?p= =3Dmailto:pop@example.com?subject%3D= pop444&n=3DxJdKmEbr&amount=3D0.1337

Send PoP for transaction= with id
<tt>cca7507897abc89628f450e8b1e0c6fca4ec3f7b34cccf55f3f53= 1c659ff4d79</tt>
to pizza place at <tt>http://pizza.example.com/pop/laszlo111<= ;/tt>
using nonce <tt>0xfc 0xcc 0x2c 0x35 0xf0 0xb8</tt><= br>
=C2=A0btcpop:?p=3D= http://pizza.example.com/pop/laszlo111&n=3D3AtNpVrPh&txid=3DEmt9MPv= t1joznqHy5eEHkNtcuQuYWXzYJBQZN6BJm6NL

=3D=3D Reference implement= ation =3D=3D

[h= ttps://github.com/kallerosenbaum/poppoc poppoc on GitHub]

[https://github.com/kalleros= enbaum/wallet Mycelium fork on GitHub]

=3D=3D References =3D=3D<= br>
[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki = BIP21]: URI Scheme

[[Proof of Payment BIP]]

[https://www.ietf.org/rfc/rfc3986.txt R= FC3986]: Uniform Resource Identifier (URI): Generic Syntax