Author

Topic: Resolvers of short bitcoin addresses - alter. to BIP 0015 HTTPS Web Service (Read 1990 times)

legendary
Activity: 1498
Merit: 1000
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.

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.
newbie
Activity: 37
Merit: 0
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
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.
legendary
Activity: 1232
Merit: 1011
Monero Evangelist
Another NSA sabotage proposal? GTFO
newbie
Activity: 37
Merit: 0
Quote
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)

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

Quote
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...
legendary
Activity: 1708
Merit: 1020
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.
newbie
Activity: 37
Merit: 0
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.
newbie
Activity: 37
Merit: 0
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.
newbie
Activity: 37
Merit: 0
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:
Quote
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
Quote
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).
legendary
Activity: 1708
Merit: 1020
Ever heard of Namecoin IDs?
newbie
Activity: 37
Merit: 0
no need for trust. Look up firstbits

Firstbits solution is not good in general
Quote
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.
sr. member
Activity: 333
Merit: 252
no need for trust. Look up firstbits
newbie
Activity: 37
Merit: 0
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.
Quote
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
[email protected]/donations5 is resolved to 1J3meoXcKEAe4E6XiHB4GMFDQPGuqgkefT
[email protected]/a5p8gfKhSw is resolved to 1FuFjXtg2rdKLs6JjNPpN3pUJnW1JXwx2G
[email protected]/dontions is not valid

In 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 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 [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 Smiley
Jump to: