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 1Tfvwj-0006xK-Nm for bitcoin-development@lists.sourceforge.net; Tue, 04 Dec 2012 17:06:13 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.175 as permitted sender) client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f175.google.com; Received: from mail-ob0-f175.google.com ([209.85.214.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Tfvwh-0002PM-L1 for bitcoin-development@lists.sourceforge.net; Tue, 04 Dec 2012 17:06:13 +0000 Received: by mail-ob0-f175.google.com with SMTP id vb8so4190901obc.34 for ; Tue, 04 Dec 2012 09:06:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.30.42 with SMTP id p10mr6788886oeh.59.1354640766241; Tue, 04 Dec 2012 09:06:06 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.128.139 with HTTP; Tue, 4 Dec 2012 09:06:05 -0800 (PST) In-Reply-To: References: <20121128233619.GA6368@giles.gnomon.org.uk> <20121129170713.GD6368@giles.gnomon.org.uk> <20121129185330.GE6368@giles.gnomon.org.uk> Date: Tue, 4 Dec 2012 18:06:05 +0100 X-Google-Sender-Auth: 164HuDJCvmwkrX2rI55gbBEEyW8 Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.5 (-) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1Tfvwh-0002PM-L1 Cc: Bitcoin Dev 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: Tue, 04 Dec 2012 17:06:13 -0000 > 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. I think that's OK. However, you should only be getting the version you expect because when you request an invoice, your client should be telling the merchant what protocol version you implement. Does it make sense to have this spec not include the details of bootstrapping? It's not complicated - we extend the URI spec in a backwards compatible way: bitcoin:1AbCdEfG?value=10.0&label=Pay%20for%20Foo&invoice=https://merchant.com/inv/aB425az When a compatible client sees the invoice param, it ignores the rest of the URI and downloads the URL https://merchant.com/inv/aB425az?ver=1.0 A server on merchant.com sees that the client expects a version 1.0 invoice and vends it. If ver=2.0 or whatever, it knows it can use 2.0 features. If extensions are supported, add new query params. We should define a simple mechanism for extending the protocol now, so people who want to make proprietary extensions don't conflict. The simplest is to just say, if you want to add new fields to an Invoice message, please update a wiki page with the tag numbers you're going to use, and start from number X. Protobufs have a simple way to formalize this in the language: https://developers.google.com/protocol-buffers/docs/proto#extensions message Invoice { extensions 1000 to max; } The point of this is to allow you to define new parts of the messages in separate .proto files. It's only a minor convenience but it means if you want to use, say, two extensions that weren't yet folded into the main spec, you can more easily do so without having to do a manual merge of the message definitions together. For instance, if you wanted to extend the protocol to support specification of recurring billing, you could make a file called recurring-invoices.proto containing: message Recurrences { required uint32 every_seconds = 1; optional uint32 start_time = 2; } extend Invoice { optional Recurrences recurrences = 1005; } then you update the wiki page to claim tag number 1005 and apps can easily use your new features. If/when the feature gets standardized via a BIP, the core .proto definition can be extended to include these messages and the extensions can go away.