[Bitcoin-development] [BIP 15] Aliases

[Bitcoin-development] [BIP 15] Aliases

[Amir Taaki]

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 genjix@genjix.net instead of 1jkddsjdskjwnk2j3kj232kjdkj

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

[Amir Taaki]

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 people upload to XFreeWebHost and then they're instantly set to go. Setting up a web host is very easy nowadays- as easy as click click click.

The other ideas are not so easy.

Also HTTPS + CA is the most secure of the bunch.

I'm curious to hear any other ideas too.

Thanks.



----- Original Message -----
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net" <bitcoin-development@lists.sourceforge.net>
Cc: 
Sent: Monday, December 12, 2011 10:21 PM
Subject: [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 genjix@genjix.net instead of 1jkddsjdskjwnk2j3kj232kjdkj

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

[Luke-Jr]

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

[theymos]

I like the user@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.

Almost all users will be unable to set up *any* always-on Internet
service to answer queries, so I'm not too concerned about how easy it is
to set up the server software.

I agree that FirstBits is bad for this. Unlike DNS, "registrations" last
forever because private keys can't be transferred safely. All short
names will be taken quickly. It will also be very expensive for clients
to query this themselves.

The CA model is broken and it should never be used by Bitcoin.

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

[Jorge Timón]

@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 various of them in the same QR-code.

@Amir
I see, the point is to be able to type the alias directly into the client.

I like the DNS proposal. This would allow for both well known working
centralized technology and namecoin (not proven, but decentralized)
options to be used.


2011/12/13, theymos <theymos@mm.st>:
> I like the user@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.
>
> Almost all users will be unable to set up *any* always-on Internet
> service to answer queries, so I'm not too concerned about how easy it is
> to set up the server software.
>
> I agree that FirstBits is bad for this. Unlike DNS, "registrations" last
> forever because private keys can't be transferred safely. All short
> names will be taken quickly. It will also be very expensive for clients
> to query this themselves.
>
> The CA model is broken and it should never be used by Bitcoin.
>
> ------------------------------------------------------------------------------
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>


-- 
Jorge Timón

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

[theymos]

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 user@server.com handling:
- Extend the protocol so that "reply" messages can be signed by a fixed
  public key
- Extend "checkorder" messages so they can specify an account to
  send BTC to. Or standardize on how to put the account into the
  message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
  also be used here to avoid having to use the IP transaction protocol
  sometimes. The public key for signing "reply" messages can be gotten
  from TXT records. This will be safe with DNSSEC and Namecoin. With
  plain DNS Bitcoin could take a SSH-like approach and ask the user to
  verify the public key the first time it is used, remembering it later.

DoS attacks are already handled by the IP transactions code: the same IP
address is always given the same bitcoin address until it pays to that
bitcoin address.

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

[Amir Taaki]

[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]

This is maybe the best idea. I added it:
https://en.bitcoin.it/wiki/BIP_0015#IP_Transactions

Things I like about this:
- IP transactions are useful, but have a security flaw. This mitigates their security problems.
- The code for IP transactions is already in Satoshi client. If other clients want to add IP transactions, then it can be done with minimal fuss/bloat.
I feel that for any protocol extension, less is more. The less code 
needed, the better the extension. Not always but generally we want to 
avoid bitcoin protocol bloat which *will* happen far in the future. The 
only way to mitigate how spaghettified the standard will be in the 
future, is by careful cautious planning now.

- We can have a proxy node running 24/7 for us, serving our public keys in lieu of us.



________________________________
 From: theymos <theymos@mm.st>
To: bitcoin-development@lists.sourceforge.net 
Sent: Thursday, 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 user@server.com handling:
- Extend the protocol so that "reply" messages can be signed by a fixed
  public key
- Extend "checkorder" messages so they can specify an account to
  send BTC to. Or standardize on how to put the account into the
  message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
  also be used here to avoid having to use the IP transaction protocol
  sometimes. The public key for signing "reply" messages can be gotten
  from TXT records. This will be safe with DNSSEC and Namecoin. With
  plain DNS Bitcoin could take a SSH-like approach and ask the user to
  verify the public key the first time it is used, remembering it later.

DoS attacks are already handled by the IP transactions code: the same IP
address is always given the same bitcoin address until it pays to that
bitcoin address.

------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.  
But none more important than the need to reduce IT complexity 
while improving strategic productivity.  Learn More! 
http://www.accelacomm.com/jaw/sdnl/114/51507609/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 3729 bytes --]

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

[Kyle Henderson]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

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 <theymos@mm.st> 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 user@server.com handling:
> - Extend the protocol so that "reply" messages can be signed by a fixed
>  public key
> - Extend "checkorder" messages so they can specify an account to
>  send BTC to. Or standardize on how to put the account into the
>  message field.
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
>  also be used here to avoid having to use the IP transaction protocol
>  sometimes. The public key for signing "reply" messages can be gotten
>  from TXT records. This will be safe with DNSSEC and Namecoin. With
>  plain DNS Bitcoin could take a SSH-like approach and ask the user to
>  verify the public key the first time it is used, remembering it later.
>
> DoS attacks are already handled by the IP transactions code: the same IP
> address is always given the same bitcoin address until it pays to that
> bitcoin address.
>
>

[-- Attachment #2: Type: text/html, Size: 1769 bytes --]

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

[Matt Corallo]

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 user@server.com handling:
I'm not against this, but I think its way overcomplicated when compared
to the DNS or HTTPS methods.
> - Extend the protocol so that "reply" messages can be signed by a fixed
>   public key
> - Extend "checkorder" messages so they can specify an account to
>   send BTC to. Or standardize on how to put the account into the
>   message field.
OK, not too debatable, but considering how terrible bitcoind's account
handling is, the second might not be easy to get right...
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
>   also be used here to avoid having to use the IP transaction protocol
>   sometimes. The public key for signing "reply" messages can be gotten
>   from TXT records. This will be safe with DNSSEC and Namecoin. With
>   plain DNS Bitcoin could take a SSH-like approach and ask the user to
>   verify the public key the first time it is used, remembering it later.
This is where I think this method becomes way overcomplicated.  Not only
do you have to update the IP-Transaction code, but now you have to
implement the full DNS System that is the other option as well.  Note
that to make this secure, we have to have a full DNSSEC-capable resolver
built-into bitcoind (there are libs, but it has to happen).  Yes you can
ask the user "does this fingerprint look right to you? Y/N" but that
always opens you up to a ton of users getting screwed out of coins and I
don't think it should be enabled, except in bitcoind, and since the main
target of this whole alias system is bitcoin-qt users, well...

Matt

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

[Walter Stanish]

> 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 create distributed consensus
within the bitcoin network.
 - Very few people - even those who wish to have a permanent alias -
want to have it map to a permanent bitcoin address, since this
discloses their financial history (eg: income for a business) to the
public
 - Some people want throw-away (single use) aliases, others want
permanent ones.  This means many addresses.
 - Blockchain bloat is already acknowledged as an issue.
 - The blockchain is not really a good option.

Leaving out the blockchain, there are still ways to implement aliasing.

What is the core problem for an extra-blockchain aliasing system?

At the core is usability - people basically want aliases to make it
easier to type in or remember addresses.  So a solution that
sacrifices usability too far is a broken one.

Another requirement is absolute security.  A user of the aliasing
system is going to trust it to translate a particular alias to a
bitcoin address - ie: 'where my money goes with absolutely zero chance
(by default)  of getting it back if it's sent somewhere wrong by
accident'.  Such an accident might be mistyping an alias.  It might
also be a hijacking of the alias resolution system (eg: a DNS based
system without DNSSEC, etc.).  As a case in point, we already see very
well organized attacks by domain squatters in order to steal traffic
or effect phishing under the DNS system.

So... to help see which qualities are meaningful for such an alias
system, let's look at what types of solutions to these problems exist
within conventional (ie: mature) financial systems.

First, arbitrary aliases are not in use.  This means that memory-based
mnemonics are not subject to predictable squatting-style attacks.  For
our purposes, this means that if you are payments@business1.com, I
can't go and register payments@busines1.com and take a portion of your
inbound cash whenever a client tries to pay you and typos on the send
address.  Likewise, if you're 'someuser@hostedwalletservice.com' I
can't go and register as 'someuse@hostedwalletservice.com' and pull
the same heist. IIBAN is the only aliasing proposal I have seen
mentioned within this thread that adopts this strategy, the others all
maintain this vulnerability through DNS. HTTP relies on DNS.

Second, checksum systems detect transposition errors. This is a very
powerful feature, which (I can't be bothered googling for stats, but
just think about it) cuts out the vast majority of such errors
instantly, at the time of input, before money changes hands or
anything touches the financial settlement networks.  IIBAN adopts
exactly the same mature and proven MOD97-based two digit checksum
feature that is used within the IBAN standard, proposed by the
European Union with the benefit of decades of banking experience in
many member states and now growing rapidly in use around the world.
(For something as expensive and painful to implement as a
nationally-mandated banking standard affecting all member banks, a
growth rate of 'a few countries per year' is a pretty serious growth
curve!)  With checksums, it's even possible to auto-suggest
corrections based upon common transposition errors and help the user
to check those parts of the alias for common errors more quickly.

Third, conventional financial systems typically require recipient name
(and sometimes address, or business tax numbers in some countries'
domestic schemes) as part of the transaction.  This secondary data
facilitates error checking since an incorrectly supplied destination
address can be checked against these properties.  Of course, Bitcoin
presently has no such secondary input with which to verify the
destination of a transfer, and since blockchain bloat is an
acknowledged issue and very few bitcoin users would like to see their
names appear against their transactions within the blockchain (visible
to all, for eternity!) it also seems that this feature is not going to
be added and for good reason.  However, within an external (and not
necessarily bitcoin specific) higher-level 'transaction negotation'
protocol (alluded to in earlier posts as a logical extension of the
pre transaction alias resolution mechanism, and being a pre
transaction connection of some nature between a payer and payee, or
their proxying/representing institution, in the case of hosted
wallets/aliases), such external destination validation features could
be added. (Many types are possible... data-based as per name/address
validation, cryptographic validation schemes, etc.)

Finally, an increasing number of countries use an aliasing scheme
(IBAN) that is familiar to users.  Doing so for digital currencies
such as Bitcoin increases usability (by eliminating novelty, and in
the case of IIBAN which is not specific to any given currency, the
need to register, recall and manage yet another account identifier),
which was one of the original goals. None of the other proposals
mentioned have this property.

I won't go in to other benefits previously mentioned of the IIBAN
proposal, but I still cannot see any reason to either:
 - Include aliasing within bitcoind itself
 - Re-invent the wheel
 - Scare off non-technical users
 - Dodge the fact that there are unique properties of bitcoin that
will always remain and should perhaps simply be acknowledged and
worked around OUTSIDE of the codebase, rather than within.
Unix/internet philosophy is that it's usually best to keep code as
simple as possible, to 'do one thing' and 'do it well'. For bitcoind
(despite sharing a codebase with the GUI), that something is achieving
a distributed internet-based financial system that is free from legacy
centralized currencies. It is *not* worrying about making it look
pretty or easy to use, which can be achieved by layering totally
external systems through simply translating various alternate
representations ('aliases') to the well defined bitcoin addressing
scheme.

Just to avoid any notion of table-banging (Hah! A lost cause?), this
will be the last IIBAN-related post I will make on this thread, but
there will be some further announcements in the near future.

Keep up the good work everyone.

Regards,
Walter Stanish
Payward Inc.

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

[Pieter Wuille]

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

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

[Rick Wesson]

On Fri, Dec 16, 2011 at 12:35 AM, Pieter Wuille <pieter.wuille@gmail.com> 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.
> 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...).

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
and reviewing their work on hardening certificate (x.509)
infrastructure as your HTTPS scheme will inherit the issues we
currently experience with CAs getting p0wned.

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 protocols. The proposals in this thread are neither clear
nor elegant. If you can't reach nearly the same level of
sophistication then I suggest you rethink your scheme.

-rick

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

[Pieter Wuille]

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 protocols. The proposals in this thread are neither clear
> nor elegant. If you can't reach nearly the same level of
> sophistication then I suggest you rethink your scheme.

That's why you use URI + bitcoin address pairs, and use SSL communication
authenticated using the respective bitcoin pubkey. They may spoof your DNS
server, they can't fake having the requested corresponding private key.

Obviously, this moves the problem to getting the URL + address securely
to the client that wants to interact with it, but that is inevitable if
you're not going to rely on a pre-trusted certificate authority and PKI.

Also, the client software can cache the address corresponding to a particular
server or URL, making it similar to an ssh client that caches host keys and
warns when they change.

-- 
Pieter

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

[Rick Wesson]

On Fri, Dec 16, 2011 at 8:17 AM, Pieter Wuille <pieter.wuille@gmail.com> 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 considering. Review some of the elegance in
>> the bitcoin protocols. The proposals in this thread are neither clear
>> nor elegant. If you can't reach nearly the same level of
>> sophistication then I suggest you rethink your scheme.
>
> That's why you use URI + bitcoin address pairs, and use SSL communication
> authenticated using the respective bitcoin pubkey. They may spoof your DNS
> server, they can't fake having the requested corresponding private key.

You are making my point (again) regarding usability and security.
Aliases are not a https secured URI+bitcoin address.

-rick

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

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 1567 bytes --]

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 as your HTTPS scheme will inherit the issues we
> currently experience with CAs getting p0wned.

