📅 Original date posted:2015-06-06
📝 Original message: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
<pre>
BIP: <BIP number>
Title: Proof of Payment URI scheme
Author: Kalle Rosenbaum <kalle at rosenbaum.se>
Status: Draft
Type: Standards Track
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
</pre>
== 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 <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
|-
| <tt>label</tt> || <tt>label</tt> ||
<tt>merchant_data</tt>
|-
| <tt>amount</tt> || <tt>amount</tt> ||
<tt>sum of outputs.amount</tt>
|-
| <tt>message</tt> || <tt>message</tt> ||
<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 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 <tt>p</tt> ===
The <tt>p</tt> parameter value is the destination where 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>btcpop:</tt> URIs short, users should
not make their <tt>p</tt> parameter unneccesarily long.
==== <tt>http:</tt> and <tt>https:</tt> URLs ====
Wallet implementations must support the <tt>http:</tt> and
<tt>https:</tt> schemes in which case <tt>POST</tt> 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
<tt>https://www.example.com/pop/352</tt>;, using nonce <tt>0x73 0xd5
0x1a 0xbb 0xd8 0x9c</tt>:
btcpop:?p=https://www.example.com/pop/352&n=zgWTm8yH&label=video 42923
Send PoP through mail using
<tt>mailto:pop at example.com?subject=pop444</tt>, amount is 13370000
satoshis, nonce is <tt>0x6f 0xe 0xfb 0x68 0x92 0xf9</tt>. Note that
the <tt>?</tt> before <tt>subject</tt> is OK according to RFC3986,
since the query part starts from the first <tt>?</tt>:
btcpop:?p=mailto:pop at example.com?subject%3Dpop444&n=xJdKmEbr&amount=0.1337
Send PoP for transaction with id
<tt>cca7507897abc89628f450e8b1e0c6fca4ec3f7b34cccf55f3f531c659ff4d79</tt>
to pizza place at <tt>http://pizza.example.com/pop/laszlo111</tt>;
using nonce <tt>0xfc 0xcc 0x2c 0x35 0xf0 0xb8</tt>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150606/d3fa1871/attachment.html>;
Kalle Rosenbaum [ARCHIVE] /
npub1uw…55zf7
2023-06-07 15:37:00
in reply to nevent1q…rkaf
Author Public Key
npub1uwweecasakwtk96j3vjmkjenhnhyv4rku382txq0kmexjwuh4w2st55zf7Published at
2023-06-07 15:37:00Event JSON
{
"id": "a22354ef89f055ba11d3df306e61d6391f5a08655795c1558ccdaf62533b8db7",
"pubkey": "e39d9ce3b0ed9cbb17528b25bb4b33bcee465476e44ea5980fb6f2693b97ab95",
"created_at": 1686152220,
"kind": 1,
"tags": [
[
"e",
"cf8ade0471f625cf9ce08952d41d79cd23daa0e535637a60cc142baf0c8fb6de",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-06-06\n📝 Original message:Hi\n\nFollowing earlier posts on Proof of Payment I'm now proposing the following\nBIP for a Proof of Payment URI scheme (To read it formatted instead, go to\nhttps://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP).\n\nRegards,\nKalle Rosenbaum\n\n\u003cpre\u003e\n BIP: \u003cBIP number\u003e\n Title: Proof of Payment URI scheme\n Author: Kalle Rosenbaum \u003ckalle at rosenbaum.se\u003e\n Status: Draft\n Type: Standards Track\n Created: \u003cdate created on, in ISO 8601 (yyyy-mm-dd) format\u003e\n\u003c/pre\u003e\n\n== Abstract ==\n\nThis is a proposal for a URI scheme to be used in the Proof of Payment\nprocess.\n\n== Motivation ==\n\nTo make a Proof of Payment, the party that wants the proof needs to\ntransfer a Proof of Payment request to the wallet software of the\nother party. To facilitate that transfer, a new URI scheme\nrepresenting the PoP request is proposed. This URI can then be encoded\nin QR images or sent over NFC in order to transfer it to the wallet.\n\n== Specification ==\n\nThe specification is the same as BIP0021, with the following\ndifferences:\n\n* The URI scheme is \u003ctt\u003ebtcpop\u003c/tt\u003e instead of \u003ctt\u003ebitcoin\u003c/tt\u003e\n* The path component, i.e. the address part, is always empty.\n* A mandatory \u003ctt\u003ep\u003c/tt\u003e parameter whose value contains the destination for\nthe PoP. This could for example be a \u003ctt\u003ehttps:\u003c/tt\u003e URL or a \u003ctt\u003emailto:\u003c/tt\u003e\nURI.\n* A mandatory \u003ctt\u003en\u003c/tt\u003e parameter representing the nonce, base58 encoded.\n* An optional \u003ctt\u003etxid\u003c/tt\u003e parameter containing the Base58 encoded hash of\nthe transaction to prove.\n\nJust as in BIP0021, elements of the query component may contain\ncharacters outside the valid range. These must first be encoded\naccording to UTF-8, and then each octet of the corresponding UTF-8\nsequence must be percent-encoded as described in RFC 3986.\n\nAll parameters except \u003ctt\u003ep\u003c/tt\u003e and \u003ctt\u003en\u003c/tt\u003e are hints to the\nwallet on which transaction to create a PoP for.\n\nThe extensibility of BIP0021 applies to this scheme as well. For\nexample, a \u003ctt\u003edate\u003c/tt\u003e parameter or a \u003ctt\u003etoaddr\u003c/tt\u003e parameter\nmight be useful. \u003ctt\u003ereq-*\u003c/tt\u003e parameters are also allowed and obey\nthe same rules as in BIP0021, clients not supporting a \u003ctt\u003ereq-*\u003c/tt\u003e\nparameter must consider the URI invalid.\n\n=== Keep URIs short ===\n\nImplementations should keep the URIs as short as possible. This is\nbecause it makes QR decoding more stable. A camera with a scratched\nlens or low resolution may run into problems scanning huge QR\ncodes. This is why the \u003ctt\u003etxid\u003c/tt\u003e parameter is encoded in Base58\ninstead of the classic hex encoded string. We get away with 44\ncharacters instead of 64. Also, the \u003ctt\u003enonce\u003c/tt\u003e parameter is Base58\nencoded for the same reason.\n\n== Interpretation ==\n\n=== Transaction hints ===\n\nThe wallet processing the URI must use the hints in the PoP request to\nfilter its transaction set. The \u003ctt\u003elabel\u003c/tt\u003e, \u003ctt\u003eamount\u003c/tt\u003e and\n\u003ctt\u003emessage\u003c/tt\u003e parameters must, if present in the URI, exactly match\nthe data associated with the original payment according to the\nfollowing table:\n\n{|\n| \u003ctt\u003ebtcpop:\u003c/tt\u003e URI parameter || \u003ctt\u003ebitcoin:\u003c/tt\u003e URI parameter ||\nBIP70 PaymentDetails data\n|-\n| \u003ctt\u003elabel\u003c/tt\u003e || \u003ctt\u003elabel\u003c/tt\u003e ||\n\u003ctt\u003emerchant_data\u003c/tt\u003e\n|-\n| \u003ctt\u003eamount\u003c/tt\u003e || \u003ctt\u003eamount\u003c/tt\u003e ||\n\u003ctt\u003esum of outputs.amount\u003c/tt\u003e\n|-\n| \u003ctt\u003emessage\u003c/tt\u003e || \u003ctt\u003emessage\u003c/tt\u003e ||\n\u003ctt\u003ememo\u003c/tt\u003e\n|}\n\nThe \u003ctt\u003etxid\u003c/tt\u003e parameter value must match the transaction hash of\nthe payment.\n\nAfter filtering, the resulting transaction set is displayed to the\nuser who selects one of them to prove. An implementation could also\nautomatically select a transaction in the filtered set, but\nthere must still be a way for the user to select freely among the\nmatching transactions. If the filtered set is empty, no transaction\nfits the hints and a message about that is presented to the user. If\nthe filtered set contains exactly one transaction, which is\npreferable, that transaction can be automatically selected.\n\nAs a fallback, there must also be a way for the user to select any\ntransaction from the wallet regardless of the transaction hints. This\ncan be useful if the metadata of the wallet is lost, possibly due to a\nrestore from backup.\n\n=== PoP destination \u003ctt\u003ep\u003c/tt\u003e ===\n\nThe \u003ctt\u003ep\u003c/tt\u003e parameter value is the destination where to send the\nPoP to. This destination is typically a \u003ctt\u003ehttps:\u003c/tt\u003e URL or a\n\u003ctt\u003ehttp:\u003c/tt\u003e URL, but it could be any type of URI, for example\n\u003ctt\u003emailto:\u003c/tt\u003e. To keep \u003ctt\u003ebtcpop:\u003c/tt\u003e URIs short, users should\nnot make their \u003ctt\u003ep\u003c/tt\u003e parameter unneccesarily long.\n\n==== \u003ctt\u003ehttp:\u003c/tt\u003e and \u003ctt\u003ehttps:\u003c/tt\u003e URLs ====\n\nWallet implementations must support the \u003ctt\u003ehttp:\u003c/tt\u003e and\n\u003ctt\u003ehttps:\u003c/tt\u003e schemes in which case \u003ctt\u003ePOST\u003c/tt\u003e method must be\nused. The content type of the POST request must be set to\n\n Content-Type: application/bitcoin-pop\n Content-Transfer-Encoding: binary\n\n== Examples ==\n\nSend PoP for a transaction with label \"video 42923\" to\n\u003ctt\u003ehttps://www.example.com/pop/352\u003c/tt\u003e, using nonce \u003ctt\u003e0x73 0xd5\n0x1a 0xbb 0xd8 0x9c\u003c/tt\u003e:\n\n btcpop:?p=https://www.example.com/pop/352\u0026n=zgWTm8yH\u0026label=video 42923\n\nSend PoP through mail using\n\u003ctt\u003emailto:pop at example.com?subject=pop444\u003c/tt\u003e, amount is 13370000\nsatoshis, nonce is \u003ctt\u003e0x6f 0xe 0xfb 0x68 0x92 0xf9\u003c/tt\u003e. Note that\nthe \u003ctt\u003e?\u003c/tt\u003e before \u003ctt\u003esubject\u003c/tt\u003e is OK according to RFC3986,\nsince the query part starts from the first \u003ctt\u003e?\u003c/tt\u003e:\n\n btcpop:?p=mailto:pop at example.com?subject%3Dpop444\u0026n=xJdKmEbr\u0026amount=0.1337\n\nSend PoP for transaction with id\n\u003ctt\u003ecca7507897abc89628f450e8b1e0c6fca4ec3f7b34cccf55f3f531c659ff4d79\u003c/tt\u003e\nto pizza place at \u003ctt\u003ehttp://pizza.example.com/pop/laszlo111\u003c/tt\u003e\nusing nonce \u003ctt\u003e0xfc 0xcc 0x2c 0x35 0xf0 0xb8\u003c/tt\u003e\n\n btcpop:?p=\nhttp://pizza.example.com/pop/laszlo111\u0026n=3AtNpVrPh\u0026txid=Emt9MPvt1joznqHy5eEHkNtcuQuYWXzYJBQZN6BJm6NL\n\n== Reference implementation ==\n\n[https://github.com/kallerosenbaum/poppoc poppoc on GitHub]\n\n[https://github.com/kallerosenbaum/wallet Mycelium fork on GitHub]\n\n== References ==\n\n[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP21]: URI\nScheme\n\n[[Proof of Payment BIP]]\n\n[https://www.ietf.org/rfc/rfc3986.txt RFC3986]: Uniform Resource Identifier\n(URI): Generic Syntax\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150606/d3fa1871/attachment.html\u003e",
"sig": "3103516a576a122b9dd7841e9b75a7a6149f48bccee76ec784be6f9d2af8d20d55e9d4ee9ea2c0bbfa2bb1877f2a2c27ba145e09282f21d85945b9fb5a08f116"
}