From: Angel Leon <gubatron@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Nicolas Dorier <nicolas.dorier@gmail•com>,
Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Date: Wed, 28 Jan 2015 12:17:54 -0500 [thread overview]
Message-ID: <CADZB0_a84VDU1iz8H_6AifsvZ5k68H10c1NV8irWuaz2v46EeQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3ta59A0Fr9-afd1ByQ7U0G7kQVu_EsK-8AZkud74Kxpw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6659 bytes --]
why not allow both serializations and keep serialization format a
parameter, keep everyone happy.
http://twitter.com/gubatron
On Wed, Jan 28, 2015 at 12:14 PM, Mike Hearn <mike@plan99•net> wrote:
> I think we'll just have to agree to disagree on this one. I've implemented
> BIP70 a couple of times now and didn't find it to be difficult. I know you
> had odd problems with the C# protobuf implementation you were using but
> library bugs can happen for any kind of programming.
>
> I forgot to mention the other reason it's done this way. One of the
> driving goals of BIP70 was to support the TREZOR and similar devices. For
> hardware wallets, it's critical to keep the amount of code they need to run
> as small as possible. Any bugs in the code there can cause security holes
> and lead to the device being hacked.
>
> Doing it the way you suggest would mean the secure code would have to
> contain complex and bug-prone text parsing logic as well as a full blown
> HTTP and SSL stack, that requires not only X.509 handling but also lots of
> other stuff on top. It'd increase cost, complexity and decrease security
> quite a bit.
>
> Whilst I appreciate if your platform provides a scripting-like API and
> nothing low level it might seem easier to use JSON+HTTPS, that isn't the
> case for one of the primary design targets.
>
>
>
> On Wed, Jan 28, 2015 at 6:04 PM, Nicolas Dorier <nicolas.dorier@gmail•com>
> wrote:
>
>> Mike, I am not denying it is impossible to do all of that.
>> Just that it is not a trivial stuff to do to make it works everywhere,
>> and I think that it is not a good thing for a client side technology.
>> BIP70 has its use, and I understand why there is case where it is good to
>> ship the certs in the message and not depends on the transport.
>>
>> But a standard that just use JSON and HTTPS, even if less flexible that
>> BIP70, would make it easier and sufficient for today's use case.
>>
>> On Wed, Jan 28, 2015 at 5:55 PM, Mike Hearn <mike@plan99•net> wrote:
>>
>>> My point is not that there is a limitation in BIP70. My point is that
>>>> you put the burden of certificate verification on developer's shoulder when
>>>> we can just leverage built in HTTPS support of the platform.
>>>>
>>>
>>> Platforms that support HTTPS but not certificate handling are rare - I
>>> know HTML5 is such a platform but such apps are inherently dependent on the
>>> server anyway and the server can just do the parsing and validation work
>>> itself. If WinRT is such a platform, OK, too bad.
>>>
>>> The embedding of the certificates is not arbitrary or pointless, by the
>>> way. It's there for a very good reason - it makes the signed payment
>>> request verifiable by third parties. Effectively you can store the signed
>>> message and present it later to someone else, it's undeniable. Combined
>>> with the transactions and merkle branches linking them to the block chain,
>>> what you have is a form of digital receipt ... a proof of purchase that can
>>> be automatically verified as legitimate. This has all kinds of use cases.
>>>
>>> Because of how HTTPS works, you can't easily prove to a third party that
>>> a server gave you a piece of data. Doing so requires staggeringly complex
>>> hacks (see tls notary) and when we designed BIP70, those hacks didn't even
>>> exist. So we'd lose the benefit of having a digitally signed request.
>>>
>>> Additionally, doing things this way means BIP70 requests can be signed
>>> by things which are not HTTPS servers. For example you can sign with an
>>> email address cert, an EV certificate i.e. a company, a certificate issued
>>> by some user forum, whatever else we end up wanting. Not every payment
>>> recipient can be identified by a domain name + dynamic session.
>>>
>>>
>>>> However, if you want to use your plateform's store, then you are toasted
>>>>
>>>
>>> That's a bit melodramatic. BitcoinJ is able to use the Android, JRE,
>>> Windows and Mac certificate stores all using the same code or very minor
>>> variants on it (e.g. on Mac you have to specify you want the system store
>>> but it's a one-liner).
>>>
>>> Yes, that's not *every* platform. Some will require custom binding glue
>>> and it depends what abstractions and languages you are using.
>>>
>>>
>>>> Have you tried to do that on windows RT and IOS ? I tried, and I
>>>> quickly stopped doing that since it is not worth the effort. (Frankly I am
>>>> not even sure you can on win rt, since the API is a stripped down version
>>>> of windows)
>>>>
>>>
>>> There is code to do iOS using the Apple APIs here:
>>>
>>>
>>> https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRPaymentProtocol.m#L391
>>>
>>>
>>>> Why have you not heard about the problem ? (until now, because I have
>>>> this problem because I need to have the same codebase on
>>>> winrt/win/android/ios/tablets)
>>>>
>>>
>>> WinRT is a minority platform in the extreme, and all the other platforms
>>> you mentioned have the necessary APIs. Java abstracts you from them. So I
>>> think you are encountering this problem because you desire to target WinRT
>>> and other platforms with a single codebase. That's an unusual constraint.
>>>
>>> AFAIK the only other people who encountered this are BitPay, because
>>> they want to do everything in Javascript which doesn't really provide any
>>> major APIs.
>>>
>>>
>>>> Also, you bundle mozilla's store in bitcoinj, what happen when the
>>>> store change and your customer have not intent to use bitcoinj new version
>>>> ? by leveraging the plateform you benefit from automatic updates.
>>>>
>>>
>>> Yes, there are pros and cons to bundling a custom root store.
>>>
>>>
>>>> Also, does java stores deals with certificate revocations ? sure you
>>>> can theorically code that too... or just let the plateform deals with it.
>>>>
>>>
>>> It can do OCSP checks, yes, although I believe no wallets currently do
>>> so. A better solution would be to implement an OCSP stapling extension to
>>> BIP70 though.
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. 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: 9858 bytes --]
next prev parent reply other threads:[~2015-01-28 17:18 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 12:45 Nicolas DORIER
2015-01-28 13:32 ` Wladimir
2015-01-28 14:00 ` Nicolas DORIER
2015-01-28 15:42 ` Mike Hearn
2015-01-28 16:04 ` Jeff Garzik
2015-01-28 16:52 ` Nicolas DORIER
2015-01-28 17:29 ` Jeff Garzik
2015-01-28 17:45 ` Mike Hearn
2015-01-28 16:19 ` Giuseppe Mazzotta
2015-01-28 16:51 ` Matt Whitlock
2015-01-28 17:02 ` Mike Hearn
2015-01-28 16:34 ` Nicolas DORIER
2015-01-28 16:55 ` Mike Hearn
2015-01-28 17:04 ` Nicolas Dorier
2015-01-28 17:14 ` Mike Hearn
2015-01-28 17:17 ` Angel Leon [this message]
2015-01-28 17:27 ` Nicolas DORIER
-- strict thread matches above, loose matches on Subject: below --
2015-01-19 19:07 Richard Brady
2015-01-19 19:09 ` Jeff Garzik
2015-01-19 19:16 ` Richard Brady
2015-01-19 19:34 ` Jeff Garzik
2015-01-19 19:48 ` Peter Todd
2015-01-19 19:57 ` Richard Brady
2015-01-19 20:03 ` Alan Reiner
2015-01-19 20:06 ` Peter Todd
2015-01-19 20:40 ` Mike Hearn
2015-01-19 20:56 ` Gavin Andresen
2015-01-19 21:22 ` Brian Hoffman
2015-01-19 20:59 ` Ross Nicoll
2015-01-24 13:19 ` Isidor Zeuner
2015-01-25 22:59 ` Ross Nicoll
2015-03-14 15:58 ` Isidor Zeuner
2015-03-24 12:08 ` Jorge Timón
2015-01-19 21:21 ` Jeff Garzik
2015-01-19 19:19 ` Matt Whitlock
2015-01-19 19:37 ` Mike Hearn
2015-01-19 19:38 ` Jeff Garzik
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=CADZB0_a84VDU1iz8H_6AifsvZ5k68H10c1NV8irWuaz2v46EeQ@mail.gmail.com \
--to=gubatron@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
--cc=nicolas.dorier@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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