From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Mon, 19 Dec 2011 14:16:54 -0500
User-Agent: KMail/1.13.7 (Linux/3.1.4-gentoo; KDE/4.7.3; x86_64; ; )
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
	<201112191315.25857.luke@dashjr.org>
	<4EEF8806.6070707@parhelic.com>
In-Reply-To: <4EEF8806.6070707@parhelic.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201112191416.56029.luke@dashjr.org>
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Precedence: list

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 system. Not all payment outputs are necessarily 
serializable into addresses, and assuming they are would be broken-by-design.
In other words, why send the user's *software* "pay to address foo" just to 
have it turn that into a script (of limited subset), when you can send the 
script itself and avoid all the possible problems? Doing this right also means 
that if the user's client doesn't support version 255 addresses, it still 
works fine.

> I'm not going to pretend that I know all the details of the difficulties
> that were encountered with JSON-RPC. But in the argument of developer
> accessibility, it still serves a purpose. If JSON-RPC support is
> removed, you will immediately lose a large pool of high level language
> developers.

JSON isn't problem-free at high-level either. To summarize one of the issues, 
almost every implementation of JSON treats Numbers differently based on 
whether they have a '.' in them or not.

MIME has been around much longer, and should have sufficient support in every 
language by now. For some reason, Python calls the module 'email'.