DESIGN -As a moderator, I want a mini CLR monitor sybil/collusion attack dashboard so i can see whether mini CLR is being sybill or collusion attacks

[owocki]

User Story

As a moderator, I want a mini CLR monitor dashboard so i can see whether mini CLR is being sybill or collusion attacks

Why Is this Needed

Summary:
bc anti sybil is an ongoing problem

Description

Type:
feature

Current Behavior

no dashboard

Expected Behavior

a dashboard that is

• moderator only
• available on gitcoin.co under gitcoin.co/modtools (also moderator only page)
• displays all tips in a mini CLR round
• u can navigate by the different match rounds, the data will be loaded from https://github.com/gitcoinco/web/blob/master/app/townsquare/models.py#L335
• for each match round you can see tips with the following columns: pk, created_on, from user info (handle, avatar, account age, ip address, location, ethereum address, account card info (the same card that @octavioamu deployed to town square), to user info (handle, avatar, account age, , ip address, location, ethereum address, account card info (the same card that @octavioamu deployed to town square)
• flag button that when clicked acts similr to the gitcoin grants flag button (allows moderator to write a report about a sybil attack, which is stored in the DB + then emailed to kevin@gitcoin.co)

Additional Information

original CLR attackable spec : #6179

this scope is for mini CLR, but could be re-used for grants CLR

[owocki]

@molecula451 @oussema feedback on this?

[frankchen07]

hm could be useful for regular CLR too. I can jerry-rig something in metabase (show txns for ones made by day or something), but having something less psql db-like would be nice

maybe we can tack this onto ben difrancesco's work?

[oussema]

I think we need to focus on account age, sybill attacks are generally done by fresh accounts, to make a dashbord for monitor is a good idea, but it will be nice if you get more info from Github accounts, there are many github accounts created recently without any project or with only forked projects which means that they are 90 % fake, so it's possible to add information about their github account age ?

[molecula451]

I would opt for the fulfilled bounty model object playing a key role on this one. Some user that are not willing to contribute or to even come back to the site at least 1 bounty, 1-3 bounties could potentially prove reliability, user activity and engage on the site hence preventing sybill (for users that do not show something reliable on github) the pop-over card that @octavioamu deployed contais this very reliable info for users "on the site"

The motto is about "Grow Open Source" I will assume Owocki doesn't want to discard any potentially collaborative, future, well behaviour users just because their account it's new on "Github"

Hence show me what you got (by metrics) and I'll tell you what you get important key. Trust in the metrics of https://gitcoin.co

[oussema]

the problem for me is simple, for example the next CLR round starts June 15th, til this date , I'll create one account each day, and each hour I'll choose an account to connect with and participate to bounties and help people, with this method I'll make those accounts look like they real accounts.

Let's assume that til the June 15th I'll create 30 accounts, let's assume also that I used this method in the previous 5 CLR Rounds , That it means that on June 15th I'll have 180 accounts created by the same person ( 5 * 30 + 30 =180 accounts).

If a sybill attack wil be launched by those accounts , every account contribute to same grant by 10 Dai , we could estimate at least 3000 Dai of CLR match ( I estimate this CLR from the distribution of the CLR round 5 @owocki ).

It's better now to find a solution to prevent this kind of attacks, you see what I want to say @molecula451 ? and the problem it's more dangerous because it's like snowball effect, the next CLR there will be 30 other accounts , and the next one and the next one ...

[molecula451]

Could you perhaps capture user's browser fingerprinting on that dashboard

[molecula451]

the problem for me is simple, for example the next CLR round starts June 15th, til this date , I'll create one account each day, and each hour I'll choose an account to connect with and participate to bounties and help people, with this method I'll make those accounts look like they real accounts.

Let's assume that til the June 15th I'll create 30 accounts, let's assume also that I used this method in the previous 5 CLR Rounds , That it means that on June 15th I'll have 180 accounts created by the same person ( 5 * 30 + 30 =180 accounts).

If a sybill attack wil be launched by those accounts , every account contribute to same grant by 10 Dai , we could estimate at least 3000 Dai of CLR match ( I estimate this CLR from the distribution of the CLR round 5 @owocki ).

It's better now to find a solution to prevent this kind of attacks, you see what I want to say @molecula451 ? and the problem it's more dangerous because it's like snowball effect, the next CLR there will be 30 other accounts , and the next one and the next one ...

All that points out oussema is very accurate. But in fact. How would I be able to age an account for a CLR matching if haven't complete at least 1 bounty yet! and If I am serious on the site why would I bother in aging many accounts - completing many bounties (it's irrational)

[molecula451]

Let's suppose I have 5 virtual machines deployed with all different user devices/OS.. for each instance I would create a github account for each because I found tasty the CLR matching on Gitcoin. I will age them. But haven't succeed in found a liquidity funder, in fact, nobody have approved to work that certain "new" account to start bounty because funders still do not trust because of new account metrics.

Me being the attacker. Shall I throw-time in waiting to age the accounts by completing bounties one by one and then pretend to make an attack? I would be 6 CLR rounds late some months lost

trust fulfilled bounties

[oussema]

That's right ! if we will use the number of a fulfilled bounties as a metric, to tip grants or other person in mini-CLR , will minimize the effect of the Sybill Attack. And I think for the future , KYC is necessary to controbute to a grant , $250K in each round it's money !

[L-KH]

I am not sure if the number of fulfilled bounties is a good metric for that. we will take an example of a youtube channel grant that invites their subscribers to join the grant and tip only 1DAI. how can that happen if those subscribers are totally new or the first time to use Gitcoin?

[molecula451]

I am not sure if the number of fulfilled bounties is a good metric for that. we will take an example of a youtube channel grant that invites their subscribers to join the grant and tip only 1DAI. how can that happen if those subscribers are totally new or the first time to use Gitcoin?

Not to be confuse, that metric would be for mini-CLR

[owocki]

I think we need to focus on account age, sybill attacks are generally done by fresh accounts,

This is true right now, but only for unsophisticated attackers. Will change over time I bet

I would opt for the fulfilled bounty model object playing a key role on this one.

I think this is an elegant step forward, but I worry about the user onboarding costs. Its very easy to send/receive a tip. Bounties are 10x harder to do.

Could you perhaps capture user's browser fingerprinting on that dashboard

UserAgent maybe but its easily foolable.

---

One suggestion that came out of the recent Gitccoin livestream was using SMS numbers as proof of unqiue human.

Btw have you guys read this? Very good canonical source of truth on collusion /sybil attacks https://vitalik.ca/general/2019/04/03/collusion.html

[L-KH]

I think we need to focus on account age, sybill attacks are generally done by fresh accounts,

let try to think like an attacker. I will create right now many accounts for example 10 accounts. and wait like 1month and then use them to attack in future CLR.
so I think further age, we have to check the address of new accounts and see the first transaction. attacker for sure he will need some amount in a new account to send tips(attack). so if we find collusion in a new account and the old one in the first transaction of the new one. then we have to make those accounts on the scope.

One suggestion that came out of the recent Gitcoin Livestream was using SMS numbers as proof of unique human.

good one. even there is a possibility to create many numbers (there is some services on telegram like this, but not free). so perfect solution is to fusion (age, first transaction, SMS)

[owocki]

yeah i wondered about that too. asking on twitter here https://twitter.com/owocki/status/1254756810092802049

…

On Mon, Apr 27, 2020 at 6:55 AM Lahcen-KH ***@***.***> wrote: I think we need to focus on account age, sybill attacks are generally done by fresh accounts, let try to think like an attacker. I will create right now many accounts for example 10 accounts. and wait like 1month and then use them to attack in future CLR. so I think further age, we have to check the address of new accounts and see the first transaction. attacker for sure he will need some amount in a new account to send tips(attack). so if we find collusion in a new account and the old one in the first transaction of the new one. then we have to make those accounts on the scope. One suggestion that came out of the recent Gitcoin Livestream was using SMS numbers as proof of unique human. good one. even there is a possibility to create many numbers (there is some services on telegram like this, but not free). so perfect solution is to fusion (age, first transaction, SMS) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6492 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD5PCOSWGGRYLV7GKLLF6DROV6DZANCNFSM4MOMS2TA> .

-- @owocki <http://www.twitter.com/owocki>

_________________________________________ gitcoin is live and has generated over $4.0mm for Open Source Software - see our results <https://gitcoin.co/results>