New opt-in permit issuance mechanism in BitPeople

Hi, if sharing dApp content is allowed here (had a post deleted a while back, I post maybe once a year, but have been public with that Craig Wright was clearly Satoshi, for example, and that is tabu on this subreddit), BitPeople has closed a minor attack vector now that has been known for many years (mentioned in 2018 whitepaper, and in documentation since) but was never an imminent problem, and I did not find the right defense to it until now.

The attack vector:

Collusion attacks are when x% collude, and get x%^2 pairs with 2 colluders. This sustains roughly 1+x% more PoUH for colluders than otherwise.

A simultaneous attack is possible by attacking the opt-in mechanism at the same time, to get fake opt-in requests in pairs controlled by colluders. The solution to it is to limit colluder access to opt-in permits.

The solution:

Opt-in permits are now issued by a form of vote, plus randomization. Anyone can issue 1 each event. Every permit issued is issued to a random person (that can use it to invite a new person. ) Colluders themselves cannot easily acquire permits, as they only get a fraction of what they could get issued with their votes. This keeps attack potential minimal. Negative votes also exist, if colluders were to attempt to attack anyway, and it closes the attack vector entirely.

The code:

The function borderVote() does everything, see source code at the bottom of the whitepaper.

Many transactions:

As anyone can see the protocol is very transaction-heavy. Each user has to issue multiple transactions per month, and it in the long term (a decade, maybe more) aims to have 8 billion users. So, digital ledgers will have to improve for that to be realistic. For this particular borderVote() mechanism, I would probably use an automated external contract to the main contract that controls that, for my own account. BitPeople itself does not dictate how to do that.

Whitepaper:

http://bitpeople.org/