Und dann war da doch noch... die Blockchain!
Dieser Mystery ist in zwei Punkten speziell:
- Es wird genau erklärt, was gemacht werden muss
- Ihr seid angehalten, Eure Lösung im Online-Log zu erwähnen
Worum geht's ?
Ein Grossteil wird schon mal von der Blockchain gehört haben - vermutlich im Zusammenhang mit den ominösen Bitcoins. Schlussendlich ist die Blockchain aber nichts anderes ein ein Transaktionslog. In einem Transaktionslog werden... nun ja... Transaktionen aufgezeichnet - sinnvollerweise chronologisch. Je nach Einsatzgebiet können das Messdaten von Sensoren, Daten zur Verfolgung von Lieferketten oder - wie im Fall der Bitcoins - Daten zu Geldüberweisungen sein. So weit, so gut...
Wenn der Blockchain eine neue Transaktion hinzugefügt werden soll (üblicherweise werden mehrere Transaktionen in einem Block zusammengefasst, daher der erste Teil des Namens), muss diese zuerst validiert werden, bevor sie definitiver Teil der Blockchain wird. Die ist erforderlich, weil die Blockchain typischerweise auf einem öffentlich zugänglichen System von unterschiedlichen Parteien nachgeführt wird. Mit der Validierung wird somit verhindert, dass die Blockchain unrechtmässig manipuliert wird.
Zu diesem Zweck wird über eine kryptographische Funktion eine 'Prüfsumme' berechnet; ein sogenannter Hash. In diesen Hash fliessen sowohl die relevanten Daten des neuen, zu validierenden Blocks (beispielsweise Beträge, Absender, Empfänger) als auch der Hash des letzten gültigen (also bereits früher validierten) Blocks der Blockchain. Dadurch werden die einzelnen Blöcke miteinander verkettet.
Der Trick dabei ist, dass im Log nun keine Informationen mehr verändert werden können, da sich dann auch der Hash dieses Blocks ändern müsste. Da dieser aber wiederum bereits in den Hash des nächsten Blocks eingeflossen ist (und dieser wiederum in den Hash des übernächsten Blocks etc), müssten nun alle Hashes ab der veränderten Transaktion neu berechnet werden.
Um dies zu verhindern, wird die Berechnung des Hashs künstlich erschwert. Es wird beispielsweise festgelegt, dass der Hash mit einer bestimmten Zahlenfolge beginnen muss, um den Block validieren zu dürfen. Dazu können in der Transaktion ein paar eigens zu diesem Zweck reservierte (und ansonsten aber irrelevante) Bytes beliebig verändert werden, die sogenannte Nonce. Wenn der berechnete Hash nicht den Vorgaben entspricht, wird die Berechnung mit einer geänderten Nonce erneut versucht... und erneut... und erneut... und erneut...
Falls ich - irgendwann - doch tatsächlich einen gültigen Hash gefunden haben sollte, darf ich ihn jetzt der Blockchain hinzufügen und die so signierte Transaktion ist nun gültig. Bei der Bitcoin Blockchain würde ich dann übrigens eine kleine Belohnung (in Form von Bitcoins) erhalten, weshalb dieser Prozess auch Mining (Schürfen) genannt wird - obwohl es im Kern eigentlich (nur) darum geht, Überweisungen zu validieren und diese schlussendlich manipulationssicher zu speichern.
Der gültige Hash ist der Nachweis, dass ich eine (nicht unerhebliche) Rechenleistung aufgebracht habe - der sogenannte Proof Of Work - oder eben der Arbeitsnachweis.
Wem das nun alles etwas zu viel geworden ist, dem danke ich ganz herzlich für die Aufmerksamkeit und empfehle aufrichtig, sich nun einem anderen Cache zuzuwenden.
Für alle anderen geht's hier - stellenweise etwas technischer - weiter... 
Die Verkettung
Wir basteln uns nun eine vereinfachte Blockchain. Die Transaktionen sind die Logs in diesem Listing. Um zu den Koordinaten zu kommen, müsst Ihr das aktuellste (oberste) Log in diesem Listing validieren (dies entspricht also quasi dem Block, den wir der Chain hinzufügen wollen).
Um unnötige Dramen mit Sonderzeichen zu vermeiden, berechnen wir den Hash deshalb nur über die folgenden einfachen Attribute, die Ihr dem zu validierenden (also letzten) Logeintrag entnehmen müsst:
- Log ID
- Cache ID
- Account ID des Loggers
Dazu könnt Ihr entweder das JSON Objekt im HTML Datenstrom oder die entsprechenden Elemente im GPX auslesen:
JSON Beispiel:
{"LogID":811800651,
"CacheID":3339524,
...
"AccountID":1037696,
...
}
GPX Beispiel:
<groundspeak:cache id="3339524" ...>
<groundspeak:log id="811800651">
<groundspeak:finder id="1037696" ...>
Nun müssen wir natürlich noch den Hashcode des vorangehenden (also vorletzten) Logeintrags berücksichtigen, um eine Verkettung zu erzeugen. Dummerweise haben Geocache Logs keinen Hash (ist ja auch keine Blockchain), weshalb wir dort ersatzweise die "Log ID" notieren:
JSON Beispiel:
{"LogID":792502116,
...
}
GPX Beispiel:
<groundspeak:log id="792502116">
Diejenigen, die das Rätsel direkt nach der Publikation lösen, validieren somit den "Publish Listing" Eintrag des Reviewers. Dieser folgt einem "Write note", der den sogenannten GENESIS Block einer jeden Blockchain darstellt.
Die oben aufgeführten Werte werden nun in einen simplen Textstring überführt (die eckigen Klammern werden zur besseren Lesbarkeit beibehalten):
[LogID][CacheID][AccountID][LogID-Vorgänger][Nonce]
Mit den oben aufgeführten Beispielwerten ergibt sich somit dieser Textstring, der symbolisch die zu validierenden Transaktionsdaten darstellt.
[811800651][3339524][1037696][792502116][Nonce]
Proof Of Work
Über diesen Textstring ermitteln wir nun den Hash. Als Hash-Funktion verwenden wir SHA-256.
Die Nonce im letzten Element ist maximal 30 Zeichen lang und sollte aus lesbaren Zeichen bestehen, sonst könnt Ihr den Hash anschliessend nicht online validieren.
Ihr verändert nun die Nonce so lange, bis ihr einen Hash erhaltet, der in der üblichen HEX-Darstellung mit 000000 beginnt (also drei Nullbytes, bzw 24 Nullbits). Dies ist die weiter oben erwähnte Erschwernis. Die statistische Chance dazu liegt bei 2^24 - also bei genau 1:16'777'216
Für das oben erwähnte Beispiel wäre dies übrigens eine mögliche gültige Nonce:
[811800651][3339524][1037696][792502116][AAIaJeS]
Der daraus resultierende SHA-256 Hash sieht nämlich so aus (und erfüllt somit die Vorgabe der 6 führenden Nullen):
0000006C35CD5D8A81B51957A1D5C98E49A44D0C9E80F295318DED828455A9D9
Verifikation
Falls Ihr eine Nonce gefunden habt, die einen gültigen Hash erzeugt, validiert Ihr Euer Ergebnis HIER.
Achtung: Obiger Link führt zu einer externen Webseite mit weiteren Details, die zum Finden des Geocaches benötigt werden. Als der Cachebesitzer versichere ich, dass diese Seite ungefährlich ist. Die Seite und ihr Inhalt sind nicht von Groundspeak oder einem Geocache Reviewer auf schädlichen Inhalt überprüft worden und die Seite wird auf eigene Gefahr besucht.
Wenn alles passt, erhaltet Ihr direkt die Finalkoordinaten.
Fügt Eurem Online-Log doch bitte den vom Online Validator angezeigten Eingabetext (inklusive Nonce) an. Hier dürft Ihr also erstmals Eure Lösung publizieren! Der beste Beweis, dass Ihr den Cache selbst gelöst habt - euer ganz persönlicher Arbeitsnachweis! Die von Euch publizierte Lösung kann ab diesem Zeitpunkt logischerweise nicht mehr verwendet werden, da die Nachfolger ja nun wiederum Euer Log validieren müssen.
Brute Force
Ganz klar... der Proof of Work basiert auf simplen Brute Force Verfahren. Deshalb verbrauchen die Miner ja auch unglaubliche Mengen an Energie. Das Brute Force Verfahren findet aber bitte lokal auf Eurem Rechner statt - und nicht via HTTP-Requests auf die oben erwähnte Webpage. Diese wartet genau aus diesem Grund jeweils gemächliche 10 Sekunden, bis sie Euch das Ergebnis anzeigt.