This is the only real problem with HTTPS: we would be centralising part of our 
otherwise decentralised system.  CAs are certainly a risk.

However, trust is needed somewhere in the communication.  There is no way to 
securely communicate between A and B without the use of some previously 
trusted secure channel -- in Joe Sixpack's case it's by assuming that the 
browser he downloaded came with an untainted CA list, and that the CAs are 
trustworthy.  Neither of which is guaranteed.  Until and unless we get PGP 
support in browsers, CAs are all that we have.

Worrying about CAs misses the point anyway; if we're being that paranoid -- 
how did A tell B the appropriate alias to use for a lookup?  Was that channel 
secure too?  I could set up a MITM server that simply looks for the alias 
"RICKWESSON@bitcoinaliases.org" and rewrites it to 
"ANDYPARKINS@bitcoinaliases.org".  When the answer to that problem is HTTPS 
(or some other system that requires a previously authorised secure channel for 
transfer of trust), then we're back where we started, and HTTPS is acceptable.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Khalahan]

[-- Attachment #1: Type: text/plain, Size: 7601 bytes --]

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 perfect starting point to map names to
other things (a public bitcoin address, an url, etc)
You won't have all the advantages of namecoin when using other systems
like DNS and HTTP(S) as the first entry point.

What is namecoin ?

* proven technology :
- do not mix the namecoin technology and the dot-bit namespace with .bit
domains (dot-bit domains needs dot-bit compatible dns servers or proxies
+ namecoin and have a small visibility due to the nature of
top-to-bottom domain name system controlled by ICANN, namecoin needs
only namecoin to store data !)
- as proven and secure as bitcoin
- merged mining provides a secure network

* decentralized :
- a lot of nodes, and you can have your own node
- everybody can register his own name, by itself with the namecoin
software (bitcoin could even allow registration directly from it,
easily) or by using a name provider
- everybody can become a name provider (register for your friends and
resell names).

* no single point of failure :
- DNS and HTTPS have several limitations (Man in the Middle attacks, no
reliable authority of certifications, domain seizure, ...)

* designed for that :
- namecoin uses a system of namespaces to separate each usages :
http://dot-bit.org/Main_Page#Namespaces.
For example, the "personal namespace" draft
(http://dot-bit.org/Personal_Namespace) could be extended to support
mapping to a bitcoin address, or a dedicated namespace can be used if
prefered (the "bitcoin/" or "alias/" or "map/" prefixes for example).

* easily connectable to bitcoin
- they both use RPC and json to exchange informations, so connecting one
to the other is really easy
- bitcoin could even allow registration of names by sending an RPC
request to namecoin

* extensible and not limited :
- you are not forced to store a bitcoin address directly in namecoin,
you can also store an url or a domain name
- allows additional security : add a certificate fingerprint combined
with an https url (so, using DNS or HTTP(S) is not a major problem
anymore if the first point of entry is really secure and configurable
[and you use and self-signed certificate])
- really easy to update
- simple for simple cases
- possibility to use a nick, an email address or a domain as name
- other methods to get bitcoins addresses can be added later, protocol
is extensible


Examples of possible registered names in namecoin with the "personal
namespace" (with the "p/" prefix) :

* An individual person with well known public addresses :
"p/*khal*":
{
    "email": "khal@dot-bit.org",
    "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}

* Another individual person with well known public addresses :
"p/*khal@dot-bit.org*":
{
    "bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    "namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}

* A merchant accepting payments in bitcoin, namecoin, paypal or
othercoin (to show you how the whole namespace could be used) :
"p/*mymerchant.com*":
{
    "bitcoin": {
        "url": "https://payto.mymerchant.com/bitcoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
        "cert": "https://payto.mymerchant.com/certificate.pem",
    },
    "namecoin": {
        "url": "https://payto.mymerchant.com/namecoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
    },
    "paypal": "xxxxxx@yyyyyyyyy.zzz",
    "othercoin": "oxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

* A merchant with a public address, an url to generate custom addresses
and a domain name (not sure if this case is really usefull, maybe as
fallback)
"p/*mymerchant2*":
{
    "bitcoin": {
        "url": "https://payto.mymerchant.com/bitcoin/",
        "fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926",
        "dns": "_bitcoin.payto.mymerchant.com",
        "address": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
    }
}


* How to use it in bitcoin ?

Several possibilities of address syntax :
- khal, khal@dot-bit.org, mymerchant.com, mymerchant2 : no syntax limit
- mymerchant2@bitcoin : will conflict with names already containing a @
- mymerchant2@namecoin : same
- namecoin:mymerchant2 : strange syntax, confusing with the "uri scheme"
- namecoin://mymerchant2 : same
- other ?


Here is how things would be processed when people put an address to pay
to in the bitcoin client :

* address : khal
-> RPC to namecoin for "p/khal"
-> json processing for "p/khal->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

* address : khal@dot-bit.org
-> RPC to namecoin for "p/khal@dot-bit.org"
-> json processing for "p/khal@dot-bit.org->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T

* address : mymerchant.com
-> RPC to namecoin for "p/mymerchant.com"
-> json processing for "p/mymerchant.com->bitcoin"
-> json processing for "p/mymerchant.com->bitcoin->url" and
"p/mymerchant.com->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy

* address : mymerchant2
-> RPC to namecoin for "p/mymerchant2"
-> json processing for "p/mymerchant2->bitcoin"
-> json processing for "p/mymerchant2->bitcoin->url" and
"p/mymerchant2->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : error (website unavailable, page not found, timeout, etc)
-> json processing for "p/mymerchant2->bitcoin->dns"
-> dns request for "_bitcoin.payto.mymerchant.com"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy


Le 15/12/2011 20:59, theymos a écrit :
> 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 user@server.com handling:
> - Extend the protocol so that "reply" messages can be signed by a fixed
>   public key
> - Extend "checkorder" messages so they can specify an account to
>   send BTC to. Or standardize on how to put the account into the
>   message field.
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
>   also be used here to avoid having to use the IP transaction protocol
>   sometimes. The public key for signing "reply" messages can be gotten
>   from TXT records. This will be safe with DNSSEC and Namecoin. With
>   plain DNS Bitcoin could take a SSH-like approach and ask the user to
>   verify the public key the first time it is used, remembering it later.
>
> DoS attacks are already handled by the IP transactions code: the same IP
> address is always given the same bitcoin address until it pays to that
> bitcoin address.
>
> ------------------------------------------------------------------------------
> 10 Tips for Better Server Consolidation
> Server virtualization is being driven by many needs.  
> But none more important than the need to reduce IT complexity 
> while improving strategic productivity.  Learn More! 
> http://www.accelacomm.com/jaw/sdnl/114/51507609/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>


-- 
Best Regards,
Khalahan
http://dot-bit.org/


[-- Attachment #2: Type: text/html, Size: 11135 bytes --]

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

[slush]

[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]

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 alias system in namecoin and *cleanly integrate it with bitcoin*.
Don't forget that people who want to do lookup need to maintain also
namecoin blockchain with their bitcoin client. It goes against my instinct
of keeping stuff easy.

For example, yesterday I implemented HTTPS lookup for addresses into my
fork of Electrum client. I did it in 15 minutes, it works as expected, it
does the job and the implementation is really transparent, becuase
implementation is 20 lines of code. There's no magic transformation, no
forced "?handle=" parameters or whatever. And I don't care if somebody
provide URL
https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True

And everybody can do the same in their clients, in their merchant
solutions, websites or whatever. Everybody can do HTTPS lookup. But try to
explain DNS, Namecoin, IIBAN, email aliases to other programmers...

Those IIBAN - well, why not. At least I see the potential in PR. So far I
understand it as some teoretic concept which is not supported by anything
else right now. Give it few years until it matures and then add IIBAN alias
to Bitcoin client too.

Maybe I'm repeating myself already, but the way to go is to make aliases as
easy as possible, so everybody can implement it in their own solution and
thus practially remove the need of using standard bitcoin addresses for
normal users. Using some superior technology, which is hard to implement or
even understand won't solve the situation, because it will ends up with
some reference implementation in standard client only and nobody else will
use it.

slush

On Fri, Dec 16, 2011 at 6:23 PM, Khalahan <khal@dot-bit.org> wrote:

> **
> 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.
>
>

[-- Attachment #2: Type: text/html, Size: 2820 bytes --]

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

[Amir Taaki]

[-- Attachment #1: Type: text/plain, Size: 4234 bytes --]

I think IBANs are not such a good idea. Note that as someone who has spent the last year of my life dealing with hundreds of bank transactions a day and interacting with the banking system (both on a technical, systematic and personnel level), the entire system is a gigantic mess.

The banks are in fact looking to us for answers. That's why we (Bitcoin Consultancy) were invited to the SWIFT conference to join their panel on bank 2.0.

I don't even mind the maxim "take everything the banks have done and do the complete opposite" :)

I invite anyone who is skeptical to read the ECB's specification on SEPA payments. It really is an example of a system made to work alongside legacy systems that rely on inefficient people. The interchange fees are dependent on a totally arbitrary test of merchant indifference and various antitrust regulations.

These systems are usually built not by engineers or hackers, but by finance people. IBAN has no place in bitcoin IMO.

I don't mean to sound too critical, but I'm skeptical of its usefulness. Especially when we already have bitcoin addresses with their own checksums- what value do IBANs add? Nothing except negatives.



________________________________
 From: slush <slush@centrum.cz>
To: Khalahan <khal@dot-bit.org> 
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 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 alias system in namecoin and *cleanly integrate it with bitcoin*. Don't forget that people who want to do lookup need to maintain also namecoin blockchain with their bitcoin client. It goes against my instinct of keeping stuff easy.

For example, yesterday I implemented HTTPS lookup for addresses into my fork of Electrum client. I did it in 15 minutes, it works as expected, it does the job and the implementation is really transparent, becuase implementation is 20 lines of code. There's no magic transformation, no forced "?handle=" parameters or whatever. And I don't care if somebody provide URL https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True

And everybody can do the same in their clients, in their merchant solutions, websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS, Namecoin, IIBAN, email aliases to other programmers...


Those IIBAN - well, why not. At least I see the potential in PR. So far I understand it as some teoretic concept which is not supported by anything else right now. Give it few years until it matures and then add IIBAN alias to Bitcoin client too.

Maybe I'm repeating myself already, but the way to go is to make aliases as easy as possible, so everybody can implement it in their own solution and thus practially remove the need of using standard bitcoin addresses for normal users. Using some superior technology, which is hard to implement or even understand won't solve the situation, because it will ends up with some reference implementation in standard client only and nobody else will use it.

slush


On Fri, Dec 16, 2011 at 6:23 PM, Khalahan <khal@dot-bit.org> wrote:

 
>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.
>
>
------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 6266 bytes --]

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

[Harald Schilly]

On Fri, Dec 16, 2011 at 21:10, Amir Taaki <zgenjix@yahoo.com> 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

[Khalahan]

[-- Attachment #1: Type: text/plain, Size: 3459 bytes --]

The number of proposals <https://en.bitcoin.it/wiki/BIP_0015> 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 address for example, because i don't control the
gmail.com domain)
- Server Service (DNS + a daemon) : Same as DNS TXT records
- HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able
to check the full certificate chain and access a list of up-to-date
certificate authorities (installed on the OS or provided with bitcoin).
And don't forget the CA model is not 100% reliable (several CA hacked
this year + possible government control...).
- IP Transactions : /This proposal seeks to enable DNS lookups for IP
transactions/ => same as above

I know that providing a namecoin daemon with bitcoin is not the lighter
solution, but, if a better one existed i guess it would have already
been integrated into bitcoin... (see in what state is my first attempt
with the HTTPS proposal : Send payments to emails, urls and domains in
GUI <https://github.com/bitcoin/bitcoin/pull/174> - /khalahan opened
this pull request April 20, 2011/)

So, what's next ?

Le 16/12/2011 20:54, slush a écrit :
> 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 alias system in namecoin and *cleanly
> integrate it with bitcoin*. Don't forget that people who want to do
> lookup need to maintain also namecoin blockchain with their bitcoin
> client. It goes against my instinct of keeping stuff easy.
>
> For example, yesterday I implemented HTTPS lookup for addresses into
> my fork of Electrum client. I did it in 15 minutes, it works as
> expected, it does the job and the implementation is really
> transparent, becuase implementation is 20 lines of code. There's no
> magic transformation, no forced "?handle=" parameters or whatever. And
> I don't care if somebody provide URL
> https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
> <https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True>
>
> And everybody can do the same in their clients, in their merchant
> solutions, websites or whatever. Everybody can do HTTPS lookup. But
> try to explain DNS, Namecoin, IIBAN, email aliases to other programmers...
>
> Those IIBAN - well, why not. At least I see the potential in PR. So
> far I understand it as some teoretic concept which is not supported by
> anything else right now. Give it few years until it matures and then
> add IIBAN alias to Bitcoin client too.
>
> Maybe I'm repeating myself already, but the way to go is to make
> aliases as easy as possible, so everybody can implement it in their
> own solution and thus practially remove the need of using standard
> bitcoin addresses for normal users. Using some superior technology,
> which is hard to implement or even understand won't solve the
> situation, because it will ends up with some reference implementation
> in standard client only and nobody else will use it.
>
> slush

-- 
Best Regards,
Khalahan
http://dot-bit.org/


[-- Attachment #2: Type: text/html, Size: 4666 bytes --]

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

[Rick Wesson]

On Fri, Dec 16, 2011 at 1:52 PM, Khalahan <khal@dot-bit.org> 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 able to
> use a gmail address for example, because i don't control the gmail.com
> domain)

The same goes for http(s) one would not be able to use
http://google.com/user unless google offers the services.

ALSO look at DANE for getting around the certificate requirement for https

> - Server Service (DNS + a daemon) : Same as DNS TXT records

DNS TXT are not the only way forward, also registry/registrars can facilitate.

> - HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able to
> check the full certificate chain and access a list of up-to-date certificate
> authorities (installed on the OS or provided with bitcoin). And don't forget
> the CA model is not 100% reliable (several CA hacked this year + possible
> government control...).

This most likely relies on a paid, valid certificate (that expires),
no self signed certs. I admit that running a secured https server with
a valid CA signed  cet is as simple/hard as running a DNSSEC authority
zone.

using a x.509 certificate to secure a bitcoin transaction removes some
of the anonymity of the transaction by allowing the lookup to identify
the certification, ca, crl etc thus connecting a transaction/bitcoin
address to the cert and to its issuing authority. No matter the
frequency of the destination bitcoin address changing.

IMNSHO, leveraging CAs to secure http to provide a lookup translation
to a bitcoin address will only erode anonymity. While DNS is connected
to whois there are provision for hiding behind a proxy where to the
best of my knowledge there are no such provisions offered by CA's
issuing x.509 certificates.

Should self signed cers be "allowed" or encouraged only decreases
security. Clearly DANE would be the only way to mitigate this
situation but then you are back to relying on DNSSEC to bind the x.509
cert.

wash, rinse,  ...

-rick

> - IP Transactions : This proposal seeks to enable DNS lookups for IP
> transactions => same as above
>
> I know that providing a namecoin daemon with bitcoin is not the lighter
> solution, but, if a better one existed i guess it would have already been
> integrated into bitcoin... (see in what state is my first attempt with the
> HTTPS proposal : Send payments to emails, urls and domains in GUI - khalahan
> opened this pull request April 20, 2011)
>
> So, what's next ?
>
> Le 16/12/2011 20:54, slush a écrit :
>
> 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 alias system in namecoin and *cleanly integrate it with bitcoin*. Don't
> forget that people who want to do lookup need to maintain also namecoin
> blockchain with their bitcoin client. It goes against my instinct of keeping
> stuff easy.
>
> For example, yesterday I implemented HTTPS lookup for addresses into my fork
> of Electrum client. I did it in 15 minutes, it works as expected, it does
> the job and the implementation is really transparent, becuase implementation
> is 20 lines of code. There's no magic transformation, no forced "?handle="
> parameters or whatever. And I don't care if somebody provide URL
> https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
>
> And everybody can do the same in their clients, in their merchant solutions,
> websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS,
> Namecoin, IIBAN, email aliases to other programmers...
>
> Those IIBAN - well, why not. At least I see the potential in PR. So far I
> understand it as some teoretic concept which is not supported by anything
> else right now. Give it few years until it matures and then add IIBAN alias
> to Bitcoin client too.
>
> Maybe I'm repeating myself already, but the way to go is to make aliases as
> easy as possible, so everybody can implement it in their own solution and
> thus practially remove the need of using standard bitcoin addresses for
> normal users. Using some superior technology, which is hard to implement or
> even understand won't solve the situation, because it will ends up with some
> reference implementation in standard client only and nobody else will use
> it.
>
> slush
>
>
> --
> Best Regards,
> Khalahan
> http://dot-bit.org/
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

[Jorge Timón]

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 valid format of the answered
message? I mean fields like "amount", "concept" and such.

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

[Jordan Mack]

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 structure that 
would be used?


On 12/18/2011 1:05 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, namecoin or
> whatever they trust.
>
> Shouldn't we be also discussing the valid format of the answered
> message? I mean fields like "amount", "concept" and such.
>

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

[Luke-Jr]

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, namecoin or
> whatever they trust.

How are you going to authenticate the host? Certificates from CAs are how 
HTTPS does it. HTTP is vulnerable. If the URI contains an address (eg, 
bitcoin://remotehost/base58key), the remote host could sign its (self-signed) 
SSL key with the ECDSA key to prove authenticity. DNSSEC/namecoin presumably 
has some way to do this as well.

> Shouldn't we be also discussing the valid format of the answered
> message? I mean fields like "amount", "concept" and such.

At some point, a proper protocol to negotiate payment is needed for anything 
like this.

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

[slush]

[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]

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 <luke@dashjr.org> 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 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.
>
> How are you going to authenticate the host? Certificates from CAs are how
> HTTPS does it. HTTP is vulnerable. If the URI contains an address (eg,
> bitcoin://remotehost/base58key), the remote host could sign its
> (self-signed)
> SSL key with the ECDSA key to prove authenticity. DNSSEC/namecoin
> presumably
> has some way to do this as well.
>
> > Shouldn't we be also discussing the valid format of the answered
> > message? I mean fields like "amount", "concept" and such.
>
> At some point, a proper protocol to negotiate payment is needed for
> anything
> like this.
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2407 bytes --]

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

[Luke-Jr]

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) rather 
than merely sending a simple payment to a single fixed address.

I am not convinced *aliases* are practical, without CA trust. An organization 
that wants to trust a CA with all their funds can leave off the address 
portion, to provide more human-friendly URIs.

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

[Pieter Wuille]

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 receive payments to
you...

If no trusted CA is used to authenticate the communication, there is no way
to be sure the one you are asking how to pay, is the person you want to pay.
Therefore, one solution is to put a bitcoin address in the identification
string itself, and requiring SSL communication authenticated using the
respective key.

This makes the identification strings obviously less useful as aliases,
but pure aliases in the sense of human-typable strings have imho
limited usefulness anyway - in most cases these identification strings
will be communicated through other electronic means anyway.

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 ignored by most users anyway, but what do you do about
that?)

-- 
Pieter

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

[Luke-Jr]

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 ignored by most users anyway, but what do you do about
> that?)

Like SSH, don't make it easy to ignore.
eg, to ignore it, you need to manually go in and remove it from the URI.

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

[slush]

[-- Attachment #1: Type: text/plain, Size: 2720 bytes --]

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 secure enough. At least nobody mentioned it
yet. And if I need to choose between easy solution or secure solution for
aliases, I'll pick that easy one. I mean - we need some solution which will
be easy enough for daily use; it is something what we currently don't have.
But if I want to be really really sure I'm using correct destination for
paying $1mil for a house, I can every time ask for real bitcoin addresses,
this is that secure way which we currently have.

slush

On Mon, Dec 19, 2011 at 2:14 AM, Pieter Wuille <pieter.wuille@gmail.com>wrote:

> 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 receive payments
> to
> you...
>
> If no trusted CA is used to authenticate the communication, there is no way
> to be sure the one you are asking how to pay, is the person you want to
> pay.
> Therefore, one solution is to put a bitcoin address in the identification
> string itself, and requiring SSL communication authenticated using the
> respective key.
>
> This makes the identification strings obviously less useful as aliases,
> but pure aliases in the sense of human-typable strings have imho
> limited usefulness anyway - in most cases these identification strings
> will be communicated through other electronic means anyway.
>
> 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 ignored by most users anyway, but what do you do about
> that?)
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3552 bytes --]

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

[Jorge Timón]

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 difficult and probably most clients won't
support it. Using namecoin to directly specify the payment address
seems a bad idea for most cases for the reasons that have been said.

For the "answer format" JSON seems ok, but I mean a "negotiating
protocol" like luke-jr says. I'd even include green addresses there
but probably many of you don't like the idea.

2011/12/19, slush <slush@centrum.cz>:
> And if I need to choose between easy solution or secure solution for
> aliases, I'll pick that easy one. I mean - we need some solution which will
> be easy enough for daily use; it is something what we currently don't have.
> But if I want to be really really sure I'm using correct destination for
> paying $1mil for a house, I can every time ask for real bitcoin addresses,
> this is that secure way which we currently have.

I agree.

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

[Andy Parkins]

[-- Attachment #1: Type: Text/Plain, Size: 1088 bytes --]

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 rather than technical.  Multiple CAs 
have been strong-armed by governments or tricked into issuing fake 
certificates by scammers.  There is no technical measure around that.  By 
using the CA certificate we are saying to the system "here is someone I trust 
to issue a certificate".  So far, with a large number of CAs, that trust is 
misplaced.

I'm of the opinion though that this problem is outside the remit of bitcoin to 
solve.

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 comes pre-installed for me in my browser.



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[solar]

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 for bitcoin software to promise any trust.

The part where the concept becomes flawed is trusting 3rd parties who have no relationship with you, to serve your interests.  Now I'm just generalizing here and this is not universally true.. but internet CAs just want to sell certificates - they generally don't care beyond that, and they abuse the certificate validity dates to charge more money.  All this is done under the guise of wanting to provide a secure experience to users without a prior relationship to the entity being identified.  I propose that trying to follow this paradigm in bitcoin alias resolution is a bad idea because it tries to solve 2 problems at once, one of which does not have any 'good' solution, and forces a specific policy.

First, we need to resolve an alias to a bitcoin address somehow.. but secondly we need to establish trust with the entity doing the alias resolution - to make sure that we can trust the response.

When resolving an alias you will have to query an untrusted server, possibly being proxied by an 'attacker'.  Presumably, an x.509 certificate will be presented, possibly self signed or chained off a self generated CA or whatever else.. but if it's your first contact then there is no possible way to know if it's correct or not.  You would have to retrieve the correct public key of the CA to compare to first, possibly out of band.  Get it from my website, compare it to my business card, send me an email and I'll send it to you, or get it from some other source using some other pre existing trust (a centralized and possibly private directory perhaps).  The point is, the reason there is so much disagreement is because there is no good way to trust the resolver if you don't create that trust relationship prior to resolving an alias from it.

I think that having to pre-trust the resolver would be an acceptable solution to all.. Those whose policy requires a simpler process can get a 3rd party CA list, much like the ones provided with web browsers and operating systems.  Those with strict verification policies can choose to pre verify every public key.. and these processes are familiar to many organizations using PKI for other things already.  In a client, presenting the usual certificate detail dialog, showing the public key, subject, issuer, and thumbprint would be sufficient to allow users to implement their own policies without forcing it one way or another.

Please consider that while some organizations or users might require strong anonymity and pre existing trust, there are others who may want to do the opposite and that is just as valid, even if you or 'everyone else' disagrees with that.  In the case of bitcoin, it will be used as part of a larger system, and whatever concerns are created by 'insecure' alias resolution may well be addressed in another part of the system.  The most successful standards and implementations are the ones which provide the most flexibility - primarily because that allows users to extend them in ways the original designers didn't necessarily plan for.

Thanks,
Laszlo



On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote:

> 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 rather than technical.  Multiple CAs 
> have been strong-armed by governments or tricked into issuing fake 
> certificates by scammers.  There is no technical measure around that.  By 
> using the CA certificate we are saying to the system "here is someone I trust 
> to issue a certificate".  So far, with a large number of CAs, that trust is 
> misplaced.
> 
> I'm of the opinion though that this problem is outside the remit of bitcoin to 
> solve.
> 
> 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 comes pre-installed for me in my browser.
> 
> 
> 
> Andy
> 
> -- 
> Dr Andy Parkins
> andyparkins@gmail.com
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for 
> developers. It will provide a great way to learn Windows Azure and what it 
> provides. You can attend the event by watching it streamed LIVE online.  
> Learn more at http://p.sf.net/sfu/ms-windowsazure_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Rick Wesson]

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 that the certificate provided
   by the TLS server is in fact associated with the domain name they
   expect.  TLSA provides bindings of keys to domains that are asserted
   not by external entities, but by the entities that operate the DNS.
   This document describes how to use secure DNS to associate the TLS
   server's certificate with the intended domain name.


For those of you against DNSSEC, DANE leverages it significantly.

The point I have been attempting to make is if one to rely on HTTPS,
leveraging DANE will allow you to mitigate CAs and use self signed
cers but you will need to leverage DNSSEC to bind the self signed cert
using DANE and if you are going to rely on DNSSEC for DANE to support
HTTPS, why not short-circut this madness and just publish your
identifiers and secure the zone via DNSSEC and link in a stub resolver
in the client.

Short story: transform user@authority.tld  --> _btc.user.athority.tld TXT 1z....

A short i-d is probably a better way to explain, so I will task myself
to do that.

-rick


On Mon, Dec 19, 2011 at 6:46 AM, solar <solar@heliacal.net> wrote:
> 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 for bitcoin software to promise any trust.
>
> The part where the concept becomes flawed is trusting 3rd parties who have no relationship with you, to serve your interests.  Now I'm just generalizing here and this is not universally true.. but internet CAs just want to sell certificates - they generally don't care beyond that, and they abuse the certificate validity dates to charge more money.  All this is done under the guise of wanting to provide a secure experience to users without a prior relationship to the entity being identified.  I propose that trying to follow this paradigm in bitcoin alias resolution is a bad idea because it tries to solve 2 problems at once, one of which does not have any 'good' solution, and forces a specific policy.
>
> First, we need to resolve an alias to a bitcoin address somehow.. but secondly we need to establish trust with the entity doing the alias resolution - to make sure that we can trust the response.
>
> When resolving an alias you will have to query an untrusted server, possibly being proxied by an 'attacker'.  Presumably, an x.509 certificate will be presented, possibly self signed or chained off a self generated CA or whatever else.. but if it's your first contact then there is no possible way to know if it's correct or not.  You would have to retrieve the correct public key of the CA to compare to first, possibly out of band.  Get it from my website, compare it to my business card, send me an email and I'll send it to you, or get it from some other source using some other pre existing trust (a centralized and possibly private directory perhaps).  The point is, the reason there is so much disagreement is because there is no good way to trust the resolver if you don't create that trust relationship prior to resolving an alias from it.
>
> I think that having to pre-trust the resolver would be an acceptable solution to all.. Those whose policy requires a simpler process can get a 3rd party CA list, much like the ones provided with web browsers and operating systems.  Those with strict verification policies can choose to pre verify every public key.. and these processes are familiar to many organizations using PKI for other things already.  In a client, presenting the usual certificate detail dialog, showing the public key, subject, issuer, and thumbprint would be sufficient to allow users to implement their own policies without forcing it one way or another.
>
> Please consider that while some organizations or users might require strong anonymity and pre existing trust, there are others who may want to do the opposite and that is just as valid, even if you or 'everyone else' disagrees with that.  In the case of bitcoin, it will be used as part of a larger system, and whatever concerns are created by 'insecure' alias resolution may well be addressed in another part of the system.  The most successful standards and implementations are the ones which provide the most flexibility - primarily because that allows users to extend them in ways the original designers didn't necessarily plan for.
>
> Thanks,
> Laszlo
>
>
>
> On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote:
>
>> 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 rather than technical.  Multiple CAs
>> have been strong-armed by governments or tricked into issuing fake
>> certificates by scammers.  There is no technical measure around that.  By
>> using the CA certificate we are saying to the system "here is someone I trust
>> to issue a certificate".  So far, with a large number of CAs, that trust is
>> misplaced.
>>
>> I'm of the opinion though that this problem is outside the remit of bitcoin to
>> solve.
>>
>> 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 comes pre-installed for me in my browser.
>>
>>
>>
>> Andy
>>
>> --
>> Dr Andy Parkins
>> andyparkins@gmail.com
>> ------------------------------------------------------------------------------
>> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
>> Microsoft is holding a special Learn Windows Azure training event for
>> developers. It will provide a great way to learn Windows Azure and what it
>> provides. You can attend the event by watching it streamed LIVE online.
>> Learn more at http://p.sf.net/sfu/ms-windowsazure_______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Luke-Jr]

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 custom output script). The HTTP 
specification, however, allows binary data in multipart content just fine.

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

[Luke-Jr]

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 comes pre-installed for me in my browser.

Accepted CAs is/should be a property of your *operating system*, not any 
particular software. Anyhow, restricting this further just makes it even more 
unusable. Already there is only 1 or 2 CAs that will provide a gratis 
certificate for personal/small users. If you only allow high-class CAs, I 
imagine that will restrict "no key in the URI" aliases to those who will fork 
over a lot of money.

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

[Jordan Mack]

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 personally 
prefer XML in most cases, but since JSON is already used with the RPC, 
it seemed like a natural fit here. Binary data can be base64 encoded, 
although I'm not sure why you would need to send back binary in an alias 
response.

What exactly do you mean by "custom output script"?


On 12/19/2011 8:30 AM, Luke-Jr wrote:
> 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 custom output script). The HTTP
> specification, however, allows binary data in multipart content just fine.

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

[slush]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

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 it's another story).

slush

On Mon, Dec 19, 2011 at 6:04 PM, Jordan Mack <jordanmack@parhelic.com>wrote:

> I thought that JSON support was fairly common these days. I personally
> prefer XML in most cases, but since JSON is already used with the RPC,
> it seemed like a natural fit here. Binary data can be base64 encoded,
> although I'm not sure why you would need to send back binary in an alias
> response.
>

[-- Attachment #2: Type: text/html, Size: 1028 bytes --]

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

[solar]

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 way to use it.. my policy may be (as an example) to require each party I deal with to generate their own self signed cert or their own CA cert (same thing really) and then I can trust that and only that.  Obviously, commercial CAs will sell a certificate to anyone which means you trust anyone that is their customer.  This is a valid site policy but not for everyone.

Rick Wesson's suggestion about DNSSEC and such is interesting since it would provide a system for that 'first contact' exchange where you can more reliably retrieve the certificate, if the site supports it.  Some policies may not require this however - you can always get the trust established another way like downloading a cert file from a website or whatever else you consider adequately secure for your organization.

I think 3rd party CA lists and the DNSSEC/DANE idea are both useful ways to automatically establish trust out of band, but this is independent of the actual implementation of alias resolution, which happens after a trusted connection is made.  Automatically establishing trust with the alias resolver is perhaps a useful feature, but not a requirement for either side to support alias resolution.

In any case, it sounds like using HTTPS and x.509 certs would allow many of these automatic trust establishment systems to be implemented on top, allowing flexible policy configuration, which seems to be important to several people in this thread of discussion.

I think using JSON would be ok but like it's been said, you either have to serialize your binary data into some text format like base64/UUencode or represent it as an integer array, both of which are inefficient.. probably cancelling out any benefit of using JSON in the first place :)

Maybe there is no need for binary data for alias resolution though.. I imagine it would be as simple as submitting a name to resolve, and giving back a base58 address string, perhaps along with a textual comment or other extra, information data.

Being strict or lax or anything else is not really a concern for alias resolution - establishing trust is an administrative issue with a lot of different solutions and not every site or application requires trust.  HTTPS and mutual authentication may be desirable for general cases, however HTTP should work just as well if trust is established another way and thus SSL/TLS is not a requirement for the HTTP exchange to work.  As an example use case, I may be using IPsec or any number of other systems external to bitcoin and alias resolution itself.

Laszlo



On Dec 19, 2011, at 4:35 PM, Luke-Jr wrote:

> 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 comes pre-installed for me in my browser.
> 
> Accepted CAs is/should be a property of your *operating system*, not any 
> particular software. Anyhow, restricting this further just makes it even more 
> unusable. Already there is only 1 or 2 CAs that will provide a gratis 
> certificate for personal/small users. If you only allow high-class CAs, I 
> imagine that will restrict "no key in the URI" aliases to those who will fork 
> over a lot of money.
> 
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for 
> developers. It will provide a great way to learn Windows Azure and what it 
> provides. You can attend the event by watching it streamed LIVE online.  
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Jordan Mack]

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 languages. The 
widely adopted cURL library does not support multipart response parsing 
at all.

JSON is widely adopted, human readable, and has parsing libraries 
available for every major language. There is a bit of additional bloat, 
but I believe it is warranted in this case because of the convenience 
and ease it brings to developers.

If the idea is to "KISS", and provide a method that is both quick and 
easy to implement for the average developer, then JSON is a stand out 
option. Using HTTP for the data interchange will make things difficult 
for a lot of developers if multipart responses are used. JSON will be 
greeted with open arms.



On 12/19/2011 9:09 AM, slush wrote:
> 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 it's another story).

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

[Luke-Jr]

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?

Sure, I meant HTTP as the underlying protocol.
TLS/SSL should of course be required in some form.

> I thought that JSON support was fairly common these days. I personally
> prefer XML in most cases, but since JSON is already used with the RPC,
> it seemed like a natural fit here. 

JSON-RPC won't go on forever. In any case, bitcoind's use of JSON-RPC is 
exactly why I (and many other developers) have come to the realization how 
poorly supported JSON really is. Most of the common languages do have a 
library, but almost all of them have one issue or another (particularly around 
the very undefined Number type).

XML shares the same binary-data problem as JSON, too.
As slush mentioned, no additional serialization is necessary anyway.

> Binary data can be base64 encoded, although I'm not sure why you would need
> to send back binary in an alias response.

Because computers work with binary. I don't think anyone wants to implement a 
fully functional script assembler just to send funds.

> What exactly do you mean by "custom output script"?

This suggests you need to learn more about how Bitcoin works ;)
https://en.bitcoin.it/wiki/Script

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

