Topic: Proposal: friendly addresses with enhanced privacy (Read 3636 times)

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.

or:
namecoind name_send gonzo 1 

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

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 [email protected], the relay server creates a digital signature for "[email protected]" 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("[email protected]") +checksum)), thus publishing her public key.
• When Bob wants to make a payment to [email protected], 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 [email protected], 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("[email protected]") +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 [email protected] 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.

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.

what a petty

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

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 [email protected] user account, the relay server creates a digital signature for "[email protected]" 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("[email protected]") +checksum), and one sending a bitcent/satoshi/etc to base58(ripemd160("[email protected]" +checksum), in order to complete registration of her user account
* When Bob wants to make a payment to [email protected], he scans the bitcoin block-chain for the earliest spend to the base58(ripemd160("[email protected]" +checksum) address. The receiving address of the other output in the transaction would be the base58(ripemd160(example.com-signature("[email protected]") +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("[email protected]" +checksum) address took place, and a signature of "[email protected]" 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("[email protected]") +checksum), then Bob ignores that spend and scans the bitcoin blockchain for the next earliest spend to the base58(ripemd160("[email protected]" +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 "[email protected]" 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.

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 "[email protected]", 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, 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.

Perhaps one solution would be for Alice, when registering the user account, to request a digital signature of "[email protected]" 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("[email protected]") +checksum).

When Bob wants to send a payment to Alice, he requests a digital signature of [email protected] 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 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 [email protected], [email protected] 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

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?

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 [email protected], 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("[email protected]") +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 "[email protected]" 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("[email protected]") +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, "[email protected]" 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.

Actually click one of the links...

I have put this project on hold until DIANNA is available

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

"""

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.

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/

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

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.

Interesting idea.  watching.

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