On Monday, December 19, 2011 5:29:34 PM Gregory Maxwell wrote:
> I've been arguing with Luke-JR on IRC about the interpenetration of
> BIP_0014— Gavin's recent commit uses the same version string for the
> GUI interface and the daemon mode.
>
> Luke believes this is a _violation_ of BIP_0014 and
I've been arguing with Luke-JR on IRC about the interpenetration of
BIP_0014— Gavin's recent commit uses the same version string for the
GUI interface and the daemon mode.
Luke believes this is a _violation_ of BIP_0014 and an error in
judgement on Gavin's part, and a failure to conform to the co
On 12/18/2011 1:19 PM, Stefan Thomas wrote:
> Let those who want anonymity connect through Tor, Freenet, etc. It's
> easy to add anonymity via an extra layer, but it is impossible to add
> performance on top of a slow system.
That's a very good point. This is needless complication at the protoc
I don't think protocol buffers are as simple to implement as some would
like. I would still opt for it over MIME though.
On 12/19/2011 10:50 AM, Jorge Timón wrote:
> I don't have a strong position for or against JSON but...What about
> protocol buffers?
> Would it be too much too? Would it be si
I wish that was the case. It would have made my life a lot easier in the
past. A lot of the MIME libraries out there are extremely buggy. MIME is
just difficult to work with, and support is still weak.
Undefined content length + text based boundaries = pain in the ass.
It is in the e-mail modul
If alias resolution was guaranteed to always be just the address, then
yes, I would opt for no serialization at all. A simple plain text
response of an address is about as simple as it can get.
There are already a lot of good ideas floating around about how the
alias protocol could be extended.
On Monday, December 19, 2011 1:52:54 PM Jordan Mack wrote:
> I believe I'm missing something here. I was under the interpretation
> that alias resolution was going the KISS route, of basically a single
> HTTP request and response. How do you see binary data fitting into this?
Bitcoin is a binary s
I believe I'm missing something here. I was under the interpretation
that alias resolution was going the KISS route, of basically a single
HTTP request and response. How do you see binary data fitting into this?
I'm not going to pretend that I know all the details of the difficulties
that were
I don't have a strong position for or against JSON but...What about
protocol buffers?
Would it be too much too? Would it be simple enough for developers?
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is hol
In my opinion, there's not necessary any payload format (json, xml,
multipart). In keeping stuff KISS, everything we need is just an address in
response + potentially some stuff like HTTP redirects (for providing
additional compatibility for proposal of bitcoin URIs with "amount",
"label" and other
On Monday, December 19, 2011 12:04:34 PM Jordan Mack wrote:
> I still think HTTPS should be used, at the minimum. Using HTTPS is
> standard to every website out there that deals with financials, even if
> it is not a perfect system. Why should Bitcoin adopt a more lax policy
> than everyone else?
With all due respect, I continue to disagree on the topic of using HTTP
for data interchange.
Yes, an HTTP multipart response will accomplish the need for multiple
named resources. The problem is that parsing of a multipart response
isn't simple, and library support is weak across many language
I still think HTTPS should be used, at the minimum. Using HTTPS is
standard to every website out there that deals with financials, even if
it is not a perfect system. Why should Bitcoin adopt a more lax policy
than everyone else?
I thought that JSON support was fairly common these days. I perso
Using commercial CAs to establish trust is a site local administrative policy..
Bitcoin and operating systems have no technical need to concern themselves with
this. It is a shame that the system has been abused by CAs paying off
operating system and web browser vendors but this is not the only
I agree with Luke that HTTP standard has everything necessary and bloating
payload with json/xml is not necessary.
Btw that argument "we have json in client already" seems pretty wrong,
because json in server rpc solves another problem (and solve it in wrong
way, because of data type issues, but i
On Monday, December 19, 2011 6:44:59 AM Andy Parkins wrote:
> Perhaps we should be more strict about which CA certificates are trusted by
> the bitcoin client: say restrict it to those who have demonstrably good
> practices for verifying identity; rather than the ridiculous amount of
> trust that c
On Monday, December 19, 2011 2:56:09 AM Jorge Timón wrote:
> For the "answer format" JSON seems ok,
I'd prefer we stick to simple standards.
HTTP alone should really be fine to build on...
JSON in particular has very poor language support, and cannot reasonably
represent binary data (such as a c
You are describing the problem DANE addresses, see
http://tools.ietf.org/html/draft-ietf-dane-protocol-12
Using Secure DNS to Associate Certificates with Domain Names For TLS
Abstract
TLS and DTLS use PKIX certificates for authenticating the server.
Users want their applications to verify
I think HTTPS, and more specifically x.509 PKI certs and CAs are generally a
good idea and (historical implementation bugs aside) the concept is technically
sound and secure. What is a bad idea (in my opinion) is to trust a software
vendor to decide who you should trust.. thus it is a bad idea
On 2011 December 19 Monday, Jorge Timón wrote:
> Ok, so HTTP is not an option unless it shows a huge warning. I don't
> know the HTTPS possible attack, but maybe it needs a warning message
> too, from what you people are saying. Although using namecoin to
The problems with HTTPS have been social r
20 matches
Mail list logo
