{"type":"rich","version":"1.0","author_name":"npub1pa6l5jatv92d4vzk566r58zjawpuu0we8nhrywfhp90f9948e0tsx3rxtp","author_url":"https://nostr.ae/npub1pa6l5jatv92d4vzk566r58zjawpuu0we8nhrywfhp90f9948e0tsx3rxtp","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-04\n📝 Original message:\u003e\n\u003e The goal of writing a BIP seems to be to get lots of different wallet\n\u003e authors to write lots of code for you - but I *am* a wallet author, and I\n\u003e don't think that's the right way to get traction with a new scheme.\n\u003e\n\nI started without a BIP and the feedback I got is that I should to a BIP.\nWe cannot write all the code for all the wallets ; this is after all a\ncommunauty project.\nHowever we have and we will propose bounties for each wallet to support\nnatively the protocol.\n\n\n\u003e For instance the TREZOR guys would have to support your new protocol\n\u003e otherwise if I paid my hotel bill with my TREZOR I couldn't open the door\n\u003e when I got there! But they probably have better things to be doing right\n\u003e now.\n\u003e\n\nYes you are right. But if the concept of authenticating yourself gets\ntraction, they will probably do it.\n\n\n\u003e The key difference between just generating a client certificate and using\n\u003e a Bitcoin address is that the client certificate is something that is used\n\u003e *specifically* for identification. It leaves no trace in the block chain,\n\u003e so no weird privacy issues, it doesn't matter how you manage your wallet,\n\u003e and you don't have to persuade lots of people to support your idea because\n\u003e it was already done \u003e10 years ago and basically every browser/web server\n\u003e supports it.\n\u003e\n\nMy view on this is mainly about the UX and the fact everyone in Bitcoinland\nhas a wallet.\nIt's a approach leveraging this fact, with the possibility to build\ninteresting apps combining address auth and the blockchain.\n\nI understand the problems related to multisig, contracts etc,\nThere is no such thing as a from address in a transaction, however many\nservices still take first tx as the return address.\nPeople will always find way of building and doing stuff (cf the message in\nthe blockchain debate).\n\n\n\u003e Some reasons client certs aren't more widely used boil down to:\n\u003e\n\u003e    1. People like passwords. In particular they like forgetting them and\n\u003e    then having friendly people assist them to get it back. Client certs can\n\u003e    support this use case, but only if apps are checking the identity in them\n\u003e    and not the key.\n\u003e    2. The UI for managing client certs in browsers is pretty horrible.\n\u003e    There's little incentive to improve it because of (1).\n\u003e    3. Cross-device sync doesn't work very well. Apple are starting to\n\u003e    tackle this with their iCloud Keychain Sync service but then of course,\n\u003e    Apple has all your keys and you may well just sign in to things with your\n\u003e    Apple account (if it were to be supported). Cross-device sync where the\n\u003e    server *doesn't* get your keys is supported by Chrome for passwords,\n\u003e    but not client certs, because (1)\n\u003e\n\u003e None of the above issues have any obvious fix lurking within Bitcoin.\n\u003e\n\nThere is also the benefit of revocation with certificate and central\nauthority.\n\nBut, again, you already have a wallet and a Bitcoin address.\nSo if you add a simple auth protocol, people will use it at no cost.\n\nEric\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140404/9e6d4ffc/attachment.html\u003e"}