Voting system particulars are opaque to regular users, but visible to developers, since you have open source. So malicious agents will be ready with their bots the moment SN userbase (/daily coin flow) reaches a certain level.
For instance, using a small botnet to create and fund 100 accounts with 1000 sats each (~30 usd cost). Could use this to for instance:
  • Create superpower users. By having all the bots post (chatgpt generated stuff so it's not so obvious), then upvote each others posts (and a few externals, to fuzzy analyis), it seems that the "graph of trust" generated could be gamed such that arbitrary amount of "trust" can be given (or taken away, by flagging/downvoting) to any user.
  • DDos your trust graph (which seems to have O^3 time complexity? So 1 sat/comment -> ~260 USD to make 1M ItemAct (etc) from separate users -> 1 TB adjacency table for trust..) It appears the trust-graph has a heavy recursive algorithm, I don't see any load tests for it but i might be wrong.
  • I haven't looked super deep into the graph construction algorithm so you might have ways to prevent the above. But in case you haven't considered this: Could PageRank fit as an ranking algorithm instead of the graph? You want to give rank to users who zap high quality posts (early), and divide their rank by total number they zap, then rank by how many incoming vs outgoing zaps per user. IIRC it is O(n+m) complexity (n - nodes, m - links).
  • Since Rewards calcs are done at a public, given time every 24hs, the same attack as above, or any other extracted from the source code can be done just before Reward calc to suddenly steal all 21% of posts and get all the rewards. Suggestion: Randomize the times these calculations are performed. Also extract out from open source the "heart" of vote calculation.
  • Generally write load testers for big user influx cases, see what happens.
Pretty much all of this is wrong when it attempts to get detailed. I do think it's a worthwhile lens though and it does suggest a bounty payable reason in our appearance:
The devs are naive
Also go back and study PageRank. What's its runtime complexity? 😉
reply
Is it not then possible to create 1000 bot accounts upvoting each other and gaining trust and using that trust to heavily influence all other posts as well as rewards?
I took a semester studying advanced linear algebra where the end project was building pagerank, it can (obviously) scale to millions and millions of nodes.
The "reason people shouldn't use SN" remains the same: The website has powerusers built in, and as soon as it becomes profitable, all content will be links to blog posts, like I've mentioned was the cause of aggregator Diggs downfall in favor of reddit. Hopefully that is not seen as a naive point to make.
reply
I'm sorry. I realize now that probably came off pretty brash. I was not suggesting you are naive. I was just being blunt because you were being a touch presumptive, but I should be happy you've put in the work that you have and I am. (It's just a lot of work to untangle presumptions and I'm so time-poor that it triggers me. Again, I'm sorry. It's not the person I want to be.)
Is it not then possible to create 1000 bot accounts upvoting each other and gaining trust and using that trust to heavily influence all other posts as well as rewards?
It's not possible the way you describe it. It's likely possible if paired with other exceptional circumstances. It's hard to explain why but the algorithm biases away from trust clusters.
I took a semester studying advanced linear algebra where the end project was building pagerank, it can (obviously) scale to millions and millions of nodes.
Naive pagerank (power method) has a runtime complexity of O(N^2). If you look at our algorithm more closely, you'll see we have O(N^3) because we are effectively running the power method N times.
reply
No worries, I understand as you do that it's hard to give advice to programmers of unknown competence without falling arwy of tending towards either "have you tried turning it on and off again?" or "have you noticed your (publically) cron-jobbed O(n^3) algorithm can be reduced to O(m+n)"? DIdn't mean to come off as concescending with the "you need more tests" comment, I make that observation in nearly every project I consult on.
I believe your business plan and architecture is inherently flawed due to the reasons of power user manipulation I've outlined, but I enjoy your site atm and respect the effort you put in to it. Thanks for your time in responding.
reply
❤️🫂
reply