Proposal: friendly addresses with enhanced privacy

[amincd]

This would be a good way to help users use more complex transaction types,

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

I think using aliases with namecoin has been the cleanest implementation i've seen.  

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.

[1713483717]

1713483717

[phelix]

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/

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

"""

[ThomasV]

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/

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

[Red Emerald]

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/

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

"""

Actually click one of the links...

[BubbleBoy]

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.

[amincd]

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?

[BubbleBoy]

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

[amincd]

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.

[BubbleBoy]

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

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.

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

[amincd]

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 ?

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.

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 :

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.

[phelix]

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/

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

what a petty

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

[D.H.]

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.

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.

[amincd]

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.

[phelix]

[...]

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 

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

[hamdi]

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.