Date: Fri, 16 Dec 2011 09:35:38 +0100
From: Pieter Wuille <pieter.wuille@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20111216083536.GA20470@ulyssis.org>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Precedence: list

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 of all, I'm a big proponent of moving away from using base58 strings
as addresses. They are not flexible and not human-friendly. I did an own
proposal to improve the situation some time ago, see

  https://gist.github.com/1237788

There was little reaction, and maybe the reason is we shouldn't try to solve/fix
everything at once.

a) IP transactions-like system with DNS resolution

Not only does this give you nice identifiers, but it also moves the
responsibility of getting the transaction accepted by the network from the
sender to the receiver - the one who actually cares about getting his
money.

The authentication problem that was present in the original IP transactions
system can either be mitigated by trusting the existing SSL public-key
intrastructure (which not everyone may like) or (as Satoshi suggested) adding
bitcoin address-based authentication on top (separate from the address used in
the transaction itself). So you get an identifier like <url>$<btcaddress>, and
the communication to <url> would be authenticated using <btcaddress>. This
is obviously not useful as human-typable alias, but is no problem for
clickable URLs on websites that want to provide the additional security.

I'm not sure about using the bitcoin p2p protocol here - i think there are
easier (or at least more widely deployed) protocols like HTTP. So maybe ...

b) HTTPS Web Service

we can just use an HTTPS web service, that provides the bitcoin address to
be used in the transaction to a client that queries a URL. This immediately
makes the identifier double as a clickable URL, and a merchant could add
metadata to the URL to make the transaction easily trackable.

As for the possibility for spoofing: relying on DNSSEC is currently
difficult i believe (though i'm not entirely up-to-date about its
deployment). Again, alternatives are the SSL PKI, or bitcoin address-based
authentication (basically doing SSL but using bitcoin pubkeys to
authenticate)

c) user@hostname-like identifiers

These look very good, and conveniently match the e-mail system's identifiers.
However, I believe they are only useful for one purpose: user-to-user
payments. For anything somewhat more business-y you probably want to use
a clickable URL, and hide all address information entirely from the user.
Still, for user-to-user payments they are nice.

I'm not convinced about the hardcoding of the "https://" and
"/bitcoin-alias/?handle=" parts, though. These seem very arbitrarily
chosen to me, but if you consider an HTTPS-based variant of a bitcoin
ip-transactions-like system, the proposed "account" parameter to
checkorder would probably become a CGI parameter anyway...

d) DNS TXT lookups

I'm not entirely against this, but only allowing a fixed bitcoin address
to be returned would far too strongly encourage the use of fixed
addresses in transactions. If anything, it should be an identifier
for one of the other proposals (which do allow interaction, or at least
creation of a fresh bitcoin address) that is returned. 


To conclude: my suggestion would be to use URLs as address identifiers,
optionally suffixed with a bitcoin address for authentication.
This means my "address" would be either "sipa.be/pw.btc" or
"sipa.be/pw.btc$14TYdpodQQDKVgvUUcpaMzjJwhQ4KYsipa" (where "https://")
is an implicit default. Initiating a payment to either of these would
result in a GET of https://sipa.be/pw.btc. When a transaction is
constructed, it is POSTed back to that URL.

If we can agree on reasonable hardcoded mapping, pw@sipa.be could just
be a shorthand for either of these (though vulnerable to proofing...).

-- 
Pieter