From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Tesgm-0002uj-Mm for bitcoin-development@lists.sourceforge.net; Sat, 01 Dec 2012 19:25:24 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.43 as permitted sender) client-ip=74.125.82.43; envelope-from=gavinandresen@gmail.com; helo=mail-wg0-f43.google.com; Received: from mail-wg0-f43.google.com ([74.125.82.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Tesgl-0000FV-SU for bitcoin-development@lists.sourceforge.net; Sat, 01 Dec 2012 19:25:24 +0000 Received: by mail-wg0-f43.google.com with SMTP id e12so657326wge.10 for ; Sat, 01 Dec 2012 11:25:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.82.10 with SMTP id n10mr1718560wee.126.1354389917742; Sat, 01 Dec 2012 11:25:17 -0800 (PST) Received: by 10.194.27.136 with HTTP; Sat, 1 Dec 2012 11:25:17 -0800 (PST) In-Reply-To: <20121129185330.GE6368@giles.gnomon.org.uk> References: <20121128233619.GA6368@giles.gnomon.org.uk> <20121129170713.GD6368@giles.gnomon.org.uk> <20121129185330.GE6368@giles.gnomon.org.uk> Date: Sat, 1 Dec 2012 14:25:17 -0500 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Tesgl-0000FV-SU 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 19:25:24 -0000 Spec updated: https://gist.github.com/4120476 Changes are: Version numbers: a couple of people asked privately about adding version numbers to the messages. In general, Protocol Buffers don't need version numbers if later versions add only optional fields. And best-practice is to know what version of something you're expecting BEFORE you start parsing that something. So, if a bitcoin client is getting Invoice messages via email or from a web server, the version will be specified as part of the MIME type; for example: Content-Type: application/x-bitcoin-invoice; version=1 The version= syntax is part of the MIME standard. Following that best-practice of knowing what you're parsing before you parse it, I added an invoice_version field to the SignedInvoice message. It is now: message SignedInvoice { required bytes pki_data = 1; required string pki_type = 2 [default = "x509"]; required bytes serialized_invoice = 3; required uint32 invoice_version = 4 [default = 1]; required bytes signature = 5; } Handling of receiptURI errors: Following discussion here, I changed the spec to say: "Clients may handle errors communicating with the receiptURI server however they like, but should assume that if they cannot communicate at all with the server then the Payment should either be retried later or immediately rejected." and under Receipt added: "The Bitcoin client must be prepared to handle the case of an evil merchant that returns accepted=false but broadcasts the transactions anyway." I also added a TODO "Test Vectors" section with base64-encoded examples of everything. -- -- Gavin Andresen