[slush]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

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 parts). I don't see reason why we need some extra payload
yet.

slush

On Mon, Dec 19, 2011 at 7:13 PM, Jordan Mack <jordanmack@parhelic.com>wrote:

> If the idea is to "KISS", and provide a method that is both quick and
> easy to implement for the average developer, then JSON is a stand out
> option. Using HTTP for the data interchange will make things difficult
> for a lot of developers if multipart responses are used. JSON will be
> greeted with open arms.
>
>

[-- Attachment #2: Type: text/html, Size: 1124 bytes --]

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

[Jorge Timón]

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?

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

[Jordan Mack]

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 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. I would hope that support would not be dropped, even if it 
only remains as a secondary protocol with limited capability. Most high 
level developers are only going to use it for basic functions anyhow.



On 12/19/2011 10:15 AM, Luke-Jr wrote:
> Because computers work with binary. I don't think anyone wants to implement a
> fully functional script assembler just to send funds.
>
> JSON-RPC won't go on forever. In any case, bitcoind's use of JSON-RPC is
> exactly why I (and many other developers) have come to the realization how
> poorly supported JSON really is. Most of the common languages do have a
> library, but almost all of them have one issue or another (particularly around
> the very undefined Number type).

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

[Luke-Jr]

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'.

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

[Jordan Mack]

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. Is it really going to stay that simple 
for long? I would personally much just have a serialized response 
upfront, rather than having to worry about backward compatibility in the 
future.

On 12/19/2011 10:17 AM, slush wrote:
> 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 parts). I don't see reason why we need some extra
> payload yet.

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

