Resolvers of short bitcoin addresses - alter. to BIP 0015 HTTPS Web Service

[miso]

Resolvers of short bitcoin addresses - alter. to BIP 0015 HTTPS Web Service

Note: 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.

Introduction
Bitcoin addresses are not good-looking for average internet user - they are too long and too scary.

The idea
Create 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_Service
See 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.png
See 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_Service
1. 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 explanation

What 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
satoshi.nakamoto@gmail.com/donations5 is resolved to 1J3meoXcKEAe4E6XiHB4GMFDQPGuqgkefT
satoshi.nakamoto@gmail.com/a5p8gfKhSw is resolved to 1FuFjXtg2rdKLs6JjNPpN3pUJnW1JXwx2G
satoshi.nakamoto@gmail.com/dontions is not valid

In the examples, satoshi.nakamoto@gmail.com 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
satoshi.nakamoto@gmail.com/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 features
Desktop 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 miso@gmail.com 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 miso@gmail.com 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 "miso@gmail.com/dinner3." If something went wrong (ex. Gmail account does not exists), nothing is renamed.

5. I send my newly created short btc "address" miso@gmail.com/dinner3 to my friend.
6. My friend clicks "Send btc" in his Wallet software (different than my Walllet) and types in miso@gmail.com/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 miso@gmail.com/dinner3".
8. Gmail server checks if there is miso@gmail.com 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:<trusted_service_domain><?uid=<user_identifier>><&short=<btc_addr_shortcut>>
- 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. john@gmail.com/sendmesomemoney).
3. More...

Questions, improvements, discussion, please

[1715573566]

1715573566

[1715573566]

1715573566

[1715573566]

1715573566

[1715573566]

1715573566

[trout]

no need for trust. Look up firstbits

[miso]

no need for trust. Look up firstbits

Firstbits solution is not good in general

Firstbits is considered by many, including most (if not all) Bitcoin developers to be a bad idea. This is for a number of reasons:
Blockchain bloat
Most good names have already been snatched up
Vulnerable to confusion
Contradicts design of Bitcoin *
Bitcoin was designed such that addresses should only be used once, for a single transaction. Firstbits, by contrast, encourages people to find and use a single address for multiple transactions.

Source: https://en.bitcoin.it/wiki/Firstbits

* My solution does not have the issue - see the wallet part. The wallet can simply create user defined short address with date and time or sequence number, which is still pretty good memorable, readable and "one address - one transaction" principle is used.

Moreover, firstbits solution is not good enough for average user. Average user wants to link address to his personal identifier, for ex. email address.
Coinbase understand this - you can pay in coinbase to "email address".

If you make transaction worth of 1000 or 10 000 USD, you should use good old bitcoin addresses. But trusted resolver is good for small transactions - 10 USD, 100 USD.

[phelix]

Ever heard of Namecoin IDs?

[miso]

Ever heard of Namecoin IDs?

You mean this? https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki#namecoin-id
This looks more similar to my idea: https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki#https-web-service
For what I read about namecoin-id, I suppose everyone can say "I own your email address". Some validation/confirmation from your email provider is still needed.
From what I read about HTTPS Web Service from that document, it looks nice:

genjix@foo.org
https://foo.org/bitcoin-alias/?handle=genjix

As I mentioned in the first post, solutions based on Namecoin may be better. But they do not work yet. My idea is pretty simple and will just work.
It could be used as temporary solution while the Namecoin solutions are not implemented or used.
Could HTTPS Web Service from that document work just with facebook nickname - without facebook email?
Edit

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.

Source: https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki
My idea is exact opposite. It can not damage the protocol and can be anytime "turned off" and everything will work like nowadays (2014).

[miso]

So I have to trust big companies to do my resolving? What if all the big companies get together and hate me. So everytime someone uses that to send me funds to eat, they give their own address and take my funds?

Its all about the risk.
Merchant "trusts" customer that he will not doublespend. If he does not "trust", customer have to wait ~10/60/n minutes in the shop. It does not matter for most merchants for small amounts (10 USD, 100 USD).
The question is, if average users trust Google / Facebook / Blockchain.info that they do not change the address. Do not forget that:
1. The trusted resolver wants to stay trusted. You really should use the most trusted resolvers.
2. The trusted resolver do not know BTC amount which you are going to send before you send - no info at all that you are going to send large amount.
3. The trusted resolver resolves short addresses paired with identities *only* in its service/domain.
4. You can still use good old BTC addresses for valuable transactions (>= 500 USD) - the wallet should force that.

[miso]

Merchant "trusts" customer that he will not doublespend. If he does not "trust", customer have to wait ~10/60/n minutes in the shop.

If I am a merchant I don't have to trust anyone, that is why bitcoin is a trustless system. Obviously you have not looked enough into the bitcoin protocol to warrant any proposals, at this time.

