Bitcoin Forum

It's my opinion that exposing a SHA256 hash to the general public is bad usability. People would much rather publish a friendly address in a format that can easily be dictated over the phone, written down or memorized, similar to the way PayPal/Skrill/Neteller work, where an email address is the identity of the account holder. They would also like to include private payment details with each transaction, such as invoice numbers, and have the option of easily providing a refund when they desire.

Additionally, publishing a single base58 hash reduces privacy because it can help trace related payments to that address. A political candidate might not want to disclose the total amount of donations received. As a donor, I wouldn't want my friend and business partners to find out that some of the money they sent me ended up in a well known collection box. Since ECDSA keys are cheap, maximum privacy is achieved when each real world transaction has it's own unique address, and they are not aggregated in a master key, but rather spent individually by the recipient.

Combining the two requirements, I am proposing a distributed online protocol that resolves friendly names to base58 hashes, ensuring at the same time that each transaction has it's own unique address. The protocol works using a trusted 3rd party that acts as an always-on relay point on behalf of the user, similar to an email server. The payload (money / private keys) is not under the server's control, only the public address list and their mapping to a friendly address. Privacy focused individuals who don't want to disclose even the transaction list to a 3rd party can host their own relay server.

A conceptual workflow would go something like this:

• Alice creates a large number of private keys and stores them offline, keeping only the public corresponding public addresses; for space concerns the private keys could be generated based on a single seed that is easy to store
• Alice creates an account on the relay server, establishes an authentication token, and assigns herself a friendly address: alice@example.com
• Using her authentication token, Alice's client periodically contacts the relay server and queries for recent activity related to her account ("activity" will be defined bellow); if the base58 address pool is depleted, for example on first connect, the client uploads fresh keys generated in step 1
• Alice publishes her friendly address to friends, family, business partners, Bob and Mallory
• When Bob desires to make a payment to Alice, he enters Alice's friendly address in his client, the amount to send, some description and any other application-specific data
• Bob's client scans it's wallet and discovers it can match Bob's entered amount exactly by spending three private keys it owns
• Bob's client parses the address into a server and user part, contacts the relay server via DNS/HTTP and POSTs a request for a transaction. For example the post address and data could go something like this:

• The relay server extracts three of Alice's base58 hashes from the pool of available hashes, records them in the database of used hashes along with the information posted by Bob, and returns the addresses to Bob's client
  
• Bob's client makes transactions as usual to the addresses it obtained, and publishes them in the blockchain
• On the next refresh, Alice's client will contact the server and find what addresses where used, and the associated payer meta information; if the transactions exists in the blockchain, then Alice will be able to see a user friendly entry in her incoming log, that maps all 3 sends to a single entry and shows the associated payer addr and meta information, just like a regular e-wallet

For maximum compatibility and easy deployment, the server works on top of DNS and HTTP, but it could be also deployed over Namecoin/Tor. It's also coin agnostic and could be implemented for any other currency besides Bitcoin. If Bob does not want to disclose his IP address to Alice's relay server, he can resolve her friendly name via Tor. It's also optional for Bob to disclose or not his own friendly address under the "payer" POST field.

The system has the advantage that Mallory cannot find anything by queering the relay server. She will obtain a unique and random string that is never used in the blockchain and reveals no information about Alice. The only way to find out more is to send money to Alice and trance them further. But if Alice employs the same protocol when spending the money received from Mallory, then Mallory cannot find anything about Alice's other partners.

The protocol offers the convenience of systems such as PayPal without spamming the blockchain with metadata (payment details); metadata is kept private, known only by the Bob, Alice and the server, and it can also be encrypted to exclude the server. It allows easy refund if the payer chose to disclose a return address; without the payer's friendly address, refunds to a base58 addresses are a bad ideea since there is no guarantee the sender has kept the corresponding private key.

I'm not necessarily keen to have friendly addresses formatted like an email especially since this address would not have email capabilities; The friendly address syntax is yet to be defined and there are a myriad alternatives: alice$example.com, alice^example.com, btc:example.com~alice etc. I've also skimmed over the low level details for server communication since it's too early to lay down the implementation details. Also, DoS by emptying the pool of available hashes should be prevented.


