Resolvers of short bitcoin addresses - alter. to BIP 0015 HTTPS Web ServiceNote: if you really do not like this idea and you have not read BIP 0015, or you want to argue with Namecoin, please, read this full thread before commenting.
IntroductionBitcoin addresses are not good-looking for average internet user - they are too long and too scary.
The ideaCreate standardized protocol for pairing, validating and resolving "short addresses" to actual bitcoin addresses between
bitcoin (un)related parties with person identifiers (email, nickname, subdomain, ...) and
bitcoin related software.
This would be service protocol (extension), not part of the core Bitcoin protocol.The idea is similar to the BIP 0015 HTTPS Web Service (Namecoin ID). See BIP 0015 - HTTPS Web Service
https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki#HTTPS_Web_ServiceSee my opinion bellow why the BIP 0015 HTTPS Web Service (Namecoin ID) is not better at the current time.
Use cases and my idea of implementation. For long explanation, scroll down, please.https://i.imgur.com/edTly63.pngSee
Long explanation bellow for more info. It is possible that name
btc-resolver and other things are not optimal. Please, post in discussion.
What about Namecoins, Namecoin ID?0. Not Namecoin ID, but
HTTPS Web Service is similar to my idea, indeed. See BIP:
https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki#HTTPS_Web_Service1. It is not implemented, see BIP in previous line.
2. It is hard and dangerous to implement, it will take time. My solution could be implemented in couple of hours in case of trusted resolver and couple of weeks in case of bitcoin wallets. Moreover, the functionality can be rolled back without breaking/modifying Bitcoin protocol.
This [BIP 0015] is a big modification to the protocol that is not easily changed in the future and has big ramifications. There is impetus in getting it correct the first time. Aliases have to be robust and secure.
3. It will probably not provide all the functions which my idea can provide (like usage of non-email identifier).
4. It is just less powerful for implementing my goal/use case - compare
Namecoin ID,
HTTPS Web Service and implementation of my idea.
Fraud concerns - the resolver will steal my bitcoins...It can not. The resolver do not have the private keys, just bitcoin addresses with your short names.
Fraud concerns - the resolver will respond with its bitcoin address, not my address...1. The trusted resolver wants to stay trusted. You really should use the most trusted resolvers. (for most users are suitable: Google, Microsoft, Apple, Facebook - they trust them (facebook ads, gmail ads, google wallet, paid services from microsoft, ...) already and it seems to be OK). Anyway, you can use your favorite hidden-service email provider if you want.
2. The trusted resolver do not know BTC amount which you are going to send to bitcoin address paired "short address" before you send - no info at all that you are going to send large amount or small amount.
3. The trusted resolver resolves short addresses paired *only* with identifiers
in its service/domain.
4. You can still use good old BTC addresses for valuable transactions (>= 500 USD) - the wallet should even force that. This is service for average user and everyday-use payments.
Long explanationWhat do companies like Google, Microsoft, Apple, Blockchain.info (and others) have?
a1. They have trust. And want to have trust.
a2. They have user identifiers and many users. google.com, microsoft.com (outlook.com), apple.com, blockchain.info are known domains and almost everyone has gmail or yahoo account.
a3. They have money. With money, they can achieve to be secure and trusted.
Examples[email protected]/donations5
is resolved to 1J3meoXcKEAe4E6XiHB4GMFDQPGuqgkefT
[email protected]/a5p8gfKhSw
is resolved to 1FuFjXtg2rdKLs6JjNPpN3pUJnW1JXwx2G
[email protected]/dontions
is not validIn the examples,
[email protected] is memorable person identity identifier. The part after slash / is internal shortcut in Google service for some real bitcoin address string.
Google can provide service that confirms or denies that Gmail account satoshi.nakamoto has shortcut "firstAddres1" and that this shortcut is still valid (links to actual bitcoin address string) - if true, Google just responds with the actual bitcoin address string.
People who knows that Satoshi Nakamoto has this email address will or will not trust Google that provides correct confirmation and user's actual bitcoin address string.
Solutions based on Namecoin may be better. But currently the problems with Namecoin are I had to use command line when I play with it last time and average users do not know what private key is and what to not do with it - there is no simple solution or service which could solve the address problem.
User-friendly scheme in general: trusted_service_user_identifier/btc_addr_shortcut
b1. trusted_service_user_identifier can contain standard characters including slash /
b2. tc_addr_shortcut can contain standard characters excluding slash /
- The last slash / in the schema determines btc_addr_shortcut
- Slash / is my favorite delimeter, because it is simple to remember. At symbol @ woluld be confusing (see examples below), colon : may be fine, but still not as good as slash /.
Examples 2[email protected]/donations5 - email example, gmail.com provides confirmations
nakamoto.nonamebtccompany.com/personalAddr - subdomain example, nonamebtccompany.com provides confirmations
facebook.com/satoshi.moto/donations3 - user profile example, facebook.com provides confirmations
Wallet featuresDesktop or online wallets could implement feature to create short addresses automatically via trusted service provider API. No need to manually map btc addresses to short forms in trusted service provider account in browser.
Final use case - Wallet (example uses Gmail for simplicity)
1. I link my gmail account
[email protected] to my Bitcoin Wallet software (desktop or online)
2. I create new bitcoin address
1PV6ZFqZ5eKit2chSTQyt2rPcgeE67ti4W (want to receive payment) in the Wallet with label "
dinner3"
3. The Wallet sends request to Gmail domain via
HTTPS protocol - the domain is extracted from
[email protected] information and the standardized subdomain
btc-resolver is preppended, so, the final subdomain is
btc-resolver.gmail.com. Request parameters are: my email account, my new btc address and new label "
dinner3".
4. Gmail responds with status. If the status is good, the Wallet just renames the btc address/hash (in gui) to "
[email protected]/dinner3." If something went wrong (ex. Gmail account does not exists), nothing is renamed.
5. I send my newly created short btc "address"
[email protected]/dinner3 to my friend.
6. My friend clicks "Send btc" in his Wallet software (different than my Walllet) and types in
[email protected]/dinner3.
7. His Wallet recognizes gmail.com domain from my short btc "address", prepends
btc-resolver subdomain and sends
HTTPS request "Gimme actual btc address from this short address
[email protected]/dinner3".
8. Gmail server checks if there is
[email protected] account in its database and if the
dinner3 name links to actual btc address.
9. If true, it responds back with the actual btc address
1PV6ZFqZ5eKit2chSTQyt2rPcgeE67ti4W in json, error in json otherwise.
10. Friend's wallet sends bitcoin to resolved address. The user never sees the scary bitcoin address.
Of course, I can use my facebook-based short address
facebook.com/miso/dinner3 if Facebook supports this thing.
c1.
HTTPS because it is secure and simple to work with. Every php/javascript app which works with short addresses should be able to send request to resolve short address securely.
c2. And with https, there must be some rule about subdomain. Just like there was unwritten rule about www or ftp "default" subdomain in the past - if someone wanted to access ftp server with unknown IP address, he should try "ftp" subdomain.
URI scheme: btcs:
><&short=>
- btcs as bitcoin short
- maybe btcn as bitcoin name could be reserved for something similar with Namecoins in the future
This idea needs
1. Brainstorming
2. Final form/standardization
3. Big player, like blockchain.info or Bitcoin-qt developers
Benefits
Benefits for users and Bitcoin in general are clear - more usability in bitcoin, more people paying with bitcoin, ...
Benefits for trusted online wallets which implement this and popular non-bitcoin related companies (like Google)
1. Earning from ads which are displayed to user while managing/mapping btc addresses to short forms.
2. Name of the service provider in public short bitcoin address (ex. [email protected]/sendmesomemoney).
3. More...
Questions, improvements, discussion, please