From: Pieter Wuille <pieter.wuille@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Date: Fri, 16 Dec 2011 09:35:38 +0100 [thread overview]
Message-ID: <20111216083536.GA20470@ulyssis.org> (raw)
In-Reply-To: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
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
next prev parent reply other threads:[~2011-12-16 8:35 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 22:21 Amir Taaki
2011-12-12 22:25 ` Amir Taaki
2011-12-12 22:32 ` Luke-Jr
2011-12-13 4:38 ` theymos
2011-12-13 7:41 ` Jorge Timón
2011-12-15 19:59 ` theymos
2011-12-15 23:56 ` Amir Taaki
2011-12-16 2:37 ` Kyle Henderson
2011-12-16 4:32 ` Walter Stanish
2011-12-16 2:48 ` Matt Corallo
2011-12-16 17:23 ` Khalahan
2011-12-16 19:54 ` slush
2011-12-16 20:10 ` Amir Taaki
2011-12-16 20:14 ` Harald Schilly
2011-12-16 21:52 ` Khalahan
2011-12-16 22:05 ` Rick Wesson
2011-12-18 21:05 ` Jorge Timón
2011-12-18 21:18 ` Jordan Mack
2011-12-18 21:44 ` Luke-Jr
2011-12-18 23:58 ` slush
2011-12-19 1:13 ` Luke-Jr
2011-12-19 1:14 ` Pieter Wuille
2011-12-19 1:43 ` Luke-Jr
2011-12-19 1:44 ` slush
2011-12-19 7:56 ` Jorge Timón
2011-12-19 11:44 ` Andy Parkins
2011-12-19 14:46 ` solar
2011-12-19 15:35 ` Rick Wesson
2011-12-19 16:35 ` Luke-Jr
2011-12-19 17:13 ` solar
2011-12-19 16:30 ` Luke-Jr
2011-12-19 17:04 ` Jordan Mack
2011-12-19 17:09 ` slush
2011-12-19 18:13 ` Jordan Mack
2011-12-19 18:17 ` slush
2011-12-19 18:50 ` Jorge Timón
2011-12-19 20:03 ` Jordan Mack
2011-12-19 19:22 ` Jordan Mack
2011-12-19 18:15 ` Luke-Jr
2011-12-19 18:52 ` Jordan Mack
2011-12-19 19:16 ` Luke-Jr
2011-12-19 20:03 ` Jordan Mack
2011-12-16 8:35 ` Pieter Wuille [this message]
2011-12-16 16:03 ` Rick Wesson
2011-12-16 16:17 ` Pieter Wuille
2011-12-16 16:21 ` Rick Wesson
2011-12-16 17:21 ` Andy Parkins
2011-12-12 23:16 Zell Faze
2011-12-12 23:37 ` Jorge Timón
2011-12-12 23:41 ` Luke-Jr
2011-12-13 2:39 ` Stefan Thomas
2011-12-12 23:52 ` Matt Corallo
2011-12-12 23:37 ` Will
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111216083536.GA20470@ulyssis.org \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox