Topic: [BIP][Draft] BitID - "Connect with Bitcoin" protocol - page 5. (Read 22743 times)

Here is one implementation of a simple BitID client in Python :
https://github.com/antonio-fr/SimpleBitID

You can install it on windows (.exe in release section), MacOS or Linux and test the user flow with the demo service :
http://bitid.bitcoin.blue

NameID is about storing your identity into Namecoin, BitID is about authenticating to a service by proving you control a Bitcoin address.

BitID and NameID complement themselves.

For instance :
1. you sign in on a service with your BTC address using BitID
2. the service queries NameID and retrieves the identity (name, email, avatar...) attached to this address

https://nameid.org has done this for a while with Namecoin, there's php source code for it & a firefox plugin. Try to make your implementation fairly closely compatible if possible.

Let's have a thought experiment: After a long week, you decide to have some fun and go to the movie theater.
You: Hi ! May I have 2 seats for the wolf of wall street ?
Cashier: Sure ! May you fill this form with your civility, firstname, lastname, address, phone number, credit card number, expiry date and CVV2 ?
You: ...
Cashier: ...?
You: wtf ?!!!

In real life, payment is the only thing required to finalize a transaction with a merchant. Sometimes it makes sense to disclose personal data but these cases are exceptions (when you expect a delivery, when you rent an expensive good, ...). In the digital world, disclosing personal data to access bought goods or services has always been the rule but this model has several drawbacks:
- it's conceptually wrong: it introduces the concept of identity in processes which should not rely on identity,
- it requires customers give personal information without any additional gain for them,
- it requires e-merchants act as secure data hosts, when their core business is selling products or services,
- it frequently results in data leaks producing nuisances like hacked accounts, phishing, spam,...

BitId protocol (associated to bitcoin and payment protocols) can be used to improve the current model existing in the digital world.
Imho, its main strengths are:
- a very good UX (as stated by @EricKennedy "BitId is 80% UX and 20% code"),
- users just have to secure one "database" (their bitcoin wallet),
- BitId and Bitcoin protocols are built on the same crypto stack (ecdsa, secp256k1, ...). All efforts done to detect potential flaws in this stack for Bitcoin will profit to BitId.

And of course, this is just one use case. Many others can be imagined...

OpenID, Connect with Facebook and all those other systems leak personal information to a website. BitID limits it to a Bitcoin address (which you don't have to use). That is one of it's biggest advantages if you ask me.

Correct me if I am wrong EricKennedy

This is an interesting project and I think there have been a lot of good comments on development side.

The question as some others have noted is "What is the specific need?" 

We have OpenID and many other authentication systems used by websites today so what are the core advantages to this?

I don't know if this has been posted before but BitID is on CoinDesk: Authentication Protocol BitID Lets Users ‘Connect with Bitcoin’

BitID has now a Javscript implementation :
https://github.com/porkchop/bitid-js

I think I get the idea now. 
The proof of stake is embedded in response provided by the user in order to "prove" her reputation. It would be an additional (and optional) information which can be provided via bitid protocol. In a way, I think that's very close of Eric's idea about metadata sent via bitid (see chapter "scope & permissions" in https://github.com/bitid/bitid/blob/master/bitid_metadata.md).

I've just pushed a new version of the python library on github : https://github.com/LaurentMT/pybitid
This version removes the dependency on an external library for all bitcoin and crypto stuffs. It embeds now a subset of V.Buterin's pybitcointools lib, adapted for compatibility with python 3.3.

Moreover, I've pushed a new demo app : https://github.com/LaurentMT/pybitid_2fa_demo
This toy project illustrates how bitid can be used to provide 2-Factor Authentication.

The initial demo app (simple authentication with bitid) can still be found at https://github.com/LaurentMT/pybitid_demo

Still a work in progress with many things on the todo list but all feedbacks are welcome !

@NanoAkron I speak with no authority at all on BitID. In fact, I have nothing to say on what BitID is, what BitID is not, or what BitID should be. I sincerely apologise if I've given any impression to the contrary.

Please re-read my posts. I'm simply trying to illustrate a new idea here, which BitID may or may not benefit from incorporating, and which people implementing BitID are free to use or ignore as they see fit.

I speak with certainty only about my own proposal. I think you'll agree it's fair for me to be certain about my own ideas at least ;-)

The idea I'm trying to illustrate is just:
* there exists a way that anonymous users can offer information to a webserver that can help it distinguish them from throwaway accounts.

That is all. This idea exists independently of BitID, and could be implemented independently of BitID. It just makes it easier if the user has some sort of portable identity that they can tie the proof-of-stake to, so that they don't need to re-calculate it for every site. An email address would work fine.

I proposed the idea in this thread because:
* a BitID would also work fine (being a portable ID that could be used on multiple websites)
* the set of potential BitID users and the set of potential users of my proposal heavily overlap: all Bitcoin users, basically. That makes BitID an obviously natural fit.
* it would provide an additional benefit to use of BitID, potentially increasing adoption.

The two complement each other.

gacrux - who are you exactly to speak with such authority about this project?

I'm here to simply offer suggestions and trying to frame the issues surrounding this novel ID method.

You're speaking from a presumed position of authority, defining with certainty about what this is and is not.

That was just one example.

I'm sure there are hundreds of use cases for BitID. And a single user can cheaply create hundreds of BitIDs for any of those use cases :-) How many of those use cases would benefit from being able to distinguish cheaply created throwaway BitIDs from more long-lived ones? Use your imagination.


Or even by anyone with zero satoshi to their name, right?

My proposal doesn't affect that in the slightest. Signatures proving stake are an optional extra for any user who wishes to provide them. Not doing so just means you get treated as a normal user (ie. the status quo today.)


Why should it not be cheap? It should be free.

Nobody is forcing anybody to prove stake if they don't want to.


Nobody suggested locking down anything. I'm afraid you must have misunderstood me somewhere.


Not a trust system.

It could be validated as frequently as the server needs. If the server just needs to decide whether or not to show you a CAPTCHA upon account creation (a very common use case I forsee) then once is fine. But if the server is doing something more complex there's no reason it couldn't refresh your stake weighting at will.


Uh, that's your BitID. (ie. the address you're using to sign in with BitID - replace QRSTUVWXYZ with your actual address.)