Later edit, April 03, 2012:
The naive scheme presented above is very vulnerable to a man-in-the middle attack. Alice must trust the relay server, the DNS system, and the SSL provider of example.com; they could conspire to hand out fake keys that are not owned by Alice, seize all of Alice's funds, and log all payment details.

But the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?

It could go something like this:
- Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it
- Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),
- The address is unspendable since it's not a hash of a public key; only Alice and friends know this, and it cannot be detected
- Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address
- Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction
- Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address
- Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap
- He finds the single unspent transaction made by Alice, thus obtains her public key
- He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:
   - The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES
   - Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money

Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data.

What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.

What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.

There seem to be at least two similar but-incompatible schemes for doing what I proposed above as the "naive approach". Here I was thinking I am being original :):

• https://en.bitcoin.it/wiki/BIP_0015
• http://ecdsa.org/bitcoin_URIs.html

Judging by discussion in the mailing list (http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html), BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.
If we can define a good way to publish Alice's  pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.

Interesting proposal. But it requires something central, and I don't see users running their own directory servers for this.

I like that very much..very interesting..centrality is not that big problem here as it is imho just an script which worsk on a server for a predefined group of users..

If they want the added capabilitys they will use it..if not they won`t..

as long it is opensource and easy to run :)


Please start a fundraiser :) I really like that !

AND please converge it with http://btcrelay.com/ (http://btcrelay.com/)

or add teh same functionality :)

There is already some centralization, online wallets could offer this option to their users, ex. alice^mtgox.com. If I have a MtGox account I would probably welcome the option.
Also, more and more people will connect using lightweight clients, which requires a good deal of trust in the server they are using. So it's a good opportunity to piggyback the friendly address sync when connecting to the lightweight server, with minimal security implications for the users since they already trust that server.

Or they could just send the keys to her email adress. She sweeps these keys with the client as in the bitcoin "cointainer" discussion.
Now it will be much harder to know how much she has collected.

I like this idea very much - it's exactly the kind of evolution necessary for stepping away from seeing base58 strings as addresses (a word that implies some form of permanent connection to an identity).

I've proposed a more concrete proposal some time ago in the same light, a bit more specifically aimed for online merchants. You can read about it here (https://gist.github.com/1237788).

I see the point of this but I'm still weary of centralising a P2P solution. I think firstbits and btc.co are both valid ideas to resolve this.

I guess my main concern would be to make sure that we still have the option to use all and either way for payments. If we were to do something along the lines of alice^mtgox.com as mentioned above I would prefer something along the lines of OpenID instead of a specific retailer. An OpenID-type implementation that allowed me to create aliases bound to different base58 address.

Having said all of the above we can see that QR codes are becoming more common both in desktop as well as mobile wallets. I truly believe QR or maybe other types of barcodes will prove to be the solution in the long term, since they are designed to be easy and fast to read by a machine and can be read even if the resolution is bad or small parts have been damaged.

But in most cases, there is no centrlalization. You are already communicating with the receiver via his website in many cases. There is no loss of privacy by also using this channel for requesting a payment address.

Do you consider e-mail a problem because it is centralized? You can switch to another mail provider if you don't like it. You could even run your own if you're paranoid. It's exactly the same here.

I think this is an excellent idea. Its feeding into what people already know.

foo@bar.com for an email and you can have foo~bar.com for payments or something similar.

from a ux perspective it will greatly improve the chances of outsiders using the system in my opinion.

since more and more protocols like XMPP adopt the "email standard" of user@domain that form would seem the most suitable.

making a client suite available that included name resolution (and registration) for bitcoin addresses via namecoin and/or DIANNA (and some local or cloud server daemon) along with a standard bitcoin client distribution could be interesting.

I like this idea - and think that you *should* use email addresses both for simplicity and so that PGP could be tied into the system (for encrypting the receipt info).

Bank account are long numbers, not much different from bitcoin address.

Email、URL、Social media etc can simplify bitcoin address.

This should be application level, not bitcoin network level.

I think this is a great idea. This would make bitcoin like PayPal, except actually peer-to-peer.

What I'm wondering is whether two people need to be using the same relay server to send bitcoins between each other, and if not, how different relay servers communicate.

Would it be necessary to create a centralized Friendly Name System (FNS), like the DNS, for mapping friendly names to relay servers? If so, I think it would be better to just use namecoin.

Never mind. The relay server can of course be specified by the domain name that comes after @, so the existing DNS would resolve the friendly name to a relay server.

as so much else it is possible to realize this decentralized via namecoin. see aliases draft.

one problem is that a typo could be fatal. imho it is necessary to combine it with a check character or two

Interesting idea.  watching.

Bump. I think this would have more significance to bitcoin than the browser had to the internet.

I think companies with a lot invested in bitcoin, like Mtgox, would benefit from funding a client that works with this protocol.

This would be a good way to help users use more complex transaction types, vastly improving the experience and usage of the network.

I think using aliases with namecoin has been the cleanest implementation i've seen.  Sadly, the page doesn't load now. http://ecdsa.org/bitcoin-alias/

How do you envision it helping people use more complex transaction types?


If I'm not mistaken, the namecoin alias would publicize your bitcoin addresses in the namecoin block-chain. This otoh would give you complete privacy, as long as you can trust the relay server to not disclose your ownership over the bitcoin addresses.

does for me: """

This page allows you to query Bitcoin aliases stored in the Namecoin blockchain.

Example:
Alias: thomasv
Namecoin key: a/thomasv
Namecoin record: http://explorer.dot-bit.org/n/37310
Alias URL: http://ecdsa.org/bitcoin-alias/?handle=thomasv

"""

I have put this project on hold until DIANNA is available

Actually click one of the links...

Hey, I've just got an idea: the sender and the recipient already have an unforgeable channel at their disposal: the blockchain. Why not use this channel to establish a trusted public key, thus widely reducing the middle man's (relay server) maneuvering capabilities ?

It could go something like this:
- Alice wants the friendly name alice@example.com, and the owners of example.com allow her to register it
- Alice hashes the friendly name with RIPEMD160, and constructs a globally unique, unspendable bitcoin address: base58(ripemd160("alice@example.com") +checksum),
- The address is unspendable since it's not a hash of public key; only Alice and friends know this, and it cannot be detected
- Alice creates a ECDSA keypair, and uses it to sign a transfer of a few bitcents to the unspendable address
- Alice has just published ownership of the "alice@example.com" friendly name, with none of the Bitcoin participants seeing anything other than a regular Bitcoin transaction
- Bob wants to send Alice some coins; he repeats the ripmend160 hashing and gets to the unspendable address
- Bob scans his blockchain for spends to this address; it's expected the blockchain is properly indexed for such scans to be cheap
- He finds the single unspent transaction made by Alice, thus obtains her public key
- He contacts the relay server @example.com, and uses the Alice's ECDSA public key to cut the middle man out of the loop:
   - The transaction metadata is passed to the relay server as a binary blob, encrypted for Alices's private key using ECIES
   - Each address previously uploaded by Alice to the relay server is signed, so Bob can have full confidence Alice gets the money

Using this scheme, Alice maintains good privacy (she publishes a hashed version of her address), and does not have to trust the relay server with her money or personal data. (In the naive scheme presented in the first post, a malicious or hacker @example.com server could have seized all of Alice's funds, and logged all payment details)

What happens if Mallory finds Alice's friendly address, and broadcasts her own transaction to base58(ripemd160("alice@example.com") +checksum), with her own public key ? Bob should accept only the first valid transaction, and ignore later ones. This has the disadvantage that if Alice looses her initial keypair, "alice@example.com" is unusable for eternity. A more complex scheme could be devised where updates, revokes and reuse can be enabled.

What about address colisions ? RIPEMD160 80 bits of collision resistance should offer sufficient protection against accidental collisions; for deliberate collisions, we are exactly in the previous situations and the protocol should prevent it.

Would squatting, where someone creates and claims ownership over thousands of bitcoin addresses that are RIPEMD160 hashes of desirable friendly names, be a potential problem with this?

I do not believe so, since the scheme is used only for sharing a public key, not resolving it to a bitcoin address. The squatter still needs to control the example.com domain to have functional addresses. So the squatting issue is implicitly solved by relying on the DNS system.

Presumably, the user accounts of a certain desirable provider could be squatted, i.e someone would publish keys for a@gmail.com, b@gmail.com etc. That would not be a way to reserve them (you still need collaboration from @gmail.com), but it would be a way to deny them from regular users, thus creating a DoS against gmail.com relay server and spamming the chain.

Maybe this can be averted by designing a smarter way to select the correct public key when multiple initial transactions are detected to the same email hash. If the initial transaction must be of at least 0.05 BTC, then it becomes very expensive for the attacker to do this DoS; but who knows how much a coin will be worth tomorrow ? Maybe registering an address for 0.05BTC will be too expensive even for normal users :)

Perhaps one solution would be for Alice, when registering the user account, to request a digital signature of "alice@example.com" from example.com, where example.com uses its PKI private key to sign it, and then Alice sends a few bitcents/satoshis/etc to base58(ripemd160(example.com-signature("alice@example.com") +checksum).

When Bob wants to send a payment to Alice, he requests a digital signature of alice@example.com from example.com, creates a base58 ripemd160 hash of it+checksum, then scans the block-chain for the unspent transaction to it.

As long as the example.com relay server is careful about not giving out signatures of possible user accounts before user accounts are created, it would prevent DoS attacks against it.

I'm not sure I've got this part right:

If I need to go to example.com before I can find Alice's key, doesn't that imply that a hacked or malicious example.com could redirect me to a different signature of "alice@example.com", thus circumventing the protection ?The point of Alice publishing a plain hash was that any user, knowing only her friendly address, can obtain her public key from the blockchain, thus killing any man in the middle lurking at example.com

BTW, There seem to be at least two similar but-incompatible schemes for doing what I proposed in the first post. Here I was thinking I am being original :):

• https://en.bitcoin.it/wiki/BIP_0015
• http://ecdsa.org/bitcoin_URIs.html

Judging by discussion in the mailing list (http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00419.html), BIP15 was deferred because it lacked a clear way to authenticate the relay (alias) server. HTTPS is not enough.
The electrum proposal tries to do some authentication, using an undefined "trusted authority". Not very useful.
If we can define a good way to publish Alice's  pubkey into the blockchain and use it further to authenticate and encrypt the exchange, we are making progress towards a working protocol. Coin destruction and spamming should be kept to a minimum or zero.

You're right, it wouldn't work. I was wrongly assuming that sites can only have one SSL certificate issued to them by a CA at one time, and that any one could query the CAs for all of the expired/revoked certificates of a particular site. That's not how it works. A site can have multiple valid certificates, and you can only get information on a certificate that they present to you.

With namecoin I believe it would be possible though. Here's how it would work:

* A relay server registers example.bit in the namecoin block-chain.
* When Alice is registering the alice@example.bit user account, the relay server creates a digital signature for "alice@example.bit" using the privkey portion of the namecoin ECDSA key pair that the example.bit domain is registered at, sends it to Alice through a secure channel, and requires her to create a bitcoin transaction with two outputs, one sending a bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum), and one sending a bitcent/satoshi/etc to base58(ripemd160("alice@example.bit" +checksum), in order to complete registration of her user account
* When Bob wants to make a payment to alice@example.bit, he scans the bitcoin block-chain for the earliest spend to the base58(ripemd160("alice@example.bit" +checksum) address. The receiving address of the other output in the transaction would be the base58(ripemd160(example.com-signature("alice@example.bit") +checksum)
* He asks the owner of example.bit for the pubkey that hashes to the namecoin address that example.bit was registered at at the time that the spend to the base58(ripemd160("alice@example.bit" +checksum) address took place, and a signature of "alice@example.bit" made by the pubkey's corresponding privkey.
* He verifies that the pubkey provided by example.bit hashes to the namecoin address that example.bit was registered at at the time of the spend, and verifies that the signature was made by the privkey that corresponds to that public key.
* If Bob has verified that the owners of example.bit have given him the correct pubkey and signature, but the receiving address of the other output doesn't match base58(ripemd160(example.com-signature("alice@example.bit") +checksum), then Bob ignores that spend and scans the bitcoin blockchain for the next earliest spend to the base58(ripemd160("alice@example.bit" +checksum) address. He continues the process until he finds a spend where the receiving address of the other output matches the hash of the signature of "alice@example.bit" made by the privkey corresponding to the pubkey that hashes to the namecoin address that example.bit was registered at at the time of the spend.

This would prevent an attacker from making any user accounts of a particular domain unavailable without the cooperation of the domain owner, while not allowing a MITM attack by the domain owner.


Your scheme is original in requiring every input to a base58 hash be spent to a different and never used base58 hash, which would prevent an outsider from deducing any information about the participants of transactions.

what a petty

Is there a service like this for pgp public keys? http://dot-bit.org/Personal_Namespace

FYI, there was a lot more discussion than is seen in that link, over a 100 messages on the mailing list. You should be able to find everything here (http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development&max_rows=25&style=ultimate&viewmonth=201112).

I've put the friendly address proposal in the bitcoin wiki:

https://en.bitcoin.it/wiki/Friendly_addresses_with_enhanced_privacy

I really think this would improve bitcoin's usability by an order of magnitude. It could be the difference between 50 thousand people using bitcoin, and 5 billion.

I've also included an improved version of the proposal I provided above to publish public keys in the Namecoin block chain:

UnSpammable Publication of Friendly Address Owners' Public Keys

• A relay server registers example.bit in the namecoin block-chain.
• The relay server creates a base58(ripemd160("example.bit") +checksum)) hash, and sends a namecoin-bitcent/satoshi/etc to it from the namecoin address that example.bit is registered with at the time, thus publishing the pubkey of example.bit, which will be used to verify its signatures
• When Alice is registering alice@example.bit, the relay server creates a digital signature for "alice@example.bit" using the privkey of the example.bit pubkey published in the namecoin block-chain, and sends it to Alice through a secure channel
• Alice creates a bitcoin transaction, sending one bitcent/satoshi/etc to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), thus publishing her public key.
• When Bob wants to make a payment to alice@example.bit, he scans the namecoin block-chain for the earliest spend to base58(ripemd160("example.bit") +checksum))
• He checks if the spend came from the namecoin address that example.bit was registered at at the time of the spend, and if it didn't, he looks for the next earliest spend, and does this until he finds a spend to base58(ripemd160("example.bit") +checksum)) that came from example.bit's namecoin address
• Once Bob finds the spend, he considers the pubkey used for the spend as example.bit's official pubkey for signature verification
• Bob asks example.bit for a digital signature of alice@example.bit, and uses example.bit's published pubkey to verify the signature was made by example.bit's official privkey
• Bob scans the bitcoin block-chain for the earliest spend to base58(ripemd160(example.bit-signature("alice@example.bit") +checksum)), and obtains Alice's pubkey
• There is no way the owners of example.bit could have cheated and given Bob a different signature for alice@example.bit than they gave to Alice when she published her pubkey, because every namecoin domain can only ever have one official pubkey, that can never be altered

The protocol having to rely on Namecoin is a disadvantage imo, so if we could find a way to publish Alice's public key without Namecoin, it would be an improvement.

or:
namecoind name_send gonzo 1  ;D

seriously, why not simply:
get bitcoin address for a/gonzo via namecoind
send bitcoins to address

easiest will still be having the good old homepage and have the payment address there in the contact details.
just like nowadays in europe all companies have their bank account in the contact details.