[Jordan Mack]

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 module because that's all MIME was originally 
intended for. It's now grown beyond that now, but you will find the MIME 
functions still live in the e-mail libraries. When dealing with raw MIME 
encoded data, e-mail is still the most common case.


On 12/19/2011 11:16 AM, Luke-Jr wrote:
> MIME has been around much longer, and should have sufficient support in every
> language by now. For some reason, Python calls the module 'email'.

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

[Jordan Mack]

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 simple enough for developers?

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

[Stefan Thomas]

>> 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 domains first, but they want to profit and 
therefore are willing to sell them for whatever price they can get. Just 
like the trading of any other limited resource, this process sounds like 
somebody is getting rich for nothing, but it does tend to put the 
limited resources to good use as people who waste good domains can't 
afford them in the long run. The problem with Firstbits is that the 
names already grabbed have fixed private keys that are known by their 
originators. That makes the names untradable. This may be fixable with 
split keys, but a lot of "good" 1firstbits are already made useless in 
this way.

Names in Namecoin can be transferred/traded securely, strong 
cryptography is built in and it shares mining without bloating the 
Bitcoin block chain. I see it as a decentralized DNS alternative at a 
time when domain seizures are on the rise, even absent any court order.

So I would use one of the DNS-based solutions that Amir suggested and 
simply require standard-compliant clients to be able to look up .bit 
(i.e. Namecoin) domains as well. That way we have a pragmatic solution, 
but one that also provides security and true decentralization for the 
more paranoid of our users.