An email address would work equally well. We just need a way of tying the signature to your identity, so that nobody else can use it (and potentially get it blacklisted.) Anything unique that the website knows about you would work. But it's a hassle for the user to have to create the signatures more than once, so best to use something common (thus I thought it might be a good fit to use BitID.)


Well, everybody can always participate, exactly as they do now all over the web. Without a signature to prove ownership of a single satoshi you'd just be a normal user (ie. the status quo today.) Any threshold is better than nothing; there are only advantages to implementing this that I can see.


You have badly misunderstood me :-)

* This is not an authentication mechanism
* Authentication would happen with ordinary BitID (ie. signed challenge - no change there at all)
* In addition, once the user has successfully authenticated as per normal, the server can be optionally be given one or more signatures proving ownership of stake. The server can make use of the weighting it calculates from this information in any way it sees fit.
* The signatures are static because they just sign the user's ID (eg. BitID, or email address) - so they must be created exactly once and never change
* The server just used the signature to prove a link between the stake and the user, nothing else.

Your focus on preventing zero-day abuse shows you're really thinking of it as a chat forum tool. This is not the only potential usage case for BitID.

BitID is a highly secure, portable, widespread and free-to-use method of digital ID that can be used by anyone with a single Satoshi to their name.

If all you care about is stopping idiots on chat forums telling you how often they've fucked your mum, you're seriously overlooking the potentially revolutionary aspects of this ID technology.

Allowing it to remain a cheap, distributed single-point of access to any and all digital services will attract newcomers and allow the technology to bloom in ways you can't yet imagine.

Locking it down to people with masses of bitcoins to their name or people who were early adopters will see it fail like all other digital ID systems have.

Why does my webmail need to know that I'm 'more trustworthy'? Why does Netflix? Why would my phone?

It's your choice. Looking to create a 'trust' system based on value (age or amount of bitcoins at an address) is really premature for a technology which hasn't even launched yet.

100% agree with this

@gacrux: 2 questions:
- Am I right if I say that in this system, stake is validated only one time when creating the account ?
- Who generates what you've called the BitId QRSTUVWXYZ (user or website) ?

The idea sounds interesting to :
- avoid spammers using a massive number of addresses / private keys created on the fly to flood the forum
- "raise the cost" of trolling

I guess the "wealth issue" can be solved by choosing the "right" threshold: high enough to fight spammers/trolls and low enough to allow participation of everybody. So, the question seems to be: can we find such a threshold ?

Technically speaking, I envisioned a new challenge for each sign in (so it requires a new signature by the user) but I can imagine websites implementing something like what you've described which is very closed to a classic login/password authentication (address + challenge = login, signature = password).

Btw, this idea of mixing coins and age of coins makes me think to the movie "In Time" (synopsis: time is the new wealth). Do you know it ?

Edit: Cross-post. You've already answered some of my question in your last post. 

Just one other small point - it might be necessary to tweak the (balance * coin age) formula, perhaps to give more weight to balance, or more weight to coin age, or to impose a minimum coin age (1 day? 1 week?) or whatever.

I'm simplifying a bit here because I'm just trying to illustrate an idea.

The key point is that:
* BitID need not concern itself with the formula (but it would be helpful if it would automatically pass the address signatures (for proof of funds) during BitID login, to simplify the user experience.)
* Individual sites could employ a different formula to calculate the weighting (some might give more weight to coin age, some less) ... and use that weighting in different ways.
* What works best for any given site could be arrived at through trial and error.
* The user doesn't have to care. They just (optionally) provide signatures for a decent amount of funds that they've had lying in one place for a while, or intend to have lying in one place for a while, and forget about it. Anywhere it helps them with account creation (skip the CAPTCHA, start with +ve reputation, or whatever) is a bonus. Anywhere it doesn't (ie. 99% of the web) doesn't matter, no harm done.

