Mike Koss [ARCHIVE] on Nostr: 📅 Original date posted:2012-12-03 📝 Original message:The thing that bugged me ...

📅 Original date posted:2012-12-03
📝 Original message: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).

On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andresen <gavinandresen at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121203/62146299/attachment.html>;