On 12/13/2011 12:41 AM, Luke-Jr wrote:
> 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...
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

[Matt Corallo]

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 in the case of green
> addresses's POS instant payments.
Firstbits isn't acceptable for anything.  As Amir originally pointed
out, it doesn't scale well and worst of all it fills the blockchain with
a ton of crap to get 1 satoshi at an address so that it is
"registered".  
> 
> Would it be too strange to use namecoin?
> Some devices may need to rely on block exploring servers, but it is
> the easiest decentralized solution that comes to mind.
Firstbits is unacceptable because it causes unnecessary harm to each
Bitcoin node.  However, if one were to use a chain specifically crafted
for such a purpose isn't terrible.  That said, it still doesn't scale
well and if it becomes popular virtually every implementation would have
to rely on trusted servers at which point you are better off going back
to an HTTPS/DNSSEC-based implementation

Matt

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

[Luke-Jr]

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

[Will]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

Are there any PGP key servers that support EC key pairs?  OpenPGP Spec
RFC2440 defines key types for EC, just not sure if they were ever
implemented on the keyserver side.  Could even have a similar 'web of
trust' using private keys to sign people's identities similar to PGP.

Will

On 12 December 2011 23:16, Zell Faze <zellfaze@yahoo.com> wrote:

> I agree with Luke-Jr.  We need to try to find a decentralized solution if
> we are going to implement BIP 15.  Bitcoin needs to remain decentralized in
> every aspect of the protocol or we lose its greatest strength.
>
> I feel like the 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 <luke@dashjr.org> wrote:
>
> > From: Luke-Jr <luke@dashjr.org>
> > Subject: Re: [Bitcoin-development] [BIP 15] Aliases
> > To: bitcoin-development@lists.sourceforge.net, "Amir Taaki" <
> zgenjix@yahoo.com>
> > Date: Monday, December 12, 2011, 5:32 PM
> > 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.
>
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2760 bytes --]

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

