{"type":"rich","version":"1.0","author_name":"npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6","author_url":"https://nostr.ae/npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-12-18\n🗒️ Summary of this message: The author expresses concern about the lack of an easy and secure solution for using aliases in Bitcoin transactions, and suggests using SSL communication authenticated with a bitcoin address as a potential solution.\n📝 Original message:Pieter, it was more rhetorical question than asking for explanation, but\nthanks anyway. As an Internet application developer, I of course understand\nsecurity issues while using HTTPS and CA.\n\nI have a gut feeling that there simply does not exist any single solution\nwhich is both easy to use and secure enough. At least nobody mentioned it\nyet. And if I need to choose between easy solution or secure solution for\naliases, I'll pick that easy one. I mean - we need some solution which will\nbe easy enough for daily use; it is something what we currently don't have.\nBut if I want to be really really sure I'm using correct destination for\npaying $1mil for a house, I can every time ask for real bitcoin addresses,\nthis is that secure way which we currently have.\n\nslush\n\nOn Mon, Dec 19, 2011 at 2:14 AM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003ewrote:\n\n\u003e On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wrote:\n\u003e \u003e Maybe I'm retarded, but where's the point in providing alliases\n\u003e containing\n\u003e \u003e yet another hash in URL?\n\u003e\n\u003e Any DNS-based alias system is vulnerable to spoofing. If I can make\n\u003e people's\n\u003e DNS server believe that mining.cz points to my IP, I'll receive payments\n\u003e to\n\u003e you...\n\u003e\n\u003e If no trusted CA is used to authenticate the communication, there is no way\n\u003e to be sure the one you are asking how to pay, is the person you want to\n\u003e pay.\n\u003e Therefore, one solution is to put a bitcoin address in the identification\n\u003e string itself, and requiring SSL communication authenticated using the\n\u003e respective key.\n\u003e\n\u003e This makes the identification strings obviously less useful as aliases,\n\u003e but pure aliases in the sense of human-typable strings have imho\n\u003e limited usefulness anyway - in most cases these identification strings\n\u003e will be communicated through other electronic means anyway.\n\u003e\n\u003e Furthermore, the embedded bitcoin address could be hidden from the user:\n\u003e retrieved when first connecting, and stored together with the URI in\n\u003e an address book. Like ssh, it could warn the user if the key changes\n\u003e (which wil be ignored by most users anyway, but what do you do about\n\u003e that?)\n\u003e\n\u003e --\n\u003e Pieter\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Learn Windows Azure Live!  Tuesday, Dec 13, 2011\n\u003e Microsoft is holding a special Learn Windows Azure training event for\n\u003e developers. It will provide a great way to learn Windows Azure and what it\n\u003e provides. You can attend the event by watching it streamed LIVE online.\n\u003e Learn more at http://p.sf.net/sfu/ms-windowsazure\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111219/d492945b/attachment.html\u003e"}