path: root/74/b723ac7408cff39bfbf9761dd4ea7eb9c34385

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 <mark@monetize.io>) id 1TmbNg-0001MS-9n
	for bitcoin-development@lists.sourceforge.net;
	Sun, 23 Dec 2012 02:33:36 +0000
Received: from mail-qc0-f173.google.com ([209.85.216.173])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1TmbNY-0000cJ-OT
	for bitcoin-development@lists.sourceforge.net;
	Sun, 23 Dec 2012 02:33:36 +0000
Received: by mail-qc0-f173.google.com with SMTP id b12so3211091qca.4
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 22 Dec 2012 18:33:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=LN1bDSOOSgtcofoxizmIN0ARym95zuTm/J2P0dsSWmg=;
	b=Lz+zJxrAw0BsitJmNgt/A5XkTwAOzBw/3borxUFxQXbrWKx/vCxc20ZC+V4+Jpk2+R
	6B6AOUdekBGKS97DoziZ4yJ2pQkCVmFdf65hGm1cDsajmcMM/cNSsgP3V0Bb21uB4Qg8
	1oRDOIXRXyRuEZiNJqg3GcjWJPaNKhyPT0SKm5IZSE1kjdspcfRxpr2SdkF+ikZONvw6
	Poe/WHu5CQaWV5D1sp5ERWTwuc4vw8HgNjRwFlhPPRkL9GTE+LD590fkEfw8UxLltjJC
	3F/XUskeyz0uOm03bkqBxp2W8RGkK32i8/LhjNKN1jcvkopip3LepWKWpokTmDSAokLI
	JPQw==
MIME-Version: 1.0
Received: by 10.224.70.202 with SMTP id e10mr9102166qaj.69.1356230002875; Sat,
	22 Dec 2012 18:33:22 -0800 (PST)
Received: by 10.49.0.235 with HTTP; Sat, 22 Dec 2012 18:33:22 -0800 (PST)
X-Originating-IP: [50.0.36.26]
In-Reply-To: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
Date: Sat, 22 Dec 2012 18:33:22 -0800
Message-ID: <CACh7GpH107B9XVVCTU0Mm0fCDz9yn7NzkdzNcUnKry=D=GuMdg@mail.gmail.com>
From: Mark Friedenbach <mark@monetize.io>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec51b18e78e1c7904d17be779
X-Gm-Message-State: ALoCoQmpkHKnl6hVU8qmUUrVqP/9Xq+jUam2gtX26uC23Z6lOC3EG71eQctd6H2YdYeOWyrI9yQr
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.3 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread)
	[URIs: ietf.org]
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1TmbNY-0000cJ-OT
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 23 Dec 2012 02:33:36 -0000

--bcaec51b18e78e1c7904d17be779
Content-Type: text/plain; charset=UTF-8

I hope that this input does not come too late; I haven't had time to review
the proposal until now.

For alt-chains that have time-varying value (Freicoin[1], currently), it is
necessary in some applications to include a "reference height" in the
invoice. Since the bitcoin protocol does not assume a universally
agreed-upon time source, Freicoin (and presumably other
yet-to-be-implemented time-varying chains) uses blocktime as the clock for
time-value calculations: outputs lose 2**-20 of their value with each
passing block. The reference height for an invoice is the blocktime at
which amount values are specified and the reference point for time-varying
calculations. As a concrete example, an invoice for payment of 50 frc today
could be satisfied by 49.99313402 frc tomorrow.

To implement this, we would require an optional "uint64 refheight" field in
the invoice structure. "refheight" or "nRefHeight" is what we call this
value internally, but "blocktime" or "blockheight" would work as well.

Github is currently down, so I apologize if a suitable field has already
been added.

Cheers,
Mark Friedenbach

[1] http://freico.in/ "Freicoin: a P2P digital currency delivering freedom
from usury."


On Mon, Nov 26, 2012 at 2:37 PM, Gavin Andresen <gavinandresen@gmail.com>wrote:

> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else is going to do it then I will
> (eventually) too..."
>
> Thanks to Pieter Wuille and Mike Hearn for lots of feedback and
> suggestions and brainstorming.
>
> This document is online at https://gist.github.com/4120476
>
> If you respond to this message, please be considerate of people who
> subscribe to the digest version of this mailing list and trim your
> response.
>
>
> Invoices, Payments and Receipts for Bitcoin Transactions
> ========================================================
>
> This document proposes protocol buffer-based formats for signed,
> authenticated "invoices" and "receipts" -- requests for payment, and
> proof-of-payment.
>
> Separate documents propose an extension to the Bitcoin URI syntax and
> new MIME types to support them.
>
> Motivation
> ==========
>
> The idea of a "payment protocol" to improve on Bitcoin addresses has
> been around for over a year. Users have been asking for some features
> in this proposal (like the ability to provide a refund address so
> overpayments or refunds can be returned to customers without the need
> to ask them for their address) for two or three years, and have
> started to work around shortcomings in the Bitcoin payment process
> with creative (but inefficient) uses of transactions.
>
> The key features of this proposal are:
>
> + Requests for payment (Invoices) are tied to authenticated identities
> using the only widely-deployed identity authentication system we have
> right now (X.509 certificates signed by root certificate authorities)
> + Invoices include a user-friendly description of what the payment is for
> + Payments include where refunds should be sent
> + At the end of the payment process, the customer holds a
> cryptographically signed Receipt that can be used as proof-of-payment
> if there is any dispute with the merchant.
>
>
> Specification
> =============
>
> Invoice/SignedInvoice
> ---------------------
>
> An Invoice is a request for payment from a merchant to a customer:
>
> ::
>
>     message Output {
>         optional uint64 amount = 1;
>         required bytes script = 2;
>     }
>
> amount: Number of satoshis (0.00000001 BTC) to be paid. If not given
> or zero, then the customer will be asked how much to pay.
>
> script: a "TxOut" script to which the customer should direct payment.
> This will normally be one of the standard Bitcoin transaction script
> (e.g. pubkey OP_CHECKSIG).
>
> ::
>
>     message Invoice {
>         repeated bytes x509chain = 1;
>         repeated Output outputs = 2;
>         required uint64 time = 3;
>         optional uint64 expires = 4;
>         optional bool single_use = 5 [default = true];
>         optional string memo = 6;
>         optional string receiptURI = 7;
>         optional bytes merchant_data = 8;
>     }
>
> outputs: one or more outputs where Bitcoins are to be sent.
>
> x509chain: one or more DER-encoded X.509 certificates that identifies
> the merchant. See the "Certificates" section below for details.
>
> time: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was
> created.
>
> expires: Unix timestamp after which the Invoice should be considered
> invalid. If not given, the Invoice may be re-used until the earliest
> certificate expiration date in the X509chain.
>
> single_use: If true, this Invoice should be used for only one payment.
> If false, it may be added to the user's address book and used
> repeatedly until it expires (e.g. for donations or a recurring
> payment).
>
> memo: UTF-8 encoded, plain-text (no formatting) note that should be
> displayed to the customer, explaining what this Invoice is for.
>
> receiptURI: Secure (https) URI where a Payment message (see below) may
> be sent to obtain a SignedReceipt as proof-of-payment.
>
> merchant_data : Arbitrary data ignored by the client that may be used
> by the merchant to identify the Invoice.
>
> ::
>
>     message SignedInvoice {
>         required Invoice invoice = 1;
>         required bytes signature = 2;
>     }
>
> A SignedInvoice is an Invoice signed using the private key
> corresponding to the public key in the first certificate in the
> x509chain and the HMAC SHA-256 algorithm.
>
> When a Bitcoin client receives a SignedInvoice, it must authorize
> payment by doing the following:
>
> 1. Validate the x509chain certificate chain up to it's list of root
> certificate authorities
> 2. Validate that the time on the customer's system is before
> Invoice.expires
> 3. Display the "Common Name" (CN) string from the first x509chain
> certificate and ask the customer if they would like to submit payment
>
> Payment
> -------
>
> ::
>
>     message Payment {
>         required Invoice invoice = 1;
>         repeated bytes transactions = 2;
>         repeated Output refund_to = 3;
>         optional string memo = 4;
>     }
>
> invoice : the invoice received from the merchant. A merchant must
> validate the Invoice and may reject the Payment if the Invoice was
> altered by the customer.
>
> transactions : One or more valid, signed Bitcoin transactions that
> fully pay the Invoice
>
> refund_to : One or more outputs where the merchant may return funds,
> if necessary.
>
> memo : UTF-8 encoded, plain-text note from the customer to the merchant.
>
> If the customer authorizes payment, then the Bitcoin client:
>
> 1. Creates and signs a transaction with one output sending the
> Invoice.script
> 2. If there is no Invoice.receiptURI, then the transaction is
> broadcast on the Bitcoin p2p network.
> 3. Else POST a Payment message to Invoice.receiptURI and expect a
> SignedReceipt in response.
>
> Invoice.receiptURI must be secure against man-in-the-middle attacks
> that might alter Payment.refund_to.
>
> *Note: an alternative would be a SignedPayment message that ties the
> signatures in Payment.transactions to a signature for the entire
> Payment message. Spending multisig inputs that may be controlled by
> more than one person or spending arbitrary non-standard transactions
> makes that non-trivial.*
>
> Receipt/SignedReceipt
> ---------------------
>
> ::
>
>     message Receipt {
>         required Payment payment = 1;
>         required bool accepted = 2;
>         optional string memo = 3;
>     }
>
> accepted : true if the Payment is accepted and will be broadcast on
> the Bitcoin p2p network.
>
> memo : UTF-8 encoded note that should be displayed to the customer
> indicating that the transaction is complete.
>
> ::
>
>     message SignedReceipt {
>         required Receipt receipt = 1;
>         required bytes signature = 3;
>     }
>
> A SignedReceipt is a Receipt signed using the private key
> corresponding to the public key in the first certificate in the
> Receipt->Payment->Invoice.x509chain and the HMAC SHA-256 algorithm.
>
> Upon receiving a SignedReceipt, a Bitcoin client should validate the
> signature and, if valid, display the Receipt.memo and store the
> SignedReceipt as proof-of-payment.
>
> If a SignedReceipt is not received for any reason (timeout, error) and
> Payment.transactions has not been broadcast by the merchant on the
> Bitcoin p2p network, then the Bitcoin client should assume that the
> payment failed, inform the customer that the payment failed, and
> return coins involved in the transaction to the customer's wallet.
>
>
> Certificates
> ============
>
> The Invoice.x509chain (X.509 Certificate Chain) field contains the
> X.509 public key certificate or certificate chain [RFC5280]
> corresponding to the key used to digitally sign the Invoice and
> Receipt. The certificate or certificate chain is represented as an
> array of DER [ITU.X690.1994] PKIX certificate value. The certificate
> containing the public key of the entity that digitally signed the
> Invoice MUST be the first certificate. This MAY be followed by
> additional certificates, with each subsequent certificate being the
> one used to certify the previous one. The recipient MUST verify the
> certificate chain according to [RFC5280] and reject the payment
> request if any validation failure occurs.
>
> *What should we say about root certificates and certificate management
> in general? Any requirements, or leave it up to each Bitcoin client to
> determine which root CA's are trustworthy, as happens with web
> browsers? Gavin suggests trusting only (say) ten of the Extended
> Validation authorities:
>
> http://en.wikipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certificate_identification
> *
>
> *X.509 is widely criticised for doing too much. However, it is the
> Public Key Infrastructure (PKI) system we're stuck with. Do web
> browsers / certificate authorities support the full X.509 spec, or
> only a subset? Should Bitcoin clients only support some well-defined
> subset of X.509 ? More research needed here... *
>
> Use Cases
> =========
>
> Merchant Payment Service
> ------------------------
>
> A merchant payment service (like Paysius or bit-pay.com) would use
> Invoices and Receipts as follows:
>
> 1. Merchant pays for a certificate from a certificate authority, and
> then gives the payment service the certificate and their private key.
> This could be the same certificate and private key as is used for the
> merchant's web site, but best security practice would be to purchase a
> separate certificate for authenticating Invoices. Very successful
> merchant payment services might act as intermediate certificate
> authorities, issuing certificates for their merchants.
> 2. Customer goes through the checkout process on either the merchant's
> or payment service's web site.
> 3. At the end of the checkout process, a SignedInvoice is generated
> and sent to the customer's Bitcoin client.
> 4. Customer's Bitcoin client displays the Invoice, showing that the
> payment is for the merchant.
> 5. On customer approval, a Payment is sent to the payment service's
> paymentURI. The merchant is notified of the payment, and the customer
> receives a SignedReceipt as proof-of-payment.
>
> SatoshiDice
> -----------
>
> SatoshiDice (www.satoshidice.com) is an extremely popular game that
> uses tiny transactions for some customer/service communications. In
> particular, customers can add an extra output to their transactions to
> indicate where winnings should be sent. And SatoshiDice creates tiny
> transactions to let their customers know that a bet was received, but
> lost.
>
> Assuming Bitcoin clients upgrade to support this proposal, a bet on
> SatoshiDice would proceed as follows:
>
> 1. Customer clicks on a link on SatoshiDice.com and their Bitcoin
> client receives a SignedInvoice.
> 2. Customer authorizes payment, and their Bitcoin client creates a
> Payment message and submits it directly to
> https://satoshidice.com/something
> 3. The SatoshiDice web server checks to make sure the transaction is
> valid, broadcasts it, and determines whether the customer wins or
> loses. It returns a SignedReceipt with either a "You win" or "You
> lost" memo.
> 4. If the customer won, it broadcasts a transaction to pay them using
> Payment.refund_to
> 5. Customer's Bitcoin client displays the win/lose memo, and if they
> won the winnings appear in their wallet when received over the p2p
> network.
>
> Multiperson Wallet
> ------------------
>
> This use case starts with a multi-signature Bitcoin address or wallet,
> with keys held by two different people (Alice and Bob). Payments from
> that address/wallet must be authorized by both Alice and Bob, and both
> are running multi-signature-capable Bitcoin clients.
>
> Alice begins the payment process by getting a SignedInvoice from a
> merchant that needs to be paid. She authorizes payment and her Bitcoin
> client creates a Payment message with a partially-signed transaction,
> which is then sent to Bob any way that is convenient (email
> attachment, smoke signals...).
>
> Bob's Bitcoin client validates the SignedInvoice and asks Bob to
> authorize the transaction. He says OK, his Bitcoin client completes
> the transaction by providing his signature, submits the payment to the
> merchant, and then sends a message to Alice with the SignedReceipt he
> received from the merchant, completing the payment process.
>
>
> Design Notes
> ============
>
> Why X.509 Certificates?
> -----------------------
>
> This proposal uses X.509 certificates as the identity system for
> merchants because most of them will have already purchased a
> certificate to secure their website and will be familiar with the
> process of proving their identity to a certificate issuing authority.
>
> Implementing a better global PKI is outside the scope of this
> proposal. If a better PKI is adopted, the only change to this proposal
> would be to replace the Invoice.x509chain with whatever that better
> infrastructure uses to identify entities.
>
>
> Why not JSON?
> -------------
>
> Invoice, Payment and Receipt messages could all be JSON-encoded. And
> the Javascript Object Signing and Encryption (JOSE) working group at
> the IETF has a draft specification for signing JSON data.
>
> But the spec is non-trivial. Signing JSON data is troublesome because
> JSON can encode the same data in multiple ways (whitespace is
> insignificant, characters in strings can be represented escaped or
> un-escaped, etc.), and the standards committee identified at least one
> security-related issue that will require special JSON parsers for
> handling JSON-Web-Signed (JWS) data (duplicate keys must be rejected
> by the parser, which is more strict than the JSON spec requires).
>
> A binary message format has none of those complicating issues. Which
> encoding format to pick is largely a matter of taste, but Protocol
> Buffers is a simple, robust, multi-programming-language,
> well-documented, easy-to-work-with, extensible format.
>
> What about a merchant-pays-fee feature?
> ---------------------------------------
>
> It is desireable to allow a merchant to pay the cost of any Bitcoin
> network transaction processing fees, so if a customer is paying for a
> 1 BTC item they pay exactly 1 BTC.
>
> One way of accomplishing that is to add a 'maxfee' field to the
> Invoice, and have the Bitcoin client construct a transaction that pays
> the merchant (amount-maxfee).
>
> Another way of accomplishing that is to change the transaction
> selection code used by Bitcoin miners, so that dependent transactions
> are considered as a group. Then a merchant with several unconfirmed
> zero-fee transaction from customers can create a pay-to-self
> transaction with a large enough fee to pay for the set of transactions
> to be confirmed.
>
> A third way of accomplishing that is for the Bitcoin client to sign
> Payment.transactions[0] using the SIGHASH_ANYONECANPAY flag, and for
> the merchant to add an additional, small-BTC-value input to the
> transaction before broadcasting it. That additional input would go
> directly to miners as a fee. *Note: Gavin is not sure if he loves or
> hates this idea.*
>
> Checking for revoked certificates
> ---------------------------------
>
> The Online Certificate Checking Protocol (OCSP) is supposed to be a
> quick and easy way for applications to check for revoked certificates.
>
> In practice, it doesn't work very well. Certificate Authorities have
> no financial incentive to support a robust infrastructure that can
> handle millions of OCSP validation requests quickly.
>
> Ideally, Bitcoin clients would use OCSP to check certificate statuses
> every time they received or re-used an Invoice. But if that results in
> long pauses or lots of false-positive rejections (because an OCSP
> endpoint is offline or overwhelmed, perhaps) then merchants and
> customers might revert to just using "never fails" Bitcoin addresses.
>
>
>
> References
> ==========
>
> Public-Key Infrastructure (X.509) working group :
> http://datatracker.ietf.org/wg/pkix/charter/
>
> RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate
> Status Protocol - OCSP : http://tools.ietf.org/html/rfc2560
>
> Protocol Buffers : https://developers.google.com/protocol-buffers/
>
> See Also
> ========
>
> Javascript Object Signing and Encryption working group :
> http://datatracker.ietf.org/wg/jose/
>
> sipa's payment protocol proposal: https://gist.github.com/1237788
>
> ThomasV's "Signed Aliases" proposal : http://ecdsa.org/bitcoin_URIs.html
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--bcaec51b18e78e1c7904d17be779
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I hope that this input does not come too late; I haven&#39;t had time to re=
view the proposal until now.<br><br>For alt-chains that have time-varying v=
alue (Freicoin[1], currently), it is necessary in some applications to incl=
ude a &quot;reference height&quot; in the invoice. Since the bitcoin protoc=
ol does not assume a universally agreed-upon time source, Freicoin (and pre=
sumably other yet-to-be-implemented time-varying chains) uses blocktime as =
the clock for time-value calculations: outputs lose 2**-20 of their value w=
ith each passing block. The reference height for an invoice is the blocktim=
e at which amount values are specified and the reference point for time-var=
ying calculations. As a concrete example, an invoice for payment of 50 frc =
today could be satisfied by 49.99313402 frc tomorrow.<br>
<br>To implement this, we would require an optional &quot;uint64 refheight&=
quot; field in the invoice structure. &quot;refheight&quot; or &quot;nRefHe=
ight&quot; is what we call this value internally, but &quot;blocktime&quot;=
 or &quot;blockheight&quot; would work as well.<br>
