[BIP][Draft] BitID - "Connect with Bitcoin" protocol

[gacrux]

This approach is interesting, but I can't see how having coins for a long time on an address is related to small probability of abusive behavior ?

Abusive behaviour isn't the problem I want to fix - /cheap identity creation/ is.

Abusive behaviour is easily dealt with by simply banning the user. A problem only arises when the user has nothing invested in the account that you banned, so can simply create a new account and come back.

(coin age * balance) is a very good proxy for investment in an identity, because you can't repeatedly fake it. Sure, everybody starts with some reputation, even the bad guys. But the bad guys only get one chance to burn up their reputation, then acquiring more will be very slow.

I understand that if you troll you'd get banned and then in the long term it would converge to the expected relation, but from day one it wouldn't work at all.

He'd get banned very quickly, and then not come back (well, not without significant resources + time to throw at the problem.) I'm not talking about a 100% bulletproof solution, just cheaply raising the bar.

The other possible solutions to avoid CAPTCHA are :

• Coin sacrifice
• send a not trivial amount to the service in escrow (2 of 2 multisig)
• just pay the service 0.001 BTC (for instance) to unlock privileges

Another approach is to delegate the identity to another protocol such as the Identity Protocol from Mike Hearn.

My objections to the sacrifice approach are:
* the bootstrapping problem: real upfront costs to users to participate a new, as-yet-unestablished mechanism, will prevent it gaining significant traction
* the fluctuating value problem: a sacrifice of 1 BTC right now represents about USD$440. A sacrifice of 1 BTC in Janurary might have represented closer to $1000; in Janurary last year, ~$17. Measuring sacrifices is non-trivial, requires knowledge of historical exchange rates.

Objections to the other two - escrow with the website, or outright micro payment - are similar:
* bootstrapping problem: too complex / expensive to gain significant usage
* requires funds in a hotwallet, which may be vulnerable to theft
* requires the client to have access to the blockchain / actually broadcast transactions

By comparison, what I'm suggesting:
* requires the client to simply have some signatures which prove control of funds, nothing more. The BitID authentication remains very simple (just a few extra bytes to transmit.)
* client requires no hot wallet, no knowledge of blockchain, makes no transactions.
* requires new users to simply have a bitcoin balance somewhere, which most already do (even cold storage - as long as they have access to the private key to sign their BitID to prove control of funds.)

Think about it. Most bitcoin users probably already have control of an address:
A) with significant funds
OR:
B) with even a small amount of funds that haven't moved for a very long time
OR:
C) both (ie. your typical cold storage user)

They could just sign a simple message (eg. bitcoin-qt has a feature to sign arbitrary messages with private keys from your wallet) that says "My BitID is: XYZ", cut-and-paste the output into the client software they use for BitID (browser plugin, whatever.) And - bingo - instant reputation everywhere they use BitID.

[gacrux]

@gacrux I agree with you that protocol specs should address spam issue server side (actually, we already had this discussion with Eric ) but I agree with Eric that we can imagine several solutions to avoid spam and that each website should be able to implement the solution which best fits its needs.

A universal measure of how much a user has invested in their current ID should be very generally applicable. I think it belongs in the auth protocol. When I sign in with BitID the server should just have that "likelyhood of uniqueness" weighting available to it for free. I need only transmit a few bytes during authentication and it'd be available. It's then up to the server whether it wants to make use of that information or not.

On my side, I can imagine this use case:
- I want to buy a movie on a VOD website.
- I pay it with bitcoin.
- The website checks the blockchain (or via BIP70) to retrieve paiements sent by customers and match them with purchases.
   All input addresses used as sources of paiements can be used to sign in with the website and access the movie.
- I sign in with one of the input addresses of my tx. Popcorn time !

Completely tangential use case sorry If the user is paying you for goods/service then you don't care if they do it 100x - as long as they're paying you every time When was the last time you typed in your visa card number and then got presented with a CAPTCHA? The fact that you've just presented payment is all the proof most people want that you're serious about the transaction.

Think instead of something like this forum, where account creation is free:
1. create account
2. troll / scam like crazy
3. acquire negative reputation
4. ditch account, GOTO 1, rinse & repeat.

That's pretty common. How can we combat it? One idea is to make newly created accounts start with negative reputation (or restricted to posting in a newbies area, or whatever.) But then genuine new users face an uphill battle to distinguish themselves from the trolls and scammers, and to build up a reputation.

/I'm just suggesting one cheap way that we could distinguish them./

If the user can show signatures proving control of a suitable amount of aged coins (the more coins the better / the older the better), that we haven't ever seen before, then they're /probably/ a genuine new user.

