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 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 > 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 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 > >