<br>Github is currently down, so I apologize if a suitable field has alread=
y been added.<br><br>Cheers,<br>Mark Friedenbach<br><br>[1] <a href=3D"http=
://freico.in/">http://freico.in/</a> &quot;Freicoin: a P2P digital currency=
 delivering freedom from usury.&quot;<br>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Nov 2=
6, 2012 at 2:37 PM, Gavin Andresen <span dir=3D"ltr">&lt;<a href=3D"mailto:=
gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">This is the next big &quot;lets all agree to=
 do things the same way&quot; thing<br>
I think we should tackle. I&#39;m particularly looking for feedback from<br=
>
other bitcoin client developers, even if it is just a quick &quot;looks<br>
reasonable, if everybody else is going to do it then I will<br>
(eventually) too...&quot;<br>
<br>
Thanks to Pieter Wuille and Mike Hearn for lots of feedback and<br>
suggestions and brainstorming.<br>
<br>
This document is online at <a href=3D"https://gist.github.com/4120476" targ=
et=3D"_blank">https://gist.github.com/4120476</a><br>
<br>
If you respond to this message, please be considerate of people who<br>
subscribe to the digest version of this mailing list and trim your<br>
response.<br>
<br>
<br>
Invoices, Payments and Receipts for Bitcoin Transactions<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D<br>
<br>
This document proposes protocol buffer-based formats for signed,<br>
authenticated &quot;invoices&quot; and &quot;receipts&quot; -- requests for=
 payment, and<br>
