Closed kylekrieg closed 9 months ago
mbridak
commented
1 year ago Okay, do you have an RFC going for this? Maybe RFC-599, just a suggestion. Can I assume each contest sponsor would run a centralized blockchain? What happens to people who operate in a contest without an active internet connection? If the QSO is authenticated in real time, wouldn't the contester know that a contact made was not correct and give them an advantage?
kylekrieg
commented
1 year ago All valid points. A few comments, but not all answers to your questions. No RFC. I'm not a programmer and have no idea how RFC's work, other than what the acronym means, so I'll need to do a little research before fully answering.
1) I'm not that versed in Blockchain to really answer this question on the best approach. I'm assuming there is probably a YouTube video I can watch to figure out the different methods on how to implement a Blockchain solution.
2) Operators not connected to the internet would be an issue. We'd have to draw a line in the sand and say any paper or digital Cabrillo log you submit will be used as a check log. I see this as no different when the Cabrillo file format was adopted and actual paper logs were phased out. It's the contest sponsor to determine the rules of submitting a log and what they will accept.
3) In a typical contest, if your Q times/calls/exchange match up within a 10 min time frame on each side, the Q counts. The ethics of contesting say you can modify your log up to the end of the contest and then no modifications. This is all is on the trust of the operator. I guess you could do this 1 of two ways. Make a new rule within the contest saying can make modifications up to 10 mins after a Q is made. After that time period, if the fields don't match up, it's a busted Q. OR....you reconcile all the Q transactions after the contest is done. Not sure if that's something Blockchain can do, but just a thought.
Lot's of stuff to sort out. I had a fiery conversation with a contest club this week and one of the members really had some strong opinions on why this and some of my other ideas would not work. My reaction to that line of reasoning is we build this whole framework that uses existing contests and Q exchanges but we are not playing by the old rules. We run new rules, new overlays, new concepts, but we just keep the tradition of using RF to exchange the info needed to make the Q and log the contact.
mbridak
commented
1 year ago The RFC comment was mainly a joke. Almost... What your doing now IS an RFC.
I can see a time where a multi-multi has an ISP outage during a contest. Then they're dead in the water thru no fault of their own.
kylekrieg
commented
1 year ago True, but so is a HD crash for a SO1V or SO2R operator. Game over. Lot's of "what if's" out there. That's where maybe you have an extra computer logging Q's via UDP broadcasts or you hotspot your phone to get an internet connection to finish the contest.
ftl
commented
1 year ago We need a better solution where I know the outcome of a contest the second a contest is over. Blockchain technology can help with this problem by authenticating QSO's in real time.
@kylekrieg can you be more specific about the actual problem you want to solve? Is it about the amount of time you have to wait until the results of a contest are available nowadays? Or is it about preventing modifications (or "optimizations") of log files after the contest?
kd9lsv
commented
1 year ago @ftl It is a really both problems having one major goal.
The steps to minimize this delay (in order of biggest impact)
Log Checking is still partly done by closed-source software & manual intervention (checking for common names in SSB, Rubber Clocking QSOs, ...) If someone has seen an open-source log checking implementation I would like to see it.
Making Electronic Log Submission a requirement like CQ did would allow log checking even at the end of a contest to take no more than a few minutes even with the millions of QSOs made in a CQWW for example by using the cloud. (Side note WRTC, figures out the results in 24 hours after IARU so it shouldn't be difficult for other contests.)
Log Submission being automatically submitted throughout the contest would allow the contest online scoreboard to not just have people's raw score but also denote the % of QSOs confirmed/accurate.
A baby step might be with the ability at the end of the contest to have a pop-up stating "Please click yes to submit final log to contest sponsor" to not have people wait a couple of hours to submit after a long contest (dinner, ...).
Missing access to Internet during/immediately after the contest would also cause some delays but still not in magnitudes of Log Checking.
ftl
commented
1 year ago So this is not so much about a lack of trust, but rather more about enabling and motivating contesters to turn in their logs sooner and also to make the contest evaluation process more open and transparent. Blockchain is a tool for creating trust without the need for a central authority.
IMHO there are two aspects that need to be addressed:
On the technical side there needs to be infrastructure to accumulate the data and make it publicly available. It must be easily accessible to the contesters, the contest organizers, and the developers of contesting software. Open APIs and data formats are mandatory for this. https://www.3830scores.com, http://contest.run, and https://contestonlinescore.com are examples for already existing platforms that could probably be developed in this direction.
Besides that there are a lot of things to sort out on the organizational side:
You have a very valid point here, and I think real time reporting done right could enrich the contesting experience. It needs to be discussed in a wider audience to gain momentum.
73! Florian
kd9lsv
commented
1 year ago Florian,
You hit the nail on the head. Note after the discussion that @kylekrieg had at the contest club, one of the people there decided to put together an Groups.io reflector to allow a bit of broader reach as well a broadening the scope of this discussion (Creating commentary and potential live-streaming like other e-sports, in addition to what we have discussed above).
Lets move this discussion over there as we need to make this visible with many others not focused on not1mm (and also stop pinging @mbridak emails for stuff not directly to not1mm =]). I do believe that people that are in this community (amateur radio software development mixed with contesting background) are the people that see the benefits to the goal above and can provide ideas and feedback to meet it while allowing the original heritage of RadioSport to still shine.
73, Connor
qsantos
commented
1 year ago tl;dr: blockchain won't help with contest scoring; but we could definitely develop a more real-time protocol, and we could even use modern cryptography to validate QSOs instantly
I'd like to chime in on the aspects related to blockchain and digital trust in general, since I do know a fair bit about that. There does not seem to have been much more discussion on the technical proposal in the mailing list, so I will just comment here to make it more accessible for other people finding this thread.
First, blockchain is not about trust. It is about fully decentralized consensus. Let's unpack this:
In all of this, there is no concept of identity or trust, just consensus. In the case of Bitcoin, we just need an additional thing to make things work: cryptographic signatures. Each user will have a “public key” and a “private key”, which are mathematically related. The public key of a user is not sensitive. Only the user knows their own private key. And you cannot find the private key from the public key. In the case of Bitcoin, money is “sent” to a public key. To spend it, the user must use the corresponding private key. Cryptographic signatures have nothing to do with blockchain itself.
The catch is that, in most cases, you do not actually need to work in a fully decentralized context.
What does this mean in practice here?
It means that blockchain does not help us ensure the validity of contest log entries. In other words, anyone could send contest log entries as anyone. If A1AAA wants to win the contest, they can easily create tens of thousands of QSOs by pretending to be many other operators. For instance, A1AAA would send a log where they say they have contacted B2BBB, C3CCC, D4DDD. Then, they would pretend to be B2BBB and send a log where they say they have contacted A1AAA, then they would impersonate C3CCC, D4DDD, …
All that blockchain itself would give us is “consensus”. In other words, we can all agree it what order A1AAA reported the contacts, which is not really useful here.
How are currently avoiding this situation?
First answer: we don't. From my understanding, most contest do not perform any kind of authentication of the log, and rely on honesty. Correlating logs together allows eliminating mistakes, and basic attempts at cheating, but not the scenario I described above. Most of the time, contest ranking does not matter very much. And when it does (top few places), cheating would probably be detected easily, if the operators of the spoofed QSOs notice and notify the contest.
Second answer: We have a PKI. There actually already exists a pretty solid piece of architecture to authenticate logs: LotW and TQSL. LotW acts as the main authority to authenticate hams, which gives us a PKI. It does so with standard cryptographic certificates. TQSL then uses these certificates to cryptographically sign the log before sending it to LotW. Since these are standard cryptographic certificates, we can use them for other things. I myself had a bit of fun toying around with authenticating over HTTPS without encryption (so that you can use it with AMPRnet), and without a password (since there is no encryption).
Anyway, from the first answer, we can see that digital trust and authentication is not needed. So we could focus on designing a real-time protocol to send QSOs in real-time instead of manually sending a file through a web form after the contest. From the second answer, we can see that we can actually implement digital trust and authentication if we want, and we already have the PKI to do so. In any case, we do not need a blockchain.
Current contesting does not allow for "real time scoring". You must complete the contest, export your log, send the Cabrillo file to the contest sponsor and wait X amount of months for the results. This method was great in the early era of technology, but with the rise of video games, online streaming and the internet, there is a need for real time scoring to keep the younger generation engaged in contest.
We need a better solution where I know the outcome of a contest the second a contest is over. Blockchain technology can help with this problem by authenticating QSO's in real time.
Integrating this technology in modern contest loggers is a must. It can be done in parallel to submitting Cabrillo files, but needs to be mandated by a future date for us to move technology in the contesting world.