Replies: 9 comments
-
|
Okay, do you have an RFC going for this? Maybe RFC-599, just a suggestion. |
Beta Was this translation helpful? Give feedback.
-
|
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
@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? |
Beta Was this translation helpful? Give feedback.
-
|
@ftl It is a really both problems having one major goal. Moderinze RadioSport due to the technology advances.Results taking a long time to be finalized.The steps to minimize this delay (in order of biggest impact) 1. Log CheckingLog 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.) 2. Log SubmissionLog 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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Florian, You hit the nail on the head. 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, |
Beta Was this translation helpful? Give feedback.
-
|
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. What Blockchain IsFirst, 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. Why not Blockchain for Contest LoggingWhat 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. What We Can DoHow 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. |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions