Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TkLYp-00024i-BL for bitcoin-development@lists.sourceforge.net; Sun, 16 Dec 2012 21:15:47 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.175 as permitted sender) client-ip=209.85.223.175; envelope-from=melvincarvalho@gmail.com; helo=mail-ie0-f175.google.com; Received: from mail-ie0-f175.google.com ([209.85.223.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TkLYo-0000Uu-5H for bitcoin-development@lists.sourceforge.net; Sun, 16 Dec 2012 21:15:47 +0000 Received: by mail-ie0-f175.google.com with SMTP id qd14so7922471ieb.34 for ; Sun, 16 Dec 2012 13:15:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.91.168 with SMTP id cf8mr7346089igb.20.1355692540834; Sun, 16 Dec 2012 13:15:40 -0800 (PST) Received: by 10.42.61.203 with HTTP; Sun, 16 Dec 2012 13:15:40 -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: Sun, 16 Dec 2012 22:15:40 +0100 Message-ID: From: Melvin Carvalho To: Mike Koss Content-Type: multipart/alternative; boundary=e89a8f3b9d3d52318c04d0fec438 X-Spam-Score: -0.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 (melvincarvalho[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1TkLYo-0000Uu-5H 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: Sun, 16 Dec 2012 21:15:47 -0000 --e89a8f3b9d3d52318c04d0fec438 Content-Type: text/plain; charset=ISO-8859-1 On 3 December 2012 20:35, Mike Koss wrote: > The thing that bugged me most about the original spec was the sole > reliance on X.509 - glad to see you've made that optional. I think many > people will balk at deferring our identity trust to the existing CA's. I > think it's a fine bootstrap method, but I'd really like to see another > option that allows for out-of-band trust (based on ECDSA, probably). > > It would also be really nice to migrate to textual representations of data > structures as opposed to binary ones. The most successful internet > standards are based on text, making them that much more accessible for > developers to deal with them. JSON would be my preferred candidate. > > Why don't we sign the text representation of a (utf8) JSON, rather than > some complex encoding standard of JSON? That way the signatures are simple > - and you need only retain the original textual representation of a message > to validate the signature (as well as the decoded version, if you don't > want to alway re-parse the message when writing programs that use it). > Binary formats can be challenging to deal with and convert to other formats. The experiences in the PKI world of ASN.1 have not been great, in terms of interop. It tends to create islands and silos. This is probably one of the reasons why X.509 and GPG are fragmented and why we dont really have a widely deployed web of trust on the net. Another reason is simply lack of developer resources to make tools. In that respect I think JSON offers significant advantages, though I am interested in the security issues raised. > > On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andresen wrote: > >> 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 >> >> >> ------------------------------------------------------------------------------ >> Keep yourself connected to Go Parallel: >> INSIGHTS What's next for parallel hardware, programming and related areas? >> Interviews and blogs by thought leaders keep you ahead of the curve. >> http://goparallel.sourceforge.net >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > > -- > Mike Koss > CTO, CoinLab > (425) 246-7701 (m) > > A Bitcoin Primer - What you > need to know about Bitcoins. > > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > BUILD Helping you discover the best ways to construct your parallel > projects. > http://goparallel.sourceforge.net > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --e89a8f3b9d3d52318c04d0fec438 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 3 December 2012 20:35, Mike Koss <mik= e@coinlab.com> wrote:
The thing that bugged me most about the original spec was the sole reliance= on X.509 -=A0glad=A0to see you've made that optional. =A0I think many = people will balk at deferring our identity trust to the existing CA's. = =A0I think it's a fine bootstrap method, but I'd really like to see= another option that allows for out-of-band trust (based on ECDSA, probably= ).

It would also be really nice to migrate to textual represent= ations of data structures as opposed to binary ones. =A0The most successful= internet standards are based on text, making them that much more accessibl= e for developers to deal with them. =A0 JSON would be my preferred candidat= e.

Why don't we sign the text representation of a (utf= 8) JSON, rather than some complex encoding standard of JSON? =A0That way th= e signatures are simple - and you need only retain the original textual rep= resentation of a message to validate the signature (as well as the decoded = version, if you don't want to alway re-parse the message when writing p= rograms that use it).

Binary formats can be challenging to deal with and co= nvert to other formats.=A0 The experiences in the PKI world of ASN.1 have n= ot been great, in terms of interop.=A0 It tends to create islands and silos= .=A0 This is probably one of the reasons why X.509 and GPG are fragmented a= nd why we dont really have a widely deployed web of trust on the net.=A0 An= other reason is simply lack of developer resources to make tools.=A0 In tha= t respect I think JSON offers significant advantages, though I am intereste= d in the security issues raised.
=A0

On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andre= sen <gavinandresen@gmail.com> wrote:
Spec updated: https://gist.github.com/4120476

Changes are:

Version numbers: =A0a 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:
=A0 =A0Content-Type: application/x-bitcoin-invoice; version=3D1
The version=3D syntax is part of the MIME standard.

Following that best-practice of knowing what you're parsing before you<= br> parse it, I added an invoice_version field to the SignedInvoice
message. It is now:

message SignedInvoice {
=A0 =A0 required bytes pki_data =3D 1;
=A0 =A0 required string pki_type =3D 2 [default =3D "x509"];
=A0 =A0 required bytes serialized_invoice =3D 3;
=A0 =A0 required uint32 invoice_version =3D 4 [default =3D 1];
=A0 =A0 required bytes signature =3D 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=3Dfalse but broadcasts the transactions
anyway."


I also added a TODO "Test Vectors" section with base64-encoded examples of everything.

--
--
Gavin Andresen
=

---------------------------------------------------------------------------= ---
Keep yourself connected to Go Parallel:
INSIGHTS What's next for parallel hardware, programming and = related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.



--
Mike Koss
= CTO, CoinLab

A Bitcoin Primer=A0- What you need to know about Bitcoin= s.


---------------------------------------------------------= ---------------------
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel project= s.
http://gopa= rallel.sourceforge.net
_____________________________________________= __
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--e89a8f3b9d3d52318c04d0fec438--