proof-of-payment.<br>
<br>
Separate documents propose an extension to the Bitcoin URI syntax and<br>
new MIME types to support them.<br>
<br>
Motivation<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
The idea of a &quot;payment protocol&quot; to improve on Bitcoin addresses =
has<br>
been around for over a year. Users have been asking for some features<br>
in this proposal (like the ability to provide a refund address so<br>
overpayments or refunds can be returned to customers without the need<br>
to ask them for their address) for two or three years, and have<br>
started to work around shortcomings in the Bitcoin payment process<br>
with creative (but inefficient) uses of transactions.<br>
<br>
The key features of this proposal are:<br>
<br>
+ Requests for payment (Invoices) are tied to authenticated identities<br>
using the only widely-deployed identity authentication system we have<br>
right now (X.509 certificates signed by root certificate authorities)<br>
+ Invoices include a user-friendly description of what the payment is for<b=
r>
+ Payments include where refunds should be sent<br>
+ At the end of the payment process, the customer holds a<br>
cryptographically signed Receipt that can be used as proof-of-payment<br>
if there is any dispute with the merchant.<br>
<br>
<br>
Specification<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Invoice/SignedInvoice<br>
---------------------<br>
<br>
An Invoice is a request for payment from a merchant to a customer:<br>
<br>
::<br>
<br>
=C2=A0 =C2=A0 message Output {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 optional uint64 amount =3D 1;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 required bytes script =3D 2;<br>
=C2=A0 =C2=A0 }<br>
<br>
amount: Number of satoshis (0.00000001 BTC) to be paid. If not given<br>
or zero, then the customer will be asked how much to pay.<br>
<br>
script: a &quot;TxOut&quot; script to which the customer should direct paym=
ent.<br>
This will normally be one of the standard Bitcoin transaction script<br>
(e.g. pubkey OP_CHECKSIG).<br>
<br>
::<br>
<br>
=C2=A0 =C2=A0 message Invoice {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 repeated bytes x509chain =3D 1;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 repeated Output outputs =3D 2;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 required uint64 time =3D 3;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 optional uint64 expires =3D 4;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 optional bool single_use =3D 5 [default =3D tru=
e];<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 optional string memo =3D 6;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 optional string receiptURI =3D 7;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 optional bytes merchant_data =3D 8;<br>
=C2=A0 =C2=A0 }<br>
<br>
outputs: one or more outputs where Bitcoins are to be sent.<br>
<br>
x509chain: one or more DER-encoded X.509 certificates that identifies<br>
the merchant. See the &quot;Certificates&quot; section below for details.<b=
r>
<br>
time: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was create=
d.<br>
<br>
expires: Unix timestamp after which the Invoice should be considered<br>
invalid. If not given, the Invoice may be re-used until the earliest<br>
certificate expiration date in the X509chain.<br>
<br>
single_use: If true, this Invoice should be used for only one payment.<br>
If false, it may be added to the user&#39;s address book and used<br>
repeatedly until it expires (e.g. for donations or a recurring<br>
payment).<br>
<br>
memo: UTF-8 encoded, plain-text (no formatting) note that should be<br>
displayed to the customer, explaining what this Invoice is for.<br>
<br>
receiptURI: Secure (https) URI where a Payment message (see below) may<br>
be sent to obtain a SignedReceipt as proof-of-payment.<br>
<br>
merchant_data : Arbitrary data ignored by the client that may be used<br>
by the merchant to identify the Invoice.<br>
<br>
::<br>
<br>
=C2=A0 =C2=A0 message SignedInvoice {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 required Invoice invoice =3D 1;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 required bytes signature =3D 2;<br>
=C2=A0 =C2=A0 }<br>
<br>
A SignedInvoice is an Invoice signed using the private key<br>
corresponding to the public key in the first certificate in the<br>
x509chain and the HMAC SHA-256 algorithm.<br>
<br>
When a Bitcoin client receives a SignedInvoice, it must authorize<br>
payment by doing the following:<br>
<br>
1. Validate the x509chain certificate chain up to it&#39;s list of root<br>
certificate authorities<br>
2. Validate that the time on the customer&#39;s system is before Invoice.ex=
pires<br>
3. Display the &quot;Common Name&quot; (CN) string from the first x509chain=
<br>
certificate and ask the customer if they would like to submit payment<br>
<br>
Payment<br>
-------<br>
<br>
::<br>
<br>
=C2=A0 =C2=A0 message Payment {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 required Invoice invoice =3D 1;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 repeated bytes transactions =3D 2;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 repeated Output refund_to =3D 3;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 optional string memo =3D 4;<br>
=C2=A0 =C2=A0 }<br>
<br>
invoice : the invoice received from the merchant. A merchant must<br>
validate the Invoice and may reject the Payment if the Invoice was<br>
altered by the customer.<br>
<br>
transactions : One or more valid, signed Bitcoin transactions that<br>
fully pay the Invoice<br>
<br>
refund_to : One or more outputs where the merchant may return funds,<br>
if necessary.<br>
<br>
memo : UTF-8 encoded, plain-text note from the customer to the merchant.<br=
>
<br>
If the customer authorizes payment, then the Bitcoin client:<br>
<br>
1. Creates and signs a transaction with one output sending the Invoice.scri=
pt<br>
2. If there is no Invoice.receiptURI, then the transaction is<br>
broadcast on the Bitcoin p2p network.<br>
3. Else POST a Payment message to Invoice.receiptURI and expect a<br>
SignedReceipt in response.<br>
<br>
Invoice.receiptURI must be secure against man-in-the-middle attacks<br>
that might alter Payment.refund_to.<br>
<br>
*Note: an alternative would be a SignedPayment message that ties the<br>
signatures in Payment.transactions to a signature for the entire<br>
Payment message. Spending multisig inputs that may be controlled by<br>
more than one person or spending arbitrary non-standard transactions<br>
makes that non-trivial.*<br>
<br>
Receipt/SignedReceipt<br>
---------------------<br>
<br>
::<br>
<br>
=C2=A0 =C2=A0 message Receipt {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 required Payment payment =3D 1;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 required bool accepted =3D 2;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 optional string memo =3D 3;<br>
=C2=A0 =C2=A0 }<br>
<br>
accepted : true if the Payment is accepted and will be broadcast on<br>
the Bitcoin p2p network.<br>
<br>
memo : UTF-8 encoded note that should be displayed to the customer<br>
indicating that the transaction is complete.<br>
<br>
::<br>
<br>
=C2=A0 =C2=A0 message SignedReceipt {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 required Receipt receipt =3D 1;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 required bytes signature =3D 3;<br>
=C2=A0 =C2=A0 }<br>
<br>
A SignedReceipt is a Receipt signed using the private key<br>
corresponding to the public key in the first certificate in the<br>
Receipt-&gt;Payment-&gt;Invoice.x509chain and the HMAC SHA-256 algorithm.<b=
r>
<br>
Upon receiving a SignedReceipt, a Bitcoin client should validate the<br>
signature and, if valid, display the Receipt.memo and store the<br>
SignedReceipt as proof-of-payment.<br>
<br>
If a SignedReceipt is not received for any reason (timeout, error) and<br>
Payment.transactions has not been broadcast by the merchant on the<br>
Bitcoin p2p network, then the Bitcoin client should assume that the<br>
payment failed, inform the customer that the payment failed, and<br>
return coins involved in the transaction to the customer&#39;s wallet.<br>
<br>
<br>
Certificates<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
The Invoice.x509chain (X.509 Certificate Chain) field contains the<br>
X.509 public key certificate or certificate chain [RFC5280]<br>
corresponding to the key used to digitally sign the Invoice and<br>
Receipt. The certificate or certificate chain is represented as an<br>
array of DER [ITU.X690.1994] PKIX certificate value. The certificate<br>
containing the public key of the entity that digitally signed the<br>
Invoice MUST be the first certificate. This MAY be followed by<br>
additional certificates, with each subsequent certificate being the<br>
one used to certify the previous one. The recipient MUST verify the<br>
certificate chain according to [RFC5280] and reject the payment<br>
request if any validation failure occurs.<br>
<br>
*What should we say about root certificates and certificate management<br>
in general? Any requirements, or leave it up to each Bitcoin client to<br>
determine which root CA&#39;s are trustworthy, as happens with web<br>
browsers? Gavin suggests trusting only (say) ten of the Extended<br>
Validation authorities:<br>
<a href=3D"http://en.wikipedia.org/wiki/Extended_Validation_Certificate#Ext=
ended_Validation_certificate_identification" target=3D"_blank">http://en.wi=
kipedia.org/wiki/Extended_Validation_Certificate#Extended_Validation_certif=
icate_identification</a><br>

