From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z1FIT-0003JU-0s for bitcoin-development@lists.sourceforge.net; Sat, 06 Jun 2015 14:42:05 +0000 X-ACL-Warn: Received: from mail-qg0-f44.google.com ([209.85.192.44]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z1FIR-0001Cf-94 for bitcoin-development@lists.sourceforge.net; Sat, 06 Jun 2015 14:42:05 +0000 Received: by qgg3 with SMTP id 3so14111800qgg.2 for ; Sat, 06 Jun 2015 07:41:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=e6ivAiCW4AEp5TeDEU0rQKp/13CS0TvSWkp27OhSAlk=; b=cIdQtFxzSDmNl2mAu22u2PdyfPYSDUBlJ6U/UcmN+XYowNTKB5i+dmYGqnCFx6ZW7K 5es6JE9jhixNGde5tcq79bAFplZPSW/QccKNxjIdiGXEk9wMgPVxI+SJmrmWjVDIoLiR 79nudX36cLZ5Sm4Jo/j0S0hDX6QCRcIhYhJ40y4cFB8pgO4nWnIaLtSOCwiaEvbHbhu4 gbfoKqQ9b3Xq3u782MhoicJXJNTz3GQ97Z0azFE5bpblJBUI8itvD/FA14I0SHoTTNZG bOMPWf8zt/FIHqadzO22jKSRoLRt1fvRbvCxIJ+fT57uRQgZykruQbz4bgzL8G/Z4AFx C/1w== X-Gm-Message-State: ALoCoQlyr5U/wI3m8bxJeEwY+IHeN3IcEdyBcvOc1ZM1H1GgxSJRXTcZJZItMGiE0Dwjuz6fuThd MIME-Version: 1.0 X-Received: by 10.55.16.74 with SMTP id a71mr2087578qkh.15.1433601338871; Sat, 06 Jun 2015 07:35:38 -0700 (PDT) Received: by 10.96.145.9 with HTTP; Sat, 6 Jun 2015 07:35:38 -0700 (PDT) Date: Sat, 6 Jun 2015 16:35:38 +0200 Message-ID: From: Kalle Rosenbaum To: Greg Maxwell Content-Type: multipart/alternative; boundary=001a113744728dacb10517da5209 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z1FIR-0001Cf-94 Cc: Bitcoin Dev Subject: [Bitcoin-development] BIP for PoP URI scheme X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 14:42:05 -0000 --001a113744728dacb10517da5209 Content-Type: text/plain; charset=UTF-8 Hi Following earlier posts on Proof of Payment I'm now proposing the following BIP for a Proof of Payment URI scheme (To read it formatted instead, go to https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP). Regards, Kalle Rosenbaum 
  BIP: 
  Title: Proof of Payment URI scheme
  Author: Kalle Rosenbaum 
  Status: Draft
  Type: Standards Track
  Created:
== Abstract == 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 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 btcpop instead of bitcoin * The path component, i.e. the address part, is always empty. * A mandatory p parameter whose value contains the destination for the PoP. This could for example be a https: URL or a mailto: URI. * A mandatory n parameter representing the nonce, base58 encoded. * An optional txid 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 p and n 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 date parameter or a toaddr parameter might be useful. req-* parameters are also allowed and obey the same rules as in BIP0021, clients not supporting a req-* 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 txid parameter is encoded in Base58 instead of the classic hex encoded string. We get away with 44 characters instead of 64. Also, the nonce 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 label, amount and message parameters must, if present in the URI, exactly match the data associated with the original payment according to the following table: {| | btcpop: URI parameter || bitcoin: URI parameter || BIP70 PaymentDetails data |- | label || label || merchant_data |- | amount || amount || sum of outputs.amount |- | message || message || memo |} The txid 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 them to prove. An implementation could also automatically select a transaction 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 empty, no transaction fits the hints and a message about that is presented to the user. If the filtered set contains exactly one transaction, which is preferable, that transaction can be automatically selected. As a fallback, there must also be a way for the user to select any transaction 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. === PoP destination p === The p parameter value is the destination where to send the PoP to. This destination is typically a https: URL or a http: URL, but it could be any type of URI, for example mailto:. To keep btcpop: URIs short, users should not make their p parameter unneccesarily long. ==== http: and https: URLs ==== Wallet implementations must support the http: and https: schemes in which case POST method must be used. The content type of the POST request must be set to Content-Type: application/bitcoin-pop Content-Transfer-Encoding: binary == Examples == Send PoP for a transaction with label "video 42923" to https://www.example.com/pop/352, using nonce 0x73 0xd5 0x1a 0xbb 0xd8 0x9c: btcpop:?p=https://www.example.com/pop/352&n=zgWTm8yH&label=video 42923 Send PoP through mail using mailto:pop@example.com?subject=pop444, amount is 13370000 satoshis, nonce is 0x6f 0xe 0xfb 0x68 0x92 0xf9. Note that the ? before subject is OK according to RFC3986, since the query part starts from the first ?: btcpop:?p=mailto:pop@example.com?subject%3Dpop444&n=xJdKmEbr&amount=0.1337 Send PoP for transaction with id cca7507897abc89628f450e8b1e0c6fca4ec3f7b34cccf55f3f531c659ff4d79 to pizza place at http://pizza.example.com/pop/laszlo111 using nonce 0xfc 0xcc 0x2c 0x35 0xf0 0xb8 btcpop:?p= http://pizza.example.com/pop/laszlo111&n=3AtNpVrPh&txid=Emt9MPvt1joznqHy5eEHkNtcuQuYWXzYJBQZN6BJm6NL == Reference implementation == [https://github.com/kallerosenbaum/poppoc poppoc on GitHub] [https://github.com/kallerosenbaum/wallet Mycelium fork on GitHub] == References == [https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP21]: URI Scheme [[Proof of Payment BIP]] [https://www.ietf.org/rfc/rfc3986.txt RFC3986]: Uniform Resource Identifier (URI): Generic Syntax --001a113744728dacb10517da5209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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

--001a113744728dacb10517da5209--