<unnamed>

Public Key

npub1pa6l5jatv92d4vzk566r58zjawpuu0we8nhrywfhp90f9948e0tsx3rxtp

Profile Code

nprofile1qqsq7a06fw4kz4x6kpt2ddp6r3fwhq7w8hvnem3j8ymsjh5jj6nuh4cprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqyxhwumn8ghj7mn0wvhxcmmvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hscx3c3w

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-07 15:17:23 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message:The development of BitID has had some progress, and we have now a working
wallet prototype based on Android Bitcoin Wallet (bitoinj).
The user flow is quite nice and if you are curious here is a short video
demonstration :
https://www.youtube.com/watch?v=3eepEWTnRTc
By default, each new first auth request will create and save a new address
(SQRL like). It could be based on BIP32, but this works also without.
This requires to add metadata to addresses, as described here :
https://github.com/bitid/bitid/blob/master/bitid_metadata.md
It open also the fields for decentralized 2FA as well as "pay as guest"
checkout in conjonction with BIP70 payment request.
Eric
On Tue, Apr 22, 2014 at 8:34 AM, Jan Møller <jan.moller at gmail.com> wrote:
> The reason why client side certificates have never gained traction because
> it is a pain to safely store/backup secrets.
> In bitcoinland we are forced to solve the problem of safely storing
> secrets, and over the years we have come up with software and hardware
> solutions to make this safer and easier to manage for ordinary people.
> Solving this is paramount to the success of Bitcoin, and nobody has solved
> it before on a grand scale.
>
> I see no reason for forcing end users to use two different mechanisms for
> safely managing secrets.
>
> I agree that using a bitcoin address for authentication purposes might be
> confusing and potentially linking your funds with your identity. So I am
> all for using something else than bitcoin addresses and bitcoin private
> keys.
>
> With bip32 we have finally agreed on a mechanism for generating a
> hierarchy of bitcoin private keys from a master seed. A similar approach
> can be used for generating a parallel hierarchy for authentication
> purposes.
>
> - Jan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/97fad26c/attachment.html>

2023-06-07 15:17:22 UTC

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Fri, Apr 4, 2014 at 4:51 PM, Mike Hearn <mike at plan99.net> wrote:
> My view on this is mainly about the UX and the fact everyone in
>> Bitcoinland has a wallet.
>>
>
> Well, yes, but we also have browsers too :)
>
>
Yes, but no one will ever install a plug in.
And all will update their wallets with the last version, including the auth
protocol.
> I don't want to suggest the problem is unimportant - I'd love it if the
> world could move beyond passwords. But I have many scars from my time in
> the Google account swamps. We had a big team, lots of resources and even
> just getting people to use their phone as a second factor - *the simplest
> second factor possible* - was a huge uphill battle that most users just
> didn't care about. People like passwords. If you can find a way to make
> something that's better than a password but just as convenient, fantastic!
> But I don't think Bitcoin addresses are such a thing.
>
I perfectly understand all the objections, and they are very good points.
I have at least two wallets enthousiastic about the project so the protocol
will be implemented and it will give some room to experiment.
The BIP came from the idea we should formalize the standard so all wallets
could participate, and it felt more logical to come forward with it.
Maybe a better strategy would be to start "privately" with a few wallets
and services using the protocol, and to come back to the BIP there is
usability and traction.
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140404/c8740919/attachment.html>

2023-06-07 15:17:21 UTC

- reply

📅 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>

2023-06-07 15:17:18 UTC

- reply