*<br>
<br>
*X.509 is widely criticised for doing too much. However, it is the<br>
Public Key Infrastructure (PKI) system we&#39;re stuck with. Do web<br>
browsers / certificate authorities support the full X.509 spec, or<br>
only a subset? Should Bitcoin clients only support some well-defined<br>
subset of X.509 ? More research needed here... *<br>
<br>
Use Cases<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Merchant Payment Service<br>
------------------------<br>
<br>
A merchant payment service (like Paysius or <a href=3D"http://bit-pay.com" =
target=3D"_blank">bit-pay.com</a>) would use<br>
Invoices and Receipts as follows:<br>
<br>
1. Merchant pays for a certificate from a certificate authority, and<br>
then gives the payment service the certificate and their private key.<br>
This could be the same certificate and private key as is used for the<br>
merchant&#39;s web site, but best security practice would be to purchase a<=
br>
separate certificate for authenticating Invoices. Very successful<br>
merchant payment services might act as intermediate certificate<br>
authorities, issuing certificates for their merchants.<br>
2. Customer goes through the checkout process on either the merchant&#39;s<=
br>
or payment service&#39;s web site.<br>
3. At the end of the checkout process, a SignedInvoice is generated<br>
and sent to the customer&#39;s Bitcoin client.<br>
4. Customer&#39;s Bitcoin client displays the Invoice, showing that the<br>
payment is for the merchant.<br>
5. On customer approval, a Payment is sent to the payment service&#39;s<br>
paymentURI. The merchant is notified of the payment, and the customer<br>
receives a SignedReceipt as proof-of-payment.<br>
<br>
SatoshiDice<br>
-----------<br>
<br>
SatoshiDice (<a href=3D"http://www.satoshidice.com" target=3D"_blank">www.s=
atoshidice.com</a>) is an extremely popular game that<br>
uses tiny transactions for some customer/service communications. In<br>
particular, customers can add an extra output to their transactions to<br>
indicate where winnings should be sent. And SatoshiDice creates tiny<br>
transactions to let their customers know that a bet was received, but<br>
lost.<br>
<br>
Assuming Bitcoin clients upgrade to support this proposal, a bet on<br>
SatoshiDice would proceed as follows:<br>
<br>
1. Customer clicks on a link on SatoshiDice.com and their Bitcoin<br>
client receives a SignedInvoice.<br>
2. Customer authorizes payment, and their Bitcoin client creates a<br>
Payment message and submits it directly to<br>
<a href=3D"https://satoshidice.com/something" target=3D"_blank">https://sat=
oshidice.com/something</a><br>
3. The SatoshiDice web server checks to make sure the transaction is<br>
valid, broadcasts it, and determines whether the customer wins or<br>
loses. It returns a SignedReceipt with either a &quot;You win&quot; or &quo=
t;You<br>
lost&quot; memo.<br>
4. If the customer won, it broadcasts a transaction to pay them using<br>
Payment.refund_to<br>
5. Customer&#39;s Bitcoin client displays the win/lose memo, and if they<br=
>
won the winnings appear in their wallet when received over the p2p<br>
network.<br>
<br>
Multiperson Wallet<br>
------------------<br>
<br>
This use case starts with a multi-signature Bitcoin address or wallet,<br>
with keys held by two different people (Alice and Bob). Payments from<br>
that address/wallet must be authorized by both Alice and Bob, and both<br>
are running multi-signature-capable Bitcoin clients.<br>
<br>
Alice begins the payment process by getting a SignedInvoice from a<br>
merchant that needs to be paid. She authorizes payment and her Bitcoin<br>
client creates a Payment message with a partially-signed transaction,<br>
which is then sent to Bob any way that is convenient (email<br>
attachment, smoke signals...).<br>
<br>
Bob&#39;s Bitcoin client validates the SignedInvoice and asks Bob to<br>
authorize the transaction. He says OK, his Bitcoin client completes<br>
the transaction by providing his signature, submits the payment to the<br>
merchant, and then sends a message to Alice with the SignedReceipt he<br>
received from the merchant, completing the payment process.<br>
<br>
<br>
Design Notes<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Why X.509 Certificates?<br>
-----------------------<br>
<br>
This proposal uses X.509 certificates as the identity system for<br>
merchants because most of them will have already purchased a<br>
certificate to secure their website and will be familiar with the<br>
process of proving their identity to a certificate issuing authority.<br>
<br>
Implementing a better global PKI is outside the scope of this<br>
proposal. If a better PKI is adopted, the only change to this proposal<br>
would be to replace the Invoice.x509chain with whatever that better<br>
infrastructure uses to identify entities.<br>
<br>
<br>
Why not JSON?<br>
-------------<br>
<br>
Invoice, Payment and Receipt messages could all be JSON-encoded. And<br>
the Javascript Object Signing and Encryption (JOSE) working group at<br>
the IETF has a draft specification for signing JSON data.<br>
<br>
But the spec is non-trivial. Signing JSON data is troublesome because<br>
JSON can encode the same data in multiple ways (whitespace is<br>
insignificant, characters in strings can be represented escaped or<br>
un-escaped, etc.), and the standards committee identified at least one<br>
security-related issue that will require special JSON parsers for<br>
handling JSON-Web-Signed (JWS) data (duplicate keys must be rejected<br>
by the parser, which is more strict than the JSON spec requires).<br>
<br>
A binary message format has none of those complicating issues. Which<br>
encoding format to pick is largely a matter of taste, but Protocol<br>
Buffers is a simple, robust, multi-programming-language,<br>
well-documented, easy-to-work-with, extensible format.<br>
<br>
What about a merchant-pays-fee feature?<br>
---------------------------------------<br>
<br>
It is desireable to allow a merchant to pay the cost of any Bitcoin<br>
network transaction processing fees, so if a customer is paying for a<br>
1 BTC item they pay exactly 1 BTC.<br>
<br>
One way of accomplishing that is to add a &#39;maxfee&#39; field to the<br>
Invoice, and have the Bitcoin client construct a transaction that pays<br>
the merchant (amount-maxfee).<br>
<br>
Another way of accomplishing that is to change the transaction<br>
selection code used by Bitcoin miners, so that dependent transactions<br>
are considered as a group. Then a merchant with several unconfirmed<br>
zero-fee transaction from customers can create a pay-to-self<br>
transaction with a large enough fee to pay for the set of transactions<br>
to be confirmed.<br>
<br>
A third way of accomplishing that is for the Bitcoin client to sign<br>
Payment.transactions[0] using the SIGHASH_ANYONECANPAY flag, and for<br>
the merchant to add an additional, small-BTC-value input to the<br>
transaction before broadcasting it. That additional input would go<br>
directly to miners as a fee. *Note: Gavin is not sure if he loves or<br>
hates this idea.*<br>
<br>
Checking for revoked certificates<br>
---------------------------------<br>
<br>
The Online Certificate Checking Protocol (OCSP) is supposed to be a<br>
quick and easy way for applications to check for revoked certificates.<br>
<br>
In practice, it doesn&#39;t work very well. Certificate Authorities have<br=
>
no financial incentive to support a robust infrastructure that can<br>
handle millions of OCSP validation requests quickly.<br>
<br>
Ideally, Bitcoin clients would use OCSP to check certificate statuses<br>
every time they received or re-used an Invoice. But if that results in<br>
long pauses or lots of false-positive rejections (because an OCSP<br>
endpoint is offline or overwhelmed, perhaps) then merchants and<br>
customers might revert to just using &quot;never fails&quot; Bitcoin addres=
ses.<br>
<br>
<br>
<br>
References<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Public-Key Infrastructure (X.509) working group :<br>
<a href=3D"http://datatracker.ietf.org/wg/pkix/charter/" target=3D"_blank">=
http://datatracker.ietf.org/wg/pkix/charter/</a><br>
<br>
RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate<br>
Status Protocol - OCSP : <a href=3D"http://tools.ietf.org/html/rfc2560" tar=
get=3D"_blank">http://tools.ietf.org/html/rfc2560</a><br>
<br>
Protocol Buffers : <a href=3D"https://developers.google.com/protocol-buffer=
s/" target=3D"_blank">https://developers.google.com/protocol-buffers/</a><b=
r>
<br>
See Also<br>
=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Javascript Object Signing and Encryption working group :<br>
<a href=3D"http://datatracker.ietf.org/wg/jose/" target=3D"_blank">http://d=
atatracker.ietf.org/wg/jose/</a><br>
<br>
sipa&#39;s payment protocol proposal: <a href=3D"https://gist.github.com/12=
37788" target=3D"_blank">https://gist.github.com/1237788</a><br>
<br>
ThomasV&#39;s &quot;Signed Aliases&quot; proposal : <a href=3D"http://ecdsa=
.org/bitcoin_URIs.html" target=3D"_blank">http://ecdsa.org/bitcoin_URIs.htm=
l</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
Monitor your physical, virtual and cloud infrastructure from a single<br>
web console. Get in-depth insight into apps, servers, databases, vmware,<br=
>
SAP, cloud infrastructure, etc. Download 30-day Free Trial.<br>
Pricing starts from $795 for 25 servers or applications!<br>
<a href=3D"http://p.sf.net/sfu/zoho_dev2dev_nov" target=3D"_blank">http://p=
.sf.net/sfu/zoho_dev2dev_nov</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>

--bcaec51b18e78e1c7904d17be779--