Cholmondely wrote: ↑Sat Oct 16, 2021 6:24 pm
I don't even understand the question. Putting out 2 utterly simplistic oxp's merely means that I can cut and paste from Norby's work with minimal competence. Not that I understand what I'm doing! Sorry.
"Checksumming (verbification of noun "a checksum") is a trick for validating a block of data, to find errors of entry, or deliberate falsification. I was thinking of something to make it harder for a Jameson to claim "I got a 300-system run with 7002 dead pirates before I had my tea-break. Seem my screenshot! Bow in awe!" But I'll come back to that in a bit.
The classic example of a checksup is in your wallet. The 16-digit number on your bank (or credit) card isn't a random number - it includes (and you can probably work this out from just inspecting your purse contents) information about the bank (or credit agency), your account number, possibly the sequence number of the card, and a check-sum. If I recall correctly, AmEx cards all start with a digit 2, for example (it's a long time since I had to deal with an AmEx card - it might have some other characteristic, but for the moment, let's say that). So, if a website is accepting a credit card number, and the "customer" (well, remote web-browser) claims an AmEx card but enters "3xyz pqrs abcd efgh" for the card number, the website's cord can reject that immediately, because either someone is deliberately lying, or has fat-fingered the wrong number in.
Rejecting such erroneous input at the shop's website reduces both the number of enquiries to the bank (AmEx, whoever) which are doomed to failure. More vaguely, this also reduces the "attack surface" of the payments system - there are fewer types of erroneous data that the site has to check for.
Going from the AmEx specific example to the 16-digit card number in general, all the banks have agreed to follow a common rule that there are 15 digits of data (bank sort code, account number, card number, something else) and one "check-sum" digit which is calculated from the rest to give the overall 16 digit number a particular characteristic, which the involved websites can check without raising a request against the actual payment service. Let's say the characteristic is that (for the number above) the sum 3+ x+ y+ z+ p+ q+ r+ s+ a+ b+ c+ d+ e+ f+ g+ h should produce a multiple of 7. Which ever of the numbers p, q, etc is the check digit can be within the range 0 to 9, and make the 16-digit ensemble fit that characteristic with a very low amount of effort. But if the customer invents a 16-digit number it is unlikely to have that characteristic, and if the customer fat-fingers a wrong number in, again the store's website can detect it and require it to be corrected before forwarding a request to the actual bank's website.
"divisible by 7" isn't the actual test used - I never bothered to memorise that datum. But it's a matter of public record. It's probably on Wikipedia somewhere. A few minute's thought will tell you that the "divisible by 7" characteristic couldn't detect someone typing "...pqsr ..." instead of "...pqrs...", which is a very common class of entry error. Passing that public test doesn't guarantee that the 16 digits received by the store's website is a genuine credit card number, but it does filter out common fat-finger errors, and incompetent attackers.
(I think - I've never felt the need to investigate - that the "security digits" (3 or 4) on the back of bank cards also incorporate further check sums, but that
may be different between banks. I'm sure a professional card fraudster would know, but that's not a field I've ever needed. Check-sum technology was part of a Millennium Bug fuck up we had at work, and I spent several years afterwards explaining to customers why we'd suckered them into accepting a "free upgrade" to an absolute Edible Poet of a Windows version of our software. If' they'd kept the old DOS version (and it's "security device") and used it after the Millennium, they'd not have needed to pay another penny in licensing fees to us. Worlds-tiniest-violin.GIF )
Anyway, all of that background aside ...
I had been thinking if there was a way to incorporate some aspects of a series of flights into a hard-to-guess code - such as a checksum - so that a Jameson's claim of performing an extraordinary massacre could be validated. I'm sure there could be such, but since the code for the core game is open source (not so sure if that's always the case for OZPs though?), then any competent cheat would be able to read it, and make their cheat pass the test. So ... meh. It's probably not worth the effort.
Actually, one could possibly get a bit more data to hide in the checksum if you looked at the Oo-StarDate of jumps. Kind of like adding "salt" to your source text before encrypting it. But I doubt it's likely to be worth it. File under "minor issues associated with the multiplayer online version which nobody believes will ever happen" - over in the corner ; circular filing cabinet.
bl@@dy Hell 