In the case of a forum, we might grant that "probably genuine" new user a positive starting reputation, whereas an unverified new user (more likely to be a troll/scammer creating throwaway accounts) starts with default lower reputation. We're just sorting the sheep from the goats, if you see

In the case of, eg. an email service, we could allow the "probably genuine" new users to skip the CAPTCHA (ie. if their [balance * coin age] score meets a certain configurable threshold.) The CAPTCHA is designed to prevent an automated script from creating thousands of accounts, right? Such an automated script is very unlikely to be able to provide thousands of unique high/aged BTC balances.

Yes, the spammer could invest in an enormous amount of BTC, split it into thousands of addresses, and then wait for a few months for it to age enough to perform his attack. All the site admin needs to do to respond is bump the threshold up. He can quickly establish a bar that is high enough that only the most determined spammer would bother.

For websites like forums I could imagine something like a micro-tx sent to the forum before sign out but may be something like what you described
could be a more advanced system to fight trolling. Concerning privacy concerns, I would mix some coins with coinjoin (or another) before sending the micro-tx.

I'm an avid bitcoin user, I pay for stuff in bitcoin whereever I can. But even I can't be bothered to keep funds in a hot wallet so I can make micro payments to sign up for forums. I don't expect you'll get many takers for that one

So, my take is that we should make sure that websites think to address the potential spam issue and may be propose different anti-spam concepts which will be more or less adapted to the needs of websites. But websites should be free to implement what seems the best solution for them.

I advocate simply that you give them one tool to do this: BitID uniqueness weighting. (grasping for a good descriptive term here!)

The more aged coins this BitID user controls, the more likely they are to be a unique person. It's just a weighting - let site operators make use of it any way they wish.

[EricKennedy]

By comparison, what I'm suggesting:
* requires the client to simply have some signatures which prove control of funds, nothing more. The BitID authentication remains very simple (just a few extra bytes to transmit.)
* client requires no hot wallet, no knowledge of blockchain, makes no transactions.
* requires new users to simply have a bitcoin balance somewhere, which most already do (even cold storage - as long as they have access to the private key to sign their BitID to prove control of funds.)

For practical purposes, users will sign in with BitID using their wallet (the need of downloading a specific app defeats the purpose of easy integration). Therefore, if you want to show a proof of stake to the service, you'll need to have the private key on your wallet. So you can't use a cold wallet (by definition it's not cold anymore as soon as the private key is leaked anywhere).

The proof of stake has to be done by the server, which means the BitID server library will have to either integrate a full Bitcoin node, either use an API such as blockchain.info to get all needed information. This cannot be done by the wallet, as the service can't trust it (you could fork a wallet and patch it to send whatever proof of stake you want).

I like the idea of proof of stake as a spam fighting technique ; it could be quite effective.
I'll think about how I could integrate a first version in the BitID ruby gem. I'm just not sure if proof of stake could be computed from the blockchain.info API.

Eric

[NanoAkron]

By comparison, what I'm suggesting:
* requires the client to simply have some signatures which prove control of funds, nothing more. The BitID authentication remains very simple (just a few extra bytes to transmit.)
* client requires no hot wallet, no knowledge of blockchain, makes no transactions.
* requires new users to simply have a bitcoin balance somewhere, which most already do (even cold storage - as long as they have access to the private key to sign their BitID to prove control of funds.)

For practical purposes, users will sign in with BitID using their wallet (the need of downloading a specific app defeats the purpose of easy integration). Therefore, if you want to show a proof of stake to the service, you'll need to have the private key on your wallet. So you can't use a cold wallet (by definition it's not cold anymore as soon as the private key is leaked anywhere).

The proof of stake has to be done by the server, which means the BitID server library will have to either integrate a full Bitcoin node, either use an API such as blockchain.info to get all needed information. This cannot be done by the wallet, as the service can't trust it (you could fork a wallet and patch it to send whatever proof of stake you want).

I like the idea of proof of stake as a spam fighting technique ; it could be quite effective.
I'll think about how I could integrate a first version in the BitID ruby gem. I'm just not sure if proof of stake could be computed from the blockchain.info API.

Eric

Please don't use a proof-of-stake system to 'trust' users like one of the previous respondents suggested.

Think about it on a fundamental level - he's asking you to trust wealthier people, or people who haven't touched their savings in a long time, more than the average user. This is just wrong.

[laurentmt]

Completely tangential use case sorry. If the user is paying you for goods/service then you don't care if they do it 100x - as long as they're paying you every time. When was the last time you typed in your visa card number and then got presented with a CAPTCHA? The fact that you've just presented payment is all the proof most people want that you're serious about the transaction.

Well, for me, the important question is not when was the last time I typed personal data on a website but how many times I did it. And the answer is far too many. 

But you've got my point ! For transactions with e-merchants, I see BitId as a great way to prove that I own the rights to do (get, check, ...) something because there's a validated transaction and I can prove that I own a private key associated to an input address without leaking any other personal data. In this schema, an input address is like a token of ownership for a digital (or physical) good and BitId allows the exchange of this token in a very easy way.

My take is that in real life, most of the time we buy things without having to leak personal data and it should be the same in the digital world. I'm one of those guys who think that we've, far too much, let e-giants gather our personal data without even discussing about the value of these data and the services they provide (basic principle of a free market). But well, this is another discussion... 
So, I wouldn't say this use case is tangential (I hope paiement of goods with bitcoin will become more and more mainstream) but I agree to say it's the easiest one to solve.

On its side, your schema seems interesting for the very different use case of forums / community websites which is more related to addresses as tokens for identities. It creates a very strong constraint with the age of bitcoins but as you wrote this constraint is the incentive to play fair. That's ok. My main question about this system would be : Do I have the same pressure/constraint if I'm a "rich" user (with lot of bitcoins in many addresses) or if I just have a few bitcoins ? To state it differently: Does user's stake really prove the goodwill to play fair ? I don't know the answer.

Imho, BitId should stay at a low level and provide generic implementations allowing exchange of tokens (signatures) between the user and the website. The fact that we imagine so different (but legitimate) use cases is for me a good indication that websites should be free to choose or implement the solution that best fit their needs to validate that a user creating an account is not a rogue player.

Anyway, it's nice to discuss these different schemes and how something like bitcoin and bitid could improve the actual systems.
My two bits.

[EricKennedy]

Think about it on a fundamental level - he's asking you to trust wealthier people, or people who haven't touched their savings in a long time, more than the average user. This is just wrong.

All blockchain based spam prevention ideas I have seen are based on the necessity to spend some amount in order to get full access to services.
So yes, wealthy people could spam more, but this is a fact of life.

It's not about saying that money equals trust, it's about adding cost to abuse.

[gacrux]

For practical purposes, users will sign in with BitID using their wallet (the need of downloading a specific app defeats the purpose of easy integration). Therefore, if you want to show a proof of stake to the service, you'll need to have the private key on your wallet. So you can't use a cold wallet (by definition it's not cold anymore as soon as the private key is leaked anywhere).

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.)

The proof of stake has to be done by the server, which means the BitID server library will have to either integrate a full Bitcoin node, either use an API such as blockchain.info to get all needed information. This cannot be done by the wallet, as the service can't trust it (you could fork a wallet and patch it to send whatever proof of stake you want).

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 like the idea of proof of stake as a spam fighting technique ; it could be quite effective.
I'll think about how I could integrate a first version in the BitID ruby gem. I'm just not sure if proof of stake could be computed from the blockchain.info API.

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.

[gacrux]

Think about it on a fundamental level - he's asking you to trust wealthier people, or people who haven't touched their savings in a long time, more than the average user. This is just wrong.

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.

[gacrux]

On its side, your schema seems interesting for the very different use case of forums / community websites which is more related to addresses as tokens for identities. It creates a very strong constraint with the age of bitcoins but as you wrote this constraint is the incentive to play fair. That's ok. My main question about this system would be : Do I have the same pressure/constraint if I'm a "rich" user (with lot of bitcoins in many addresses) or if I just have a few bitcoins ? To state it differently: Does user's stake really prove the goodwill to play fair ? I don't know the answer.

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.

[gacrux]

It creates a very strong constraint with the age of bitcoins but as you wrote this constraint is the incentive to play fair. That's ok. My main question about this system would be : Do I have the same pressure/constraint if I'm a "rich" user (with lot of bitcoins in many addresses) or if I just have a few bitcoins ?

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.)

[laurentmt]

All blockchain based spam prevention ideas I have seen are based on the necessity to spend some amount in order to get full access to services.
So yes, wealthy people could spam more, but this is a fact of life.
It's not about saying that money equals trust, it's about adding cost to abuse.

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. 

[NanoAkron]

It creates a very strong constraint with the age of bitcoins but as you wrote this constraint is the incentive to play fair. That's ok. My main question about this system would be : Do I have the same pressure/constraint if I'm a "rich" user (with lot of bitcoins in many addresses) or if I just have a few bitcoins ?

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.)

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.

[gacrux]

- Am I right if I say that in this system, stake is validated only one time when creating the account ?

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.

- Who generates what you've called the BitId QRSTUVWXYZ (user or website) ?

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.)

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 ?

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.

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).

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.

[gacrux]

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.

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.

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.

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.)

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.

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

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

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.

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

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.

Not a trust system.

[NanoAkron]

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.

[gacrux]

@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.

[laurentmt]

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 !

[laurentmt]

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.

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).

[EricKennedy]

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

[Mitchell]

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