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

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.

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.

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.

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

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.


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.



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


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.

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.



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.



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

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 !

Benefits :
- I don't need to leak personal informations (login, password, identity, credit card, ...) to watch my movie.
- BitId is "off-blockchain": BitId using addresses already used for paiements does not leak more data into the blockchain.
- The website already knows the tx and the input addresses. BitId does not leak more data to the retailer.

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.

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.

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

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.

Eric

A big problem on the internet today is the cheapness of identity. Many sites struggle with a constant influx of trolls and sock-puppets. We attempt to address this with:
* Forum reputation systems - but there's still no easy way for a new user to prove they have anything invested in their identity.
* The ubiquitous CAPTCHA, just to establish that a visitor is a human - the very lowest bar we can put up, and even that is constantly being eroded, and causes problems for visually impaired users.

If I'm using a bitcoin address to sign in to a website, the site now has some extra information about me:
* the amount of BTC I control with that address
* the coin age

Or, put another way, the site can predict:
* the number of "Bitcoin Days Destroyed" that would occur if I were to hypothetically move the coins to another address I control in a self-payment.

So an address with 2 BTC in it for the last 5 days gets a score of 10, an address with 0.5 BTC in it for the last 21 days gets a score of 10.5, etc.

If this score is high enough you don't need to bother me with a CAPTCHA. You can also initialise forum reputation based on this score, etc etc. It'd be useful for all kinds of applications where anonymous identity is desired but the cheapness of identity creation causes problems (eg. distributed markets?)

Of course, I don't want to keep a significant balance in a wallet accessible by my browser. But I could:
* sign my BitID address with my main (perhaps offline) wallet address(es)
* provide these signatures to the server while negotiating BitID login

The server could then establish a score for my identity (coins in signatory addresses * coin age) - the higher the score, the less likely I am to be engaging in abusive behaviour. If I do engage in abusive behaviour then:
* the server adds all the signatory addresses to a blacklist (either internal, or perhaps shared with other sites somehow)
* assigns a zero/negative score to any BitID that provides any blacklisted signature upon login in future

If I wanted to dodge the blacklist and continue to engage in abusive behaviour, I'd need to move the coins to a new address. This effectively resets my "Bitcoin Days Destroyed" score to zero, and I need to wait for it to accumulate again, thus braking (rate limiting) my behaviour.

How high the bar needs to be (score of 5? 100? 0.1?) would be established by individual site operators for their own sites through trial and error.

Please consider extending your BIP to cover this. It would provide an additional factor to motivate adoption of your authentication scheme for relatively little added cost.

Hi ecrick3,
laurent here (the guy who started to wrote the python implementation). Since the first release on github, I've done some more tests and modifications to strenghten the library. Moreover, there's now a python implementation of the demo app written by EricKennedy in ruby. You can get the code here. I've tried to comment the code as much as possible to illustrate the different steps of the protocol. If you're a python developer and interested to participate in the development, you're also very welcome !

any1 try Python implementation yet?

There is now a Python implementation of the back end library :
https://github.com/LaurentMT/pybitid

Presentation of BitID metadata (leveraging BIP70, allowing 2FA, ...) :
https://github.com/bitid/bitid/blob/master/bitid_metadata.md

This has the potential to bring 2FA-level security to every login, without the need for a centralised service.

If the address is created on the fly at the initial connection request and is therefore not linked to anything, what would be the benefit of using a stealth address ?
I may not correctly grasp the concept of stealth address but I can't see how they could add any privacy advantage in this particuliar setup ?

Did you consider using a stealth address instead of the public address for the initial connection request (which is in plain text) ?

Where is the problem for this solution?

There are more then enough avaible (or dead) auth methods/projects. No need to bloat the Core(!) client with this and no need to waste the time of the core devs.

Code your own tool/client/fork whatever IHMO.

Very good demonstration of a very good idea.

How are discussions progressing with the Core developers to get this pulled into an upcoming version as an additional Core functionality?

Congrats dude! I really hope that more wallets implement it and that websites are going to use it.

Android Bitcoin Wallet has a first implementation of the BitID protocol :
https://github.com/bitid/bitcoin-wallet

A short video showing the user flow :
https://www.youtube.com/watch?v=3eepEWTnRTc

Ok, I cleaned all the confusion about "bitcoin signed message" stuff.
The BIP draft as well as all the code is now much clearer.

So basicaly what you always need to sign is the URI :


The "Bitcoin Signed Message" is integrated into the signing procedure (wallet side) and verifying (back end side).

Thanks for clearing this mess

Eric