rich1.0npub1euw92v2lmlflea24tgns69r4gxwfknh3ufj0ata70hrk7jxkhgws0l06dnhttps://nostr.ae/npub1euw92v2lmlflea24tgns69r4gxwfknh3ufj0ata70hrk7jxkhgws0l06dnnjumphttps://nostr.ae๐Ÿ“… Original date posted:2011-12-16 ๐Ÿ—’๏ธ Summary of this message: Bitcoin proposals for aliases have limitations, including centralization, reliance on HTTPS and CA, and limited domain name usage. Namecoin integration is complex but effective. ๐Ÿ“ Original message:The number of proposals <https://en.bitcoin.it/wiki/BIP_0015> is not infinite, here are their problems : - FirstBits : centralized - DNS TXT Records : DNSSEC is required to have a minimum of security, limits usage to engineers, limits usage to some domain names (i won't be able to use a gmail address for example, because i don't control the gmail.com domain) - Server Service (DNS + a daemon) : Same as DNS TXT records - HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able to check the full certificate chain and access a list of up-to-date certificate authorities (installed on the OS or provided with bitcoin). And don't forget the CA model is not 100% reliable (several CA hacked this year + possible government control...). - IP Transactions : /This proposal seeks to enable DNS lookups for IP transactions/ => same as above I know that providing a namecoin daemon with bitcoin is not the lighter solution, but, if a better one existed i guess it would have already been integrated into bitcoin... (see in what state is my first attempt with the HTTPS proposal : Send payments to emails, urls and domains in GUI <https://github.com/bitcoin/bitcoin/pull/174> - /khalahan opened this pull request April 20, 2011/) So, what's next ? Le 16/12/2011 20:54, slush a รฉcrit : > Khalahan, honestly, using namecoin for aliases is (for me) clean > example of over-engineering. I mean - it will definitely work if > implemented properly. I played with a namecoin a bit (as my pool was > the first 'big' pool supporting merged mining), but I think there's > really long way to provide such alias system in namecoin and *cleanly > integrate it with bitcoin*. Don't forget that people who want to do > lookup need to maintain also namecoin blockchain with their bitcoin > client. It goes against my instinct of keeping stuff easy. > > For example, yesterday I implemented HTTPS lookup for addresses into > my fork of Electrum client. I did it in 15 minutes, it works as > expected, it does the job and the implementation is really > transparent, becuase implementation is 20 lines of code. There's no > magic transformation, no forced "?handle=" parameters or whatever. And > I don't care if somebody provide URL > https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True > <https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True> > > And everybody can do the same in their clients, in their merchant > solutions, websites or whatever. Everybody can do HTTPS lookup. But > try to explain DNS, Namecoin, IIBAN, email aliases to other programmers... > > Those IIBAN - well, why not. At least I see the potential in PR. So > far I understand it as some teoretic concept which is not supported by > anything else right now. Give it few years until it matures and then > add IIBAN alias to Bitcoin client too. > > Maybe I'm repeating myself already, but the way to go is to make > aliases as easy as possible, so everybody can implement it in their > own solution and thus practially remove the need of using standard > bitcoin addresses for normal users. Using some superior technology, > which is hard to implement or even understand won't solve the > situation, because it will ends up with some reference implementation > in standard client only and nobody else will use it. > > slush -- Best Regards, Khalahan http://dot-bit.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/cb3fc4b4/attachment.html>