This statement is wrong or at least not accurate if you do do not wait at least for one confirmation and you do not check for doublespends in the network.
If the riskM = probability of fraud * value of the tx, then you just risk riskM money.
probability of fraud is decreasing with more confirmations. Of course, after X>0 confirmations, there is still chance that the transaction become unconfirmed if it is contained in split blockchain and is doublespend. But if the riskM is less than 100 USD, this may be acceptable for you.
The Bitcoin ist trustless system, but YOU decide when the riskM is acceptable - what X is large enough (after one confirmation of ordinary transaction, riskM is pretty small).
Anyway, your statement do not explain why is my idea wrong. The statement is dogmatic and has nothing to do with my idea.

[phelix]

As I mentioned in the first post, solutions based on Namecoin may be better. But they do not work yet.

Sure they work. You can even send NMC directly to an ID like this: namecoind sendtoalias phelix 1.00

You can include all kind of things to Namecoin IDs: BTC and other cryptocurrency addresses, eMail addresses, Bitmessage

Also there is a QT GUI that simplifies registering a name. A GUI tab especially for the id/ namespace is in the work. It would be relatively easy to implement Namecoin ID lookup with Electrum (as has been done with Bitmessage).

> no namecoin
With trusted resolvers this will go nowhere. A trustless structure is the whole point of Bitcoin.

[miso]

Sure they work. You can even send NMC directly to an ID like this: namecoind sendtoalias phelix 1.00

Can I send BTC to alias?
I want to give my friend my gmail address and let him send me Bitcoins.
I want to give my friend my facebook nickname and let him send me Bitcoins.
What I have to do? (the answer is bellow and it is different from my idea)

You can include all kind of things to Namecoin IDs: BTC and other cryptocurrency addresses, eMail addresses, Bitmessage

Everyone can link my email address to Namecoin ID without authentication. This is not the solution at all, because only Google can authenticate me.
But, there is good solution - have you read the 0015 BIP?
In the BIP 0015, there is already non-trustless idea similar to my idea. See here: https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki#https-web-service
But, my opinion is that my idea is better than idea in the BIP 0015 at the current time. See my first, updated post.

With trusted resolvers this will go nowhere. A trustless structure is the whole point of Bitcoin.

No, the BIP 0015 contains non-trustless part. I think only the Bitcoin protocol should be trustless. Why? Because there are Bitcoin unrelated services which are not compatible with Bitcoin.
Bitcoin needs integration with current services with well defined and standardized specification, while the hard and dangerous work in the protocol is in progress. When the hard work is done, rest of the world will switch to better, trustless implementation. But I doubt the current big players will switch to the trustless implementation (which is totally different and not compatible with their business) if it is not well tested. It may take years.

My idea is about an service not integrated to Bitcoin core protocol, but an service integrated to Wallets as easily implementable extension and other non-bitcoin service providers which provide person identifiers of any kind. See my updated first post.

Maybe this topic should be in general Bitcoin discussion. But it is related to Bitcoin-QT, so...

[dewdeded]

Another NSA sabotage proposal? GTFO

[miso]

Do you understand how hard it is to double spend? It isn't worth it if you are buying something for under $1000. Even 10mins is not a long wait. As I said before if I have to trust someone to get my money, then it shouldn't be apart of bitcoins. If I go against a trusted service and say they screwed me cause they hate me, no one will really listen. Your system is very much flawed.

I do understand that average user does not know how to and will not try to doublespend bitcoins, so it is "hard" to doublespend. That equation above is just better expression of what "hard" is and what money merchant risks in general.

I would agree with this sentence

As I said before if I have to trust someone to get my money, then it shouldn't be apart of bitcoins.

if the ends is like this: ... then it shouldn't be apart of the *Bitcoin protocol*.
The Bitcoin protocol and services on top of the Bitcoin protocol are different things. Yes, you can implement the services in trustless way, but see my previous comment why this can not be done today. In short, businesses and services (like Gmail or Facebook) are not compatible with Bitcoin in trustless way, nowadays.
Again, I do not mean this idea as core bitcoin service, the part of the protocol. See my previous comments.
See the bottom part of my first post about benefits for Bitcoin in general.

Another NSA sabotage proposal? GTFO

If this is NSA sabotage proposal, then Bitstamp, Coinbase, Blockchain.info and other businesses may be from the NSA too, because they are non-trustless services.
It does not matter if Google/NSA knows that I have received payment to an bitcoin address linked to short bitcoin address in their service. Do you know why? Because the short address I made is meant to be public for them - it is linked to my gmail account and they authenticated me!
Anyway, the Bitcoin is not anonymous. Just use some mixer and do not use this service if you want to stay anonymous. But I think you still have to trust the mixer service.