search

deltapi / abc-feedback

Collection of bugs and Feedback regarding the abc triple search on https://abc.tngtech.com
7 stars 0 forks source link

Check validity of submissions #20

Open dnevill opened 3 years ago

dnevill commented 3 years ago

Reposting this comment from Matt Parker's patreon post when he was asking for some testing before the video went live: Since it looks like all the processing is done client side, thought I'd do a test to see if it will store incorrect solutions if a nefarious party were to muck about with it. So if there's nothing on the server side that checks if a submission is valid you may have both some normal looking results and one particularly dessert-like result stored under the name "Pi Test Server Side Check".

I didn't get any error messages client-side to suggest that the submission was rejected, though I suppose its possible such a check is in place and simply doesn't alert the end user that they were rejected.

JohnyDL commented 3 years ago

I did mention in #1 server side and/or client side verification would be a good move too

deltapi commented 3 years ago

Hey, thanks for your input. I am curious how client side verification would look like, as the client is (hopefully) computing only valid exceptions to the conjecture. Server-side verification is not yet in place, however, the amount of data to be verified is not yet overwhelming.

JohnyDL commented 3 years ago

Proposed client side verification idea: Client Requests New Rad(a), Rad(b) Server Replies with New Rad(a) range, New Rad(b) range, AND selected Triple(s) from database (where confirmed count < n) Server increments Triple's confirm request count by 1 for each triple it's sent out (server can send out fewer triples when server load is higher and more triples when server load is lower) Client tests specified Triple(s) and range as per the normal algorithm Client returns any new triples tag "new" and confirmed triples tag "old" and their name Server adds all new triples to the database. Server looks up old triple(s) in the database, if Name of originator != name of confirmer then confirmed count +1, else request count -1. If confirmed count*n < request count then server-side check that triple (probable fake triple that needs removing from database as very few clients have confirmed it) If confirmed count > request count then server-side check that triple (possibly fake triple being confirmed by clients which weren't allocated this triple to be checked)

It is far from perfect (there will inevitably be cases where a confirmation was lost by chance) but assuming that the majority of clients are behaving ethically it'd be hard for any one client or small collection of clients to sufficiently mislead or game the whole system (and you're always server-side checking potential errors before excising them (though this list is much much smaller than having the server test every single one)) This is especially true as you spread out the confirmations out over increasing amounts of time you don't ask every client to confirm the first triple until a level of confidence is reached then move onto the next but you do them in sequence... perhaps something like https://oeis.org/A025480 (but drop the first 2^k terms) would visit every integer as many times as necessary eventually.

deltapi commented 3 years ago

We will take that up as soon as possible.