📅 Original date posted:2014-04-04
📝 Original message:>
> The goal of writing a BIP seems to be to get lots of different wallet
> authors to write lots of code for you - but I *am* a wallet author, and I
> don't think that's the right way to get traction with a new scheme.
>
I started without a BIP and the feedback I got is that I should to a BIP.
We cannot write all the code for all the wallets ; this is after all a
communauty project.
However we have and we will propose bounties for each wallet to support
natively the protocol.
> For instance the TREZOR guys would have to support your new protocol
> otherwise if I paid my hotel bill with my TREZOR I couldn't open the door
> when I got there! But they probably have better things to be doing right
> now.
>
Yes you are right. But if the concept of authenticating yourself gets
traction, they will probably do it.
> The key difference between just generating a client certificate and using
> a Bitcoin address is that the client certificate is something that is used
> *specifically* for identification. It leaves no trace in the block chain,
> so no weird privacy issues, it doesn't matter how you manage your wallet,
> and you don't have to persuade lots of people to support your idea because
> it was already done >10 years ago and basically every browser/web server
> supports it.
>
My view on this is mainly about the UX and the fact everyone in Bitcoinland
has a wallet.
It's a approach leveraging this fact, with the possibility to build
interesting apps combining address auth and the blockchain.
I understand the problems related to multisig, contracts etc,
There is no such thing as a from address in a transaction, however many
services still take first tx as the return address.
People will always find way of building and doing stuff (cf the message in
the blockchain debate).
> Some reasons client certs aren't more widely used boil down to:
>
> 1. People like passwords. In particular they like forgetting them and
> then having friendly people assist them to get it back. Client certs can
> support this use case, but only if apps are checking the identity in them
> and not the key.
> 2. The UI for managing client certs in browsers is pretty horrible.
> There's little incentive to improve it because of (1).
> 3. Cross-device sync doesn't work very well. Apple are starting to
> tackle this with their iCloud Keychain Sync service but then of course,
> Apple has all your keys and you may well just sign in to things with your
> Apple account (if it were to be supported). Cross-device sync where the
> server *doesn't* get your keys is supported by Chrome for passwords,
> but not client certs, because (1)
>
> None of the above issues have any obvious fix lurking within Bitcoin.
>
There is also the benefit of revocation with certificate and central
authority.
But, again, you already have a wallet and a Bitcoin address.
So if you add a simple auth protocol, people will use it at no cost.
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140404/9e6d4ffc/attachment.html>;
Eric Larchevêque [ARCHIVE] /
npub1pa…3rxtp
2023-06-07 15:17:21
in reply to nevent1q…mg2f
Author Public Key
npub1pa6l5jatv92d4vzk566r58zjawpuu0we8nhrywfhp90f9948e0tsx3rxtpPublished at
2023-06-07 15:17:21Event JSON
{
"id": "89f5218e0403bdf775bc8a2b4d11214621abcbd24b1b44303289c899755f2863",
"pubkey": "0f75fa4bab6154dab056a6b43a1c52eb83ce3dd93cee323937095e9296a7cbd7",
"created_at": 1686151041,
"kind": 1,
"tags": [
[
"e",
"4ef6a6393121d94287520af04668f86fde241c789a5b506f18e8d499d4d231da",
"",
"root"
],
[
"e",
"c2347da8fe3479ed2155090fbd3297a725dffeb6e56b64c8fc0bde94b0aba8f4",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 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",
"sig": "a38d9a54ca84ec464ee27d9d8b8d9fc94a4f9cd041dd8f24396f5f0bfc33524ea85d8566d2c288acfbc1ff633cf5c51405ee096b9670248a7a26ce196430412d"
}