[Jorge Timón]

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 in the case of green
addresses's POS instant payments.

Would it be too strange to use namecoin?
Some devices may need to rely on block exploring servers, but it is
the easiest decentralized solution that comes to mind.


2011/12/13, Zell Faze <zellfaze@yahoo.com>:
> I agree with Luke-Jr.  We need to try to find a decentralized solution if we
> are going to implement BIP 15.  Bitcoin needs to remain decentralized in
> every aspect of the protocol or we lose its greatest strength.
>
> I feel like the 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 <luke@dashjr.org> wrote:
>
>> From: Luke-Jr <luke@dashjr.org>
>> Subject: Re: [Bitcoin-development] [BIP 15] Aliases
>> To: bitcoin-development@lists.sourceforge.net, "Amir Taaki"
>> <zgenjix@yahoo.com>
>> Date: Monday, December 12, 2011, 5:32 PM
>> 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.
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>


-- 
Jorge Timón

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

[Zell Faze]

I agree with Luke-Jr.  We need to try to find a decentralized solution if we are going to implement BIP 15.  Bitcoin needs to remain decentralized in every aspect of the protocol or we lose its greatest strength.

I feel like the 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 <luke@dashjr.org> wrote:

> From: Luke-Jr <luke@dashjr.org>
> Subject: Re: [Bitcoin-development] [BIP 15] Aliases
> To: bitcoin-development@lists.sourceforge.net, "Amir Taaki" <zgenjix@yahoo.com>
> Date: Monday, December 12, 2011, 5:32 PM
> 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.