Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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.

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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?

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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

Re: [Bitcoin-development] [BIP 15] Aliases

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 identify hosts may be the more secure option, it's integration with the client seems more diffic

Re: [Bitcoin-development] [BIP 15] Aliases

Pieter, it was more rhetorical question than asking for explanation, but thanks anyway. As an Internet application developer, I of course understand security issues while using HTTPS and CA. I have a gut feeling that there simply does not exist any single solution which is both easy to use and sec

Re: [Bitcoin-development] [BIP 15] Aliases

On Sunday, December 18, 2011 8:14:20 PM Pieter Wuille wrote: > Furthermore, the embedded bitcoin address could be hidden from the user: > retrieved when first connecting, and stored together with the URI in > an address book. Like ssh, it could warn the user if the key changes > (which wil be ignor

Re: [Bitcoin-development] [BIP 15] Aliases

On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wrote: > Maybe I'm retarded, but where's the point in providing alliases containing > yet another hash in URL? Any DNS-based alias system is vulnerable to spoofing. If I can make people's DNS server believe that mining.cz points to my IP, I'll receiv

Re: [Bitcoin-development] [BIP 15] Aliases

On Sunday, December 18, 2011 6:58:37 PM slush wrote: > Maybe I'm retarded, but where's the point in providing alliases containing > yet another hash in URL? The point of the extended URI is to allow the server to negotiate payment details (payment/order information, fees, new privacy address, etc

Re: [Bitcoin-development] [BIP 15] Aliases

Maybe I'm retarded, but where's the point in providing alliases containing yet another hash in URL? slush On Sun, Dec 18, 2011 at 10:44 PM, Luke-Jr wrote: > On Sunday, December 18, 2011 4:05:11 PM Jorge Timón wrote: > > If we chose the simple URI proposal namecoin can still be integrated > > to

Re: [Bitcoin-development] [BIP 15] Aliases

On Sunday, December 18, 2011 4:05:11 PM Jorge Timón wrote: > If we chose the simple URI proposal namecoin can still be integrated > to map the IP of the server by those who want to. > Does it removes the necessity of the certificates? > If so, we should let people decide between HTTP, HTTPS, nameco

Re: [Bitcoin-development] [BIP 15] Aliases

I can't speak for Namecoin. As for the HTTPS requirement, I'm on the fence. Without it, the resolution is open to a man in the middle attack. Perhaps HTTPS should be required, and if HTTP is used, a large warning message is displayed. As for the answered message format, is JSON the assumed stru

Re: [Bitcoin-development] [BIP 15] Aliases

If we chose the simple URI proposal namecoin can still be integrated to map the IP of the server by those who want to. Does it removes the necessity of the certificates? If so, we should let people decide between HTTP, HTTPS, namecoin or whatever they trust. Shouldn't we be also discussing the val

Re: [Bitcoin-development] [BIP 15] Aliases

On Fri, Dec 16, 2011 at 1:52 PM, Khalahan wrote: > The number of proposals is not infinite, here are their problems : > > - FirstBits : centralized > - DNS TXT Records : DNSSEC is required to have a minimum of security, limits > usage to engineers, limits usage to some domain names (i won't be abl

Re: [Bitcoin-development] [BIP 15] Aliases

The number of proposals is not infinite, here are their problems : - FirstBits : centralized - DNS TXT Records : DNSSEC is required to have a minimum of security, limits usage to engineers, limits usage to some domain names (i won't be able to use a gmail addr

Re: [Bitcoin-development] [BIP 15] Aliases

On Fri, Dec 16, 2011 at 21:10, Amir Taaki wrote: > Especially when we already have bitcoin addresses with their own checksums- > what value do IBANs add? Well, I'm not an expert like you, but one benefit would be to be compatible with existing software solutions that are based on using IBANs. H

Re: [Bitcoin-development] [BIP 15] Aliases

IBANs add? Nothing except negatives. From: slush To: Khalahan Cc: bitcoin-development@lists.sourceforge.net Sent: Friday, December 16, 2011 7:54 PM Subject: Re: [Bitcoin-development] [BIP 15] Aliases Khalahan, honestly, using namecoin for aliases is (for me) clean exampl

Re: [Bitcoin-development] [BIP 15] Aliases

Khalahan, honestly, using namecoin for aliases is (for me) clean example of over-engineering. I mean - it will definitely work if implemented properly. I played with a namecoin a bit (as my pool was the first 'big' pool supporting merged mining), but I think there's really long way to provide such

Re: [Bitcoin-development] [BIP 15] Aliases

Namecoin is a peer-to-peer generic name/value datastore system. Don't forget it's not limited to .bit usage ! So, directly mapping things to .bit url would not be the optimal way of using namecoin. Namecoin is *specificaly designed to map things to names* in a fully decentralized way. So, it's the

Re: [Bitcoin-development] [BIP 15] Aliases

On 2011 December 16 Friday, Rick Wesson wrote: > I believe that any URI scheme will still leverage DNS and inherit any > base issues you would have with TXT records. I suggest looking at DANE HTTPS takes care of that. > and reviewing their work on hardening certificate (x.509) > infrastructure a

Re: [Bitcoin-development] [BIP 15] Aliases

On Fri, Dec 16, 2011 at 8:17 AM, Pieter Wuille wrote: > On Fri, Dec 16, 2011 at 08:03:28AM -0800, Rick Wesson wrote: >> Hardening the protocols and usability are related. Please look at some >> of the work done in the IETF which has a long history in addressing >> many of the issues you are consid

Re: [Bitcoin-development] [BIP 15] Aliases

On Fri, Dec 16, 2011 at 08:03:28AM -0800, Rick Wesson wrote: > Hardening the protocols and usability are related. Please look at some > of the work done in the IETF which has a long history in addressing > many of the issues you are considering. Review some of the elegance in > the bitcoin protocol

Re: [Bitcoin-development] [BIP 15] Aliases

On Fri, Dec 16, 2011 at 12:35 AM, Pieter Wuille wrote: > On Mon, Dec 12, 2011 at 02:21:09PM -0800, Amir Taaki wrote: >> I wrote this pre-draft: [snip] > > To conclude: my suggestion would be to use URLs as address identifiers, > optionally suffixed with a bitcoin address for authentication. > Th

Re: [Bitcoin-development] [BIP 15] Aliases

On Mon, Dec 12, 2011 at 02:21:09PM -0800, Amir Taaki wrote: > I wrote this pre-draft: > > > https://en.bitcoin.it/wiki/BIP_0015 > > It's merely a starter for discussions. Interesting discussion so far, with many nice ideas. I'll try to give my opinion and comment on some in batch here. First

Re: [Bitcoin-development] [BIP 15] Aliases

> Bitcoin itself is decentralised by design, in my opinion it seems obvious > that it needs to continue to maintain this feature. What's the real issue? - People want to use alternate representations ('aliases') of bitcoin addresses, for various reasons. - The blockchain is the only way to crea

Re: [Bitcoin-development] [BIP 15] Aliases

On Thu, 2011-12-15 at 13:59 -0600, theymos wrote: > Bitcoin already has code and a protocol for transactions to IP > addresses. Why not reuse that for dynamic address lookup? Just a few > changes are necessary to enable complete u...@server.com handling: I'm not against this, but I think its way ov

Re: [Bitcoin-development] [BIP 15] Aliases

This is the first proposal I've seen regarding mapping something like user@host that actually makes sense to me. Bitcoin itself is decentralised by design, in my opinion it seems obvious that it needs to continue to maintain this feature. On Fri, Dec 16, 2011 at 8:59 AM, theymos wrote: > Bitco

Re: [Bitcoin-development] [BIP 15] Aliases

, December 15, 2011 7:59 PM Subject: Re: [Bitcoin-development] [BIP 15] Aliases Bitcoin already has code and a protocol for transactions to IP addresses. Why not reuse that for dynamic address lookup? Just a few changes are necessary to enable complete u...@server.com handling: - Extend the

Re: [Bitcoin-development] [BIP 15] Aliases

Bitcoin already has code and a protocol for transactions to IP addresses. Why not reuse that for dynamic address lookup? Just a few changes are necessary to enable complete u...@server.com handling: - Extend the protocol so that "reply" messages can be signed by a fixed public key - Extend "check

Re: [Bitcoin-development] [BIP 15] Aliases

@Matt I didn't thought about firstbits scalability, but the "registering crap" and squatting arguments don't apply to green addresses because no one wants fancy or easy to memorize names there. Is just a way to make the bitcoin addresses shorter in the green addresses protocol to be able to have va

Re: [Bitcoin-development] [BIP 15] Aliases

I like the u...@server.com model. The protocol should be done entirely in DNS, though, not using HTTP connections to the server. Then the protocol can easily be used with Namecoin or other DNS replacements/enhancements later. Crypto to prevent MITM attacks can be an optional part of the protocol.

Re: [Bitcoin-development] [BIP 15] Aliases

>> Would it be too strange to use namecoin? > This has the same problem as FirstBits, except .bit domains are dirt cheap, > whereas vanitygen at least slows down grabbing all the common words... Grabbing is no more an issue than mining Bitcoins is an issue. Sure, domain grabbers will have the dom

Re: [Bitcoin-development] [BIP 15] Aliases

he HTTPS idea would be a great idea for a client feature, but > not really something that should be added to the protocol. > > --- On Mon, 12/12/11, Luke-Jr wrote: > > > From: Luke-Jr > > Subject: Re: [Bitcoin-development] [BIP 15] Aliases > > To: bitcoin-developme

Re: [Bitcoin-development] [BIP 15] Aliases

On Tue, 2011-12-13 at 00:37 +0100, Jorge Timón wrote: > I don't think Amir wants to put it into the protocol, but I still > don't like much the proposal if it has to rely on servers. > As an aside, even if firstbits it's not useful enough for the human > memory, it is still useful for QR-codes like

Re: [Bitcoin-development] [BIP 15] Aliases

On Monday, December 12, 2011 6:37:56 PM Jorge Timón wrote: > Would it be too strange to use namecoin? This has the same problem as FirstBits, except .bit domains are dirt cheap, whereas vanitygen at least slows down grabbing all the common words... ---

Re: [Bitcoin-development] [BIP 15] Aliases

On Mon, 12/12/11, Luke-Jr wrote: > >> From: Luke-Jr >> Subject: Re: [Bitcoin-development] [BIP 15] Aliases >> To: bitcoin-development@lists.sourceforge.net, "Amir Taaki" >> >> Date: Monday, December 12, 2011, 5:32 PM >> FirstBits looks nice at

Re: [Bitcoin-development] [BIP 15] Aliases

really something that should be added to the protocol. --- On Mon, 12/12/11, Luke-Jr wrote: > From: Luke-Jr > Subject: Re: [Bitcoin-development] [BIP 15] Aliases > To: bitcoin-development@lists.sourceforge.net, "Amir Taaki" > > Date: Monday, December 12, 2011, 5:32 PM

Re: [Bitcoin-development] [BIP 15] Aliases

FirstBits looks nice at glance, but is bound to create a gold-rush to grab every nice-looking FirstBits address. HTTPS is only as secure as the (centralized) CAs, thus not really any better than TXT records. I don't think an address of some form is avoidable. --

Re: [Bitcoin-development] [BIP 15] Aliases

OK, my thoughts. My order of preference is: web service, server service, DNS TXT records. FirstBits + Vanitygen is out of the question in my mind. Not robust enough. I like web service since anyone can trivially set one up. You can provide a PHP script and a text file (that users edit) that peo

[Bitcoin-development] [BIP 15] Aliases

I wrote this pre-draft: https://en.bitcoin.it/wiki/BIP_0015 It's merely a starter for discussions. Aliases are a way to lookup bitcoin addresses so I can type gen...@genjix.net instead of 1jkddsjdskjwnk2j3kj232kjdkj