📅 Original date posted:2014-04-04
📝 Original message:> Using a bitcoin address repeatedly is something we're trying to move away
from.
This is indeed a flaw of the proposed protocol. However it really depends
in the end of the usage : you could use an auth just once, to redeem a good
you paid, or multiple times if this makes a sense (mining pool app for
instance).
> And using a bitcoin address as a persistent identity key feels like the
wrong direction to me.
What would be really the difference between artificially create a
certificate for identity and selecting one address for identity?
> Better to use something like client certificates, the FIDO alliance's
(new!) specs:
> http://fidoalliance.org/specifications/download
> ... or Steve Gibson's proposed SQRL system:
> https://www.grc.com/sqrl/sqrl.htm
The proposal is nothing more than sqrl scoped to Bitcoin keys.
> If one of those systems gets critical mass and actually starts being
successful, then I think it would make sense to specify a standard way of
using a HD wallet's deterministic seed to derive a key used for the FIDO or
SQRL systems.
This could be a very interesting approach. But I think the system which
would get critical mass is the one which would be implemented into major
Bitcoin wallets.
Why adding another app or software when you already have all you need?
>
>
>
>
> On Fri, Apr 4, 2014 at 9:22 AM, Eric Larchevêque <elarch at gmail.com> wrote:
>>
>> What I'm trying to achieve, is to have a very simple way of
authenticating yourself with one Bitcoin address from your wallet.
>> For most of the people using Bitcoin, their wallet is on their phone.
>>
>> The UX is clear and simple :
>> 1. click on "connect with Bitcoin" (the audience is normal people)
>> 2. flash the QRcode with your wallet (blockchain.info, mycelium, ...)
>> 3. accept the authentication request (same style than OpenID or Facebook
connect)
>> 4. user is autologged and identified by the chosen Bitcoin public address
>>
>> It makes sense only if major wallets are supporting the protocol. If you
need to install a plugin or download a third party software, no one will do
it.
>> I see only benefits for the entire ecosystem, and if I'm working on such
a proposition it is because I really need this feature.
>>
>> Of course, it can be done without a BIP, I just need to convince wallet
developpers one by one to implement the feature.
>> But I thought it was much better to start the "official" way, so all
wallet could easily find and implement the same authentication mechanism.
>>
>> > Bitcoin and website authentication are unrelated problems
>>
>> I respectfully disagree. Many services require your Bitcoin address, and
to do that they artificially request an email/password to store it.
>> This is not about authentication as an identity (as "I'm Eric
Larcheveque"), but as in "I'm proving to you that I control this address".
>>
>> Without such a standard protocol, you could never envision a pure
Bitcoin physical locker rental, or booking an hotel room via Bitcoin and
opening the door through the paying address.
>>
>> Eric
>>
>>
>>
>> On Fri, Apr 4, 2014 at 3:08 PM, Mike Hearn <mike at plan99.net> wrote:
>>>
>>> This comes up every few months. I think the problem you are trying to
solve is already solved by SSL client certificates, and if you want to help
make them more widespread the programs you need to upgrade are web browsers
and not Bitcoin wallets. There are certainly bits of infrastructure you
could reuse here and there, like perhaps a TREZOR with a custom firmware
extension for really advanced/keen users, but overall Bitcoin and website
authentication are unrelated problems.
>>>
>>>
>>> On Fri, Apr 4, 2014 at 2:15 PM, Eric Larchevêque <elarch at gmail.com>
wrote:
>>>>
>>>> Hello,
>>>>
>>>> I've written a draft BIP description of an authentication protocol
based on Bitcoin public address.
>>>>
>>>> By authentication we mean to prove to a service/application that we
control a specific Bitcoin address by signing a challenge, and that all
related data and settings may securely be linked to our session.
>>>>
>>>> The aim is to greatly facilitate sign ups and logins to services and
applications, improving the Bitcoin ecosystem as a whole.
>>>>
>>>> https://github.com/bitid/bitid/blob/master/BIP_draft.md
>>>>
>>>> Demo website :
>>>> http://bitid-demo.herokuapp.com/
>>>>
>>>> Classical password authentication is an insecure process that could be
solved with public key cryptography. The problem is that it theoretically
offloads a lot of complexity and responsibility on the user. Managing
private keys securely is complex. However this complexity is already being
addressed in the Bitcoin ecosystem. So doing public key authentication is
practically a free lunch to bitcoiners.
>>>>
>>>> I've formatted the protocol description as a BIP because this is the
only way to have all major wallets implementing it, and because it
completely fits in my opinion the BIP "process" category.
>>>>
>>>> Please read it and let me know your thoughts and comments so we can
improve on this draft.
>>>>
>>>> Eric Larcheveque
>>>> elarch at gmail.com
>>>>
>>>>
>>>>
------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>
>>
>>
------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> --
> Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140404/f2c5cf7a/attachment.html>

2023-06-07 15:17:17 UTC

- reply

📅 Original date posted:2014-04-04
📝 Original message:What I'm trying to achieve, is to have a very simple way of authenticating
yourself with one Bitcoin address from your wallet.
For most of the people using Bitcoin, their wallet is on their phone.
The UX is clear and simple :
1. click on "connect with Bitcoin" (the audience is normal people)
2. flash the QRcode with your wallet (blockchain.info, mycelium, ...)
3. accept the authentication request (same style than OpenID or Facebook
connect)
4. user is autologged and identified by the chosen Bitcoin public address
It makes sense only if major wallets are supporting the protocol. If you
need to install a plugin or download a third party software, no one will do
it.
I see only benefits for the entire ecosystem, and if I'm working on such a
proposition it is because I really need this feature.
Of course, it can be done without a BIP, I just need to convince wallet
developpers one by one to implement the feature.
But I thought it was much better to start the "official" way, so all wallet
could easily find and implement the same authentication mechanism.
> Bitcoin and website authentication are unrelated problems
I respectfully disagree. Many services require your Bitcoin address, and to
do that they artificially request an email/password to store it.
This is not about authentication as an identity (as "I'm Eric
Larcheveque"), but as in "I'm proving to you that I control this address".
Without such a standard protocol, you could never envision a pure Bitcoin
physical locker rental, or booking an hotel room via Bitcoin and opening
the door through the paying address.
Eric
On Fri, Apr 4, 2014 at 3:08 PM, Mike Hearn <mike at plan99.net> wrote:
> This comes up every few months. I think the problem you are trying to
> solve is already solved by SSL client certificates, and if you want to help
> make them more widespread the programs you need to upgrade are web browsers
> and not Bitcoin wallets. There are certainly bits of infrastructure you
> could reuse here and there, like perhaps a TREZOR with a custom firmware
> extension for really advanced/keen users, but overall Bitcoin and website
> authentication are unrelated problems.
>
>
> On Fri, Apr 4, 2014 at 2:15 PM, Eric Larchevêque <elarch at gmail.com> wrote:
>
>> Hello,
>>
>> I've written a draft BIP description of an authentication protocol based
>> on Bitcoin public address.
>>
>> By authentication we mean to prove to a service/application that we
>> control a specific Bitcoin address by signing a challenge, and that all
>> related data and settings may securely be linked to our session.
>>
>> The aim is to greatly facilitate sign ups and logins to services and
>> applications, improving the Bitcoin ecosystem as a whole.
>>
>> https://github.com/bitid/bitid/blob/master/BIP_draft.md
>>
>> Demo website :
>> http://bitid-demo.herokuapp.com/
>>
>> Classical password authentication is an insecure process that could be
>> solved with public key cryptography. The problem is that it theoretically
>> offloads a lot of complexity and responsibility on the user. Managing
>> private keys securely is complex. However this complexity is already being
>> addressed in the Bitcoin ecosystem. So doing public key authentication is
>> practically a free lunch to bitcoiners.
>>
>> I've formatted the protocol description as a BIP because this is the only
>> way to have all major wallets implementing it, and because it completely
>> fits in my opinion the BIP "process" category.
>>
>> Please read it and let me know your thoughts and comments so we can
>> improve on this draft.
>>
>> Eric Larcheveque
>> elarch at gmail.com
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140404/caca26c8/attachment.html>

2023-06-07 15:17:17 UTC

- reply

📅 Original date posted:2014-04-04
📝 Original message:Hello,
I've written a draft BIP description of an authentication protocol based on
Bitcoin public address.
By authentication we mean to prove to a service/application that we control
a specific Bitcoin address by signing a challenge, and that all related
data and settings may securely be linked to our session.
The aim is to greatly facilitate sign ups and logins to services and
applications, improving the Bitcoin ecosystem as a whole.
https://github.com/bitid/bitid/blob/master/BIP_draft.md
Demo website :
http://bitid-demo.herokuapp.com/
Classical password authentication is an insecure process that could be
solved with public key cryptography. The problem is that it theoretically
offloads a lot of complexity and responsibility on the user. Managing
private keys securely is complex. However this complexity is already being
addressed in the Bitcoin ecosystem. So doing public key authentication is
practically a free lunch to bitcoiners.
I've formatted the protocol description as a BIP because this is the only
way to have all major wallets implementing it, and because it completely
fits in my opinion the BIP "process" category.
Please read it and let me know your thoughts and comments so we can improve
on this draft.
Eric Larcheveque
elarch at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140404/78771884/attachment.html>