public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Mike Koss <mike@coinlab.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Date: Sun, 16 Dec 2012 22:15:40 +0100	[thread overview]
Message-ID: <CAKaEYh+OUD4kfxwSNQBCJXmj6Kwb8jy9Au=Mfrqr2sKv7SuHpg@mail.gmail.com> (raw)
In-Reply-To: <CAErK2ChjAm-Zf11YXuBQeTQvahOEJNGiPSZaD-CQ=OU9K6HtZA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4633 bytes --]

On 3 December 2012 20:35, Mike Koss <mike@coinlab.com> 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 <gavinandresen@gmail.com>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 <http://coinlab.com/a-bitcoin-primer.pdf> - 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
>
>

[-- Attachment #2: Type: text/html, Size: 6470 bytes --]

  parent reply	other threads:[~2012-12-16 21:15 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-26 22:37 [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts Gavin Andresen
2012-11-26 23:02 ` Mike Hearn
2012-11-26 23:13   ` Luke-Jr
2012-11-26 23:16     ` Mike Hearn
2012-11-26 23:19       ` Luke-Jr
2012-11-26 23:27         ` Mike Hearn
2012-11-26 23:32         ` Gregory Maxwell
2012-11-26 23:44           ` Luke-Jr
2012-11-27  0:16             ` Gregory Maxwell
2012-11-27  0:26               ` Mike Hearn
2012-11-27  0:45                 ` Rick Wesson
2012-11-27  1:09                   ` Gavin
2012-11-27  8:44                   ` Mike Hearn
2012-11-27  0:44               ` Luke-Jr
2012-11-26 23:38 ` Rick Wesson
2012-11-26 23:52 ` Jeff Garzik
2012-11-27  0:02   ` Rick Wesson
2012-11-27  0:31     ` Luke-Jr
2012-11-27  0:37       ` Rick Wesson
2012-11-27  2:16 ` Walter Stanish
2012-11-27  2:47   ` Gregory Maxwell
2012-11-27  3:16     ` Walter Stanish
2012-11-27  3:29       ` Rick Wesson
2012-11-27  3:31         ` Walter Stanish
2012-11-27  3:54           ` Rick Wesson
2012-11-27  4:17             ` Walter Stanish
2012-11-27  8:43               ` Michael Gronager
2012-11-27 10:23                 ` Mike Hearn
2012-11-27 10:42                   ` Michael Gronager
2012-11-27 11:36                     ` Pieter Wuille
2012-11-27 11:46                       ` Michael Gronager
2012-11-27 12:03                     ` Mike Hearn
2012-11-27 12:39                       ` Michael Gronager
2012-11-27 14:05                         ` Gavin Andresen
2012-11-27 14:26                           ` Gavin Andresen
2012-11-28 13:55                           ` Walter Stanish
2012-11-27 17:03 ` Andy Parkins
2012-11-27 17:14   ` Mike Hearn
2012-11-27 17:26     ` Andy Parkins
2012-11-27 18:16       ` Mike Hearn
2012-11-27 21:39         ` Gavin Andresen
2012-11-28 10:43           ` Mike Hearn
2012-11-28 12:57             ` Peter Todd
2012-11-28 14:09               ` Gavin Andresen
2012-11-28  8:33 ` Peter Todd
2012-11-28 23:36 ` Roy Badami
2012-11-29  0:30   ` Watson Ladd
2012-11-29  8:16     ` slush
2012-11-29 16:11   ` Gavin Andresen
2012-11-29 17:07     ` Roy Badami
2012-11-29 17:30       ` Gavin Andresen
2012-11-29 17:31       ` Mike Hearn
2012-11-29 18:53         ` Roy Badami
2012-12-01 19:25           ` Gavin Andresen
2012-12-03 19:35             ` Mike Koss
2012-12-03 20:59               ` Gavin Andresen
2012-12-03 21:28               ` Mike Hearn
2012-12-03 22:26                 ` Roy Badami
2012-12-03 22:34                   ` Jeff Garzik
2012-12-03 22:48                     ` Roy Badami
2012-12-16 21:15               ` Melvin Carvalho [this message]
2012-12-17  2:18                 ` Jeff Garzik
2012-12-17  8:24                   ` Melvin Carvalho
2012-12-17  9:19                     ` Mike Hearn
2012-12-17  9:31                       ` Gary Rowe
2012-12-17 11:23                       ` Melvin Carvalho
2012-12-17 17:57                         ` Gavin Andresen
2012-12-20 16:53                           ` Stephen Pair
2012-12-20 17:43                             ` Mike Hearn
2012-12-20 19:32                               ` Stephen Pair
2012-12-21 17:05                                 ` Stephen Pair
2012-12-24  0:38                                   ` Elden Tyrell
2012-12-04 17:06             ` Mike Hearn
2012-12-05 19:34               ` Gavin Andresen
2012-12-06  6:31                 ` Andreas Petersson
2012-12-06  8:53                   ` Mike Hearn
2012-12-06 16:56                     ` Gavin Andresen
2012-12-06 17:55                       ` Mike Hearn
2012-12-06 19:13                         ` Gavin Andresen
2012-12-07 10:45                           ` Mike Hearn
2012-12-07 11:01                             ` Mike Hearn
2012-12-07 16:19                               ` Gavin Andresen
2012-12-07 16:27                                 ` Mike Hearn
2012-12-06 18:13                       ` Alan Reiner
     [not found]                       ` <CALf2ePx5jS@mail.gmail.com>
2014-09-17 19:28                         ` Vezalke
2012-12-03 21:42         ` Gregory Maxwell
2012-12-23  2:33 ` Mark Friedenbach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKaEYh+OUD4kfxwSNQBCJXmj6Kwb8jy9Au=Mfrqr2sKv7SuHpg@mail.gmail.com' \
    --to=melvincarvalho@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@coinlab.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox