Bitcoin Forum
December 03, 2016, 01:37:58 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Proposal: friendly addresses with enhanced privacy  (Read 3126 times)
BubbleBoy
Sr. Member
****
Offline Offline

Activity: 322



View Profile
March 29, 2012, 01:38:30 PM
 #1

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:
Code:
POST to: https://example.com/relay_server
URL-encoded data:
user=alice&currency=BTC&amount=500&want_addr=3&description=Paycheck%20December&payer=bob@example.org&meta1=value1&meta2=value2&...
  • 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 Smiley:

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.
1480772278
Hero Member
*
Offline Offline

Posts: 1480772278

View Profile Personal Message (Offline)

Ignore
1480772278
Reply with quote  #2

1480772278
Report to moderator
1480772278
Hero Member
*
Offline Offline

Posts: 1480772278

View Profile Personal Message (Offline)

Ignore
1480772278
Reply with quote  #2

1480772278
Report to moderator
1480772278
Hero Member
*
Offline Offline

Posts: 1480772278

View Profile Personal Message (Offline)

Ignore
1480772278
Reply with quote  #2

1480772278
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
March 29, 2012, 01:50:00 PM
 #2

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

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
ptshamrock
Sr. Member
****
Offline Offline

Activity: 479



View Profile
March 29, 2012, 02:35:00 PM
 #3

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 Smiley


Please start a fundraiser Smiley I really like that !

"Money needs to be depoliticized, and the time has come for the separation of money and state to be accomplished."
ptshamrock
Sr. Member
****
Offline Offline

Activity: 479



View Profile
March 29, 2012, 03:16:43 PM
 #4

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

or add teh same functionality Smiley

"Money needs to be depoliticized, and the time has come for the separation of money and state to be accomplished."
BubbleBoy
Sr. Member
****
Offline Offline

Activity: 322



View Profile
March 29, 2012, 08:51:08 PM
 #5

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.
istar
Hero Member
*****
Offline Offline

Activity: 524


View Profile
March 29, 2012, 10:54:06 PM
 #6

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.

Bitcoins - Because we should not pay to use our money
Pieter Wuille
Legendary
*
Offline Offline

Activity: 1036


View Profile WWW
March 29, 2012, 11:35:46 PM
 #7

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Kaos
Member
**
Offline Offline

Activity: 64



View Profile
March 29, 2012, 11:53:14 PM
 #8

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.
Pieter Wuille
Legendary
*
Offline Offline

Activity: 1036


View Profile WWW
March 30, 2012, 12:07:01 AM
 #9

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.

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.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
MaxSan
Sr. Member
****
Offline Offline

Activity: 368


View Profile
March 30, 2012, 07:21:50 AM
 #10

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.
guruvan
Hero Member
*****
Offline Offline

Activity: 518

ShastaFarEye Prospectors mazaclub & mazacha.in


View Profile WWW
March 30, 2012, 07:39:53 AM
 #11

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.

Mine at the Maza Club! with ShastaFarEye Prospectors! Mazacoin PPS & P2pool mining, and more services coming soon!
Maza Means Money! Check yours at the mazacha.in!

Please contact me  on my  OTC registered GPG (A54E87F2) Key's email address or guruvan@shastafareye.net  and encrypt all correspondence.
CIYAM
Legendary
*
Online Online

Activity: 1820


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 30, 2012, 07:43:00 AM
 #12

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
finway
Hero Member
*****
Offline Offline

Activity: 714


View Profile
March 30, 2012, 07:44:41 AM
 #13

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.


guruvan
Hero Member
*****
Offline Offline

Activity: 518

ShastaFarEye Prospectors mazaclub & mazacha.in


View Profile WWW
March 30, 2012, 07:57:28 AM
 #14

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.



definitely

Mine at the Maza Club! with ShastaFarEye Prospectors! Mazacoin PPS & P2pool mining, and more services coming soon!
Maza Means Money! Check yours at the mazacha.in!

Please contact me  on my  OTC registered GPG (A54E87F2) Key's email address or guruvan@shastafareye.net  and encrypt all correspondence.
amincd
Hero Member
*****
Offline Offline

Activity: 772


View Profile
March 30, 2012, 07:08:03 PM
 #15

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.
phelix
Legendary
*
Offline Offline

Activity: 1680


nmc:id/phelix


View Profile
March 30, 2012, 09:25:14 PM
 #16

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

blockchained.com ■ bitcointalk top posts
RaggedMonk
Sr. Member
****
Offline Offline

Activity: 308



View Profile
March 30, 2012, 10:43:45 PM
 #17

Interesting idea.  watching.
amincd
Hero Member
*****
Offline Offline

Activity: 772


View Profile
April 01, 2012, 05:47:23 PM
 #18

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.

guruvan
Hero Member
*****
Offline Offline

Activity: 518

ShastaFarEye Prospectors mazaclub & mazacha.in


View Profile WWW
April 01, 2012, 06:05:22 PM
 #19

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.

Mine at the Maza Club! with ShastaFarEye Prospectors! Mazacoin PPS & P2pool mining, and more services coming soon!
Maza Means Money! Check yours at the mazacha.in!

Please contact me  on my  OTC registered GPG (A54E87F2) Key's email address or guruvan@shastafareye.net  and encrypt all correspondence.
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
April 01, 2012, 06:14:53 PM
 #20

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/

Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!