If this were implemented I'd probably just put ~$100 into a new cold storage address, create my BitID signature, and then forget about it. As time goes on my ID will just continue to accumulate more and more legitimacy. I know I won't move it, so it doesn't have to be a huge amount (and, indeed, I'd refrain from signing with my main savings wallet, for financial privacy reasons.) If I ever need that $100 back it's still mine, so no harm (although my BitID's legitimacy rating would be reset as soon as I moved it, of course - but I could substitute/add other signatures at any time.)

We can't prove goodwill, only "likelihood that user is not a throwaway account." But if you don't act with goodwill we'll ban your account (as per usual) and you'll be on to creating throwaway accounts soon enough. If you have a huge stack of bitcoins, and you're prepared to split them up into lots of addresses and wait for them to age... then yes, you could create a greater number of throwaway accounts that we erroneously think are legitimate users. But you'll still burn through them eventually :-)

Additionally, I'd suggest:
* you would have to be a very determined troll to plan your trolling weeks or months in advance :-)
* we could just "lift the bar" (adjust the weighting that our site is looking for upwards) so that your troll accounts still don't meet it

As you see, it's an arms race between you and the legitimate users. But you have two disadvantages:
* you have multiple IDs that you need to plan in advance and adequately fund (a normal user just has one)
* those multiple IDs that you put so much hard work into keep getting reset to zero every time you do something naughty with them

It isn't a perfect system. But it would surely discourage some (most?) trolls. It gives us the tools to fight, at least. Making life harder for trolls and scammers is IMO always worthwhile even if not perfect.

I'm not suggesting that wealthy people are intrinsically more trustworthy. Indeed, the weighting I'm talking about is not a measure of trust. It's just a measure of how likely any given user is not to be using a throwaway account.

When users are anonymous and accounts are free to create there is zero barrier to people creating hundreds of throwaway accounts, which has wreaked all kinds of havoc all over the 'net, and is mainly responsible for the current state of affairs of semi-illegible CAPTCHAs everywhere you look.

We're not trying to compare two genuine users, Alice and Bob, and determine that Alice is more trustworthy or important based on the fact she is richer. We're just trying to screen out the thousand spam accounts that Eve has created to try to game the ratings system / act as sockpuppets / troll their merry way around the ban-hammer. Above a fairly low bar everybody would be equal.

Eve's spam accounts will find it much harder to each reach that bar, because she has lots of them that she needs to fund. And every time an admin brings down the ban-hammer Eve suffers a setback.

Any genuine users who can't reach the bar will be indistinguishable from Eve, and will have to establish their reputation from scratch. But they currently do anyway. That's the current status-quo.

In reality showing that you had $20 sitting in one place for a month might be enough to skip the CAPTCHA on most sites. Or showing that you had ~$500 sitting in one place for a day, if you're wealthy and in a hurry. Or showing that you had ~$3 sitting in one place for 6 months, if you're really poor but not in a hurry. This is a mechanism that everybody can take advantage of to distinguish themselves from Eve's throwaway accounts, if they want to.

Negative. You only need a /signature/, created once by the key with access to the funds, which does not change. For an entirely manual implementation you could simply save the signature in a text file on your desktop and cut/paste it into a form on the website the first time you log in.

Try this:
1. Open bitcoin-qt
2. File -> Sign Message
3. Pick address that contains some aged funds
4. Enter message - "My BitID is: QRSTUVWXYZ"
5. Sign
6. Copy/paste the address and the signature into a text file (eg. "IAV7hQhB5d5z0PGJFpqF+xiGt1T+u6etvBx56jCA2TxXf9LaTb/+iX9H/87UKx9S9vOqiL11n1GqkoaTiGjsQwA=")
7. GOTO step 1, repeat for as many addresses as you desire

Now, if you happen sign into my website with BitID QRSTUVWXYZ, you need only provide me the contents of your static text file sometime (and only the first time you sign in) in order to establish that you're "probably genuine."

I determine how much weight I give to your genuineness based on the sum of (coins * age) in all the addresses you've provided that:
1. have correct signatures matching your BitID
2. I haven't yet blacklisted for being associated with bad behaviour

A higher weighting might mean you start with more forum reputation, or aren't challenged with a CAPTCHA. A low enough weighting means you still get the CAPTCHA / default newbie reputation / whatever (ie. status quo, no disadvantage.)



Indeed. There /is/ a little bit of extra work for the server here. But this is for a non-critical bitcoin application (no money gets lost if we screw up) so we don't need to run a full trustless node. A light SPV client like bitcoinj should work fine, or perhaps even something like the blockchain.io API. Hardly prohibitive resource-wise.


I think it'd be a nicer user experience if this were integrated with BitID, as the user could just configure their proof-of-stake signatures once and then not care, and get the free reputation benefit everywhere they use BitID. But, in the simplest case, as I say, a website that already accepts BitID login could just provide a "paste your proof-of-stake signatures here" text field for the user to optionally submit.

I'm just throwing ideas around here, but I suspect this could prove to be quite effective.