Nodesignal-Talk - E232 - PQC3 - Bitcoin-Adressformate und Quantenresistenz - podcast episode cover

Nodesignal-Talk - E232 - PQC3 - Bitcoin-Adressformate und Quantenresistenz

May 23, 20251 hr 21 minSeason 3Ep. 232
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

In dieser dritten und (vielleicht) letzten Folge unserer Quanten-FUD-Reihe tauchen wir erneut tief in die Welt der Quantencomputer und ihre potenzielle Bedrohung für Bitcoin ein. Chris spricht mit Volker_BTC und Effet Cantillon – bekannt aus unserer Episode zu den "21 Millionen Bitcoin" – über die Quantenresistenz der verschiedenen Bitcoin-Adressformate.
Die Folge knüpft direkt an Episode 227 mit Hannah von Tuta und Episode 228 mit Sebastian und Calso an. Falls ihr diese noch nicht gehört habt: Nachholen lohnt sich!
Freut euch auf eine nerdige, spannende Diskussion – inklusive einem augenzwinkernden Investment-Tipp von Volker für den Fall, dass Bitcoin tatsächlich von Quantencomputern geknackt wird. Natürlich: No Financial Advice. ;-)
Viel Spaß beim Hören und danke für euren Support!
Von und mit: [[Chris]]

Produziert und geschnitten: Chris

Hier könnt ihr uns eine Spende über Lightning da lassen: ⚡️nodesignal@getalby.com
Wenn euch unsere Arbeit gefällt, könnt ihr unsere Folgen auch auf Podcasting 2.0 Plattformen, wie Fountain, PodcastGuru, Castamatic, Breez oder Podverse hören und uns so eine kleine Aufmerksamkeit da lassen. Danke an alle, die die Bitcoin Community mit ihren Spenden unterstützen! Mit diesen Spenden wird unter anderem unser Bounty Programm verwirklicht, in dem ihr euch für die Mitarbeit an einem Projekt eine Belohnung sichern könnt.
Für Feedback und weitergehenden Diskussionen kommt gerne in die Telegramgruppe von Nodesignal und bewertet uns bei Spotify und Apple Podcasts, das hilft uns sehr. Folgt uns auch gerne bei Nostr:npub1n0devk3h2l3rx6vmt24a3lz4hsxp7j8rn3x44jkx6daj7j8jzc0q2u02cy und Twitter.


Musik: Final Girl - Jeremy Blake (Royalty Free) 
Timestamps:

(00:00:00) Intro

(00:00:22) Folgenintro Chris

(00:04:14) Einschätzung Gefahr Quanten Computer

(00:13:46) Der technische Aspekt - Bitcoin Adressen

(00:16:05) Gehashte und nicht gehashte Adressen

(00:32:01) Taproot - ein Sonderfall

(00:42:56) BIP 360

(01:01:33) Zusammenfassung Adressen

(01:01:57) Ein alternativer Lösungsvorschlag

(01:06:23) Auf welchem Quanten Paranoia Level bist du?

(01:15:06) Zusammenfassung Quanten FUD Folgen 1-3

(01:19:26) Tschüss und Danke an Volker und Effet Cantillon

Transcript

Intro

Nodesignal, deine Bitcoin-Frequenz. [Musik]

Folgenintro Chris

[Musik]

Herzlich willkommen zu Nodesignal, eure Bitcoin-Quanten-FAT-Frequenz. Hier spricht der Chris und ich bin schon wieder mit einer Folge zu potenziellen Quantencomputerangriffen auf Bitcoin bzw. zur Einschätzung der Gefahr, welche Quantencomputer für die Kryptografie in Bitcoin darstellen, zurück. Ja, ich weiß, es sollten eigentlich bloß zwei Folgen zum QuantenFAT bzw. zur Post-Quanten-Kryptografie werden. In der ersten Folge sprach ich mit Hannah von Tuta einleitend zum Thema.

Das war Nodesignal Episode 227. Da ging es noch gar nicht so sehr um Bitcoin. In der darauf folgenden Folge, Episode 228, haben sich Calso und ich mit Sebastian getroffen und konkret über Bitcoin und Quantencomputer gesprochen. Bevor ihr diese Folge hört und die anderen Folgen vielleicht verpasst haben solltet, führt sie euch gerne erstmal zu Gemüte. Das Gespräch heute baut auf diesen beiden Folgen auf. Ja, eigentlich sollte nach den genannten Folgen der Deckel auf das Thema.

Und insbesondere in der zweiten Folge mit Sebastian sind wir schon ganz schön in die Tiefe gegangen. Nodesignal wäre nicht Nodesignal und Bitcoiner wären nicht Bitcoiner, wenn nicht doch noch ein paar Fragen aufgekommen wären. Nach der Folge mit Sebastian meldete sich Efe Cantillon mit ein paar sehr interessanten Fragen in der Nodesignal-Telegram-Gruppe und Volker BTC schrieb mir unabhängig davon eine DM mit ein paar ergänzenden Kommentaren. Volker BTC und Efe Cantillon. Kennt ihr sie noch?

Genau mit diesen beiden technisch äußerst bewanderten Herren haben wir eine super interessante Folge zur Frage "Warum eigentlich 21 Millionen Bitcoin gemacht?" Ich verlinke euch diese Folge in den Shownotes. Also, never change a winning team, ich habe Volker und Efe gefragt, ob wir die Fragen und Kommentare nicht öffentlich im Rahmen einer Podcast-Folge diskutieren können. Und hier ist sie. Quantenfad Folge 3. Wir sprechen über die Quantenresistenz der unterschiedlichen Bitcoin-Adressformate.

Es wird spannend und natürlich ein bisschen nerdy. Wer es durchhält, Volker gibt am Ende der Folge einen alternativen Investment-Tipp für den Fall, dass Bitcoin doch von Quantencomputern geknackt wird. Der Tipp ist natürlich mit einem Augenzwinkern. Ihr wisst ja, no financial advice. Bevor es losgeht, Nodesignal macht keine Werbung und trägt sich allein durch Community-Spenden.

Wenn euch diese Folge einen Mehrwert bietet, schickt uns gerne eine Lightning-Spende an unsere Adresse in den Shownotes oder boostet uns über euren Podcast 2.0 Player. Wir decken mit euren Spenden die laufenden Kosten des Podcasts und unterstützen Bitcoin und Open-Source-Entwicklung. Jetzt aber ab ins Gespräch. [Musik]

Einschätzung Gefahr Quanten Computer

Herzlich willkommen Efi Katian und herzlich willkommen Volker. Schön, dass ihr da seid. Hallo. Hallo. Ja, lang ist es her. Ich muss noch mal erinnern, wir haben uns getroffen zuletzt bei der Episode 179 "Warum 21 Millionen". Ist eine meiner Lieblingsfolgen. Könnt ihr euch noch erinnern? Großartig, ja. Ja, das war lustig damals.

Ja, also ich packe das auch in die Shownotes. Also wer die Folge nochmal hören möchte, da haben wir uns damit beschäftigt, warum es überhaupt 21 Millionen Bitcoin sind und nicht 22 und nicht 42 oder 50 und warum nicht 12. Gut, darum soll es aber heute nicht gehen, sondern es ist der dritte Teil zu der Post-Quanten-Kryptografie-Folge oder salopp gesagt zum Quanten-Fad. Und es gab ja schon zwei Folgen. Die Einführungsfolge mit der Hannah von Tuta.

Was sind Quantencomputer und was für eine Gefahr stellen sie da für die Kryptografie? Und dann die Folge 2 mit dem Sebastian, insbesondere zu Bitcoin. Bei der Folge 2, die sehr ausführlich war, gab es jedoch am Ende noch Fragen. Und ihr habt mich beide angeschrieben. Einmal Volker, du hast mich separat angeschrieben und der Efe kannte John auch. Und dann haben wir gedacht, okay, wenn es noch Fragen gibt, dann diskutieren wir die public hier im Podcast.

Und ich freue mich, dass wir so zusammengefunden haben. Bevor wir starten, welche Blockzeit haben wir? Da kann ich reinspringen. Ich bin gerade auf meinem Node. Wir haben den Block 896.958 vor 40 Minuten gemeint worden. Das kann ich bestätigen. Ja, vor 40 Minuten. Wow. Aha, okay. Der davor war vor 65 Minuten, ne? Demnach ist die Hashrate gerade zusammengebrochen auf 300 Exahashes. Nein. Ein Dip in der Hashrate. Genau.

Also bevor wir in die Fragen starten, die wir uns notiert haben, ich gebe schon mal einen ganz kleinen Ausblick. Wir wollen gucken, bei welchen Adresstypen der Pupkey offenbart wird, zu welchem Zeitpunkt, warum Tabroot nicht gehashed ist und wie es mit Multisig aussieht. Wir haben kurz über die Change-Adressen gesprochen. In das BIP360 wollten wir noch mal gucken und die Algorithmen und hatten dann noch so eine andere Idee, die ihr gefunden habt.

Zunächst mal, was haltet ihr denn von dieser ganzen Geschichte um Quantencomputer und dem ganzen Quantenfad? Also könnt ihr uns eine Einschätzung geben?

Ja, also ich habe es mir angeguckt und aufmerksam gelesen, wie weit sind wir da draußen und ich bin auch zu der Einschätzung gekommen, oder ich bin zur Einschätzung gekommen, dass das noch nicht absehbar ist, wann Quantencomputer existieren, die so schnell sind oder so stark bestückt sind mit Quanten, dass sie innerhalb kürzester Zeit Dinge rechnen können. Und selbst wenn welche existieren, werden da immer Kosten dranhängen.

Von daher denke ich, müssen wir heute darüber sprechen, wie realistisch ist es denn eigentlich in den nächsten 10, 20 Jahren. Ja, stimme ich dir zu. Quantencomputer sind derzeit eher physikalische Messgeräte als irgendwelche brauchbaren Computer. Es gibt verschiedene Ansätze, das zu machen. Da gibt es so Ionenfallen, es gibt Josephson Junctions mit verkoppelten Elektronen, die irgendwie synchronisiert sind, es gibt Photon-basierte und es gibt – was war das letzte?

Habe ich vergessen, muss man auch nicht alles kennen. Aber jede von den Ansätzen hat konzeptionelle Nachteile. Bei dem einen hast du das Problem, dass du nur Mikrokelvin über dem absoluten Null sein darfst. Das heißt, du brauchst flüssiges Helium, das ist wahnsinnig teuer.

Dafür hast du relativ geringe Fehlerrate von nur 0,1 bis 1 Prozent, was an sich schon jede Art von Berechnung ausschließt, wenn du mehrere tausend von diesen Dingern hast und hast 0,1 Prozent Fehlerrate, dann kriegst du nur Müll hinten raus.

Dann gibt es Photon-basierte, die haben das Problem, dass sie sehr schnell verfallen, weil die Photonen natürlich nicht still bleiben, sondern die musst du in einem Glasfaserleiter oder so was tun und irgendwann dotzen die da an die Wand und interagieren und dann ist das Ganze wieder entkoppelt. Das heißt, du hast ein Problem mit der Lebensdauer von den Dingern, von den Quanten. Die Quanten müssen ja existieren und lebendig bleiben, also verschränkt bleiben über die gesamte Dauer der Rechnung.

Und wenn du dann so Zeiten hast im Nano- bis Mikrosekundenbereich und hast eine Berechnung von zehn Minuten vor dir, dann ist es witzlos. Du hast andere Dinge, also das derzeit vielversprechendste sind diese Ionenfallen. Das heißt, du fängst einzelne Ionen ab, so Yttrium oder so was, und du kühlst die runter auf so niedrig wie möglich und danach kühlst du die restliche Braunschuhbewegung noch ab mit Lasern. Und dafür brauchst du mehrere Laser, also einen Laser für jede Richtung.

Und dann pulst du die Laser so, dass du genau das Ding zum Stehen bringst. Das kannst du machen mit so einem, aber wenn du dann 100 hast, dann brauchst du 300 Laser, die sich alle nicht gegenseitig stören und die musst du irgendwo unterbringen und so weiter. Und du musst die steuern und so weiter. Es ist wahnsinnig kompliziert. Also jede von diesen Apparaturen, die man hat, hat irgendwo eine physikalische Grenze, die wir derzeit nicht mal ansatzweise durchbrechen können.

Das ist also konzeptionell unmöglich. Deswegen würde ich doch dringend davon abraten, in irgendeine Form von FUD zu verfallen. Ja, der Quanteneffekt ist real, der Quantencomputer ist theoretisch real. Quantencomputer in umgesetzter Form ist mit Sicherheit Dekaden weg. Das ist auf jeden Fall schon mal eine entspannende Einschätzung. Das Ziel der Reihe ist ja so ein bisschen, dass wir so einen Überblick bekommen, wo stehen wir denn da überhaupt einmal auf der Seite der Quantencomputer?

Und für den Fall, dass es dann doch real wird, wo stehen wir auf der Bitcoin-Seite und welche Angriffsvektoren gibt es? Jetzt hast du im Folgendokument, Volker, schon Szenarien durchgespielt. Wollen wir die mal durchgehen? Ja, gerne. Wir haben im Grunde die Möglichkeit, die Zukunft in drei große Szenarien zu unterteilen in Bezug auf das, was Bitcoin gefährden kann. Das erste Szenario ist auch das erste, was kommen würde, wenn es jemals kommt.

Quantencomputer sind sehr selten und sehr teuer zu betreiben. Das heißt, es gibt dann einen und der gehört irgendwie China oder Amerika oder sowas. Und das kostet eine Million pro Minute oder sowas, um das Ding tatsächlich zu betreiben. In dem Fall sind mit Sicherheit keine Bitcoin gefährdet, weil erstens dieses Ding unter staatlicher Aufsicht steht oder unter Aufsicht von sehr vielen Shareholdern eines sehr, sehr reichen Unternehmens.

Und die sind nicht daran interessiert, irgendwas Illegales oder Illegitimes zu machen, sondern die wollen damit zum Beispiel Krebs besiegen, neue pharmazeutische Forschung machen, die man bisher nicht machen konnte und so weiter. Es gibt das zweite Szenario. Die Dinger sind verfügbar. Also man kann sie kaufen, aber sie sind immer noch sehr teuer, weil du zum Beispiel flüssiges Helium dafür brauchst oder enormen Energieaufwand.

Und in dem Fall würde man sagen, am ehesten gefährdet sind Adressen, die on-chain sichtbar sind. Das heißt, wo der Public Key bekannt ist. Und da können wir nachher auflisten, welche das sind. Oder ich kann es jetzt machen, wie es euch lieber ist. Also im Szenario zwei, die on-chain gefährdeten Coins. In absteigender Reihenfolge sind erst mal die Exchanges, von denen die Adressen bekannt sind.

Es gibt ja Exchanges, die ihre Wallet-Adressen offengelegt haben. Und da sind dann teilweise hunderttausende von Bitcoins drin, vielleicht sogar Millionen. Und die werden natürlich als erstes angegriffen. Als zweites Finanzdienstleister und Verwarer, denen man den XPUB gegeben hat. Also wenn du den XPUB hast, kannst du alle Adressen sehen. Und der XPUB ist der Public Key für alle darunter liegenden Adressen. Natürlich ist es sehr attraktiv, über so einen XPUB eine XPRIF auszurechnen.

Und wenn du Finanzdienstleister bist, hältst du viele von diesen XPUBs, dann ist die Wahrscheinlichkeit, dass du gehackt wirst und diese XPUBs angegriffen werden, weil da wahrscheinlich viele, viele Coins drauf sind, sehr hoch. Das dritte wären dann die Petoshi Coins, also die Satoshi Pattern Coins, von denen man nicht ganz sicher weiß, dass sie Satoshi gehören. Also Entstehungsmuster nimmt man es an, daher Petoshi. Das sind 50 Coins pro Block, das lohnt sich schon.

Aber es lohnt sich natürlich nicht, wenn der Angriff dann 70 Coins pro 10 Minuten kostet. Und dann gibt es ein paar Donation-Adressen, also veröffentlichte Adressen, auf denen viele Bitcoins liegen. Und dann noch andere Pay-to-Public-Key und irgendwann mal auch Deiner. Also sicherlich von uns Normalbürgern ist da nichts direkt gefährdet, würde ich sagen. Weil es wäre zu teuer, das anzumarken.

Der technische Aspekt - Bitcoin Adressen

Wenn ich das jetzt so zusammenfasse, dann sind da ja einige Informationen drin. Also wir haben einerseits so etwas wie strategische Angriffsziele, also Exchanges, Finanzdienstleister und so. Und dann hat das ja noch einen technischen Aspekt, je nach Adressformat. Efi Kantigian, sollen wir mal die Adressformate durchgehen, welche da insbesondere gefährdet wären in solchen Szenarien?

Genau, gerne. Also Volker hatte gerade schon angesprochen, es gibt die Petoshi-Coins und das ist dieses erste Adressformat, dieses Pay-to-Public-Key, wo die Public Keys direkt auf der Blockchain offengelegt werden. Das ist dann einfach. Die Idee war dann eigentlich gar nicht aus irgendwelchen Sicherheitserwägungen, sondern für die Privatsphäre und für die Kompaktheit gehashte Verfahren einzusetzen. Da kann man Checksumming reinmachen. Das ist mit dabei zum einen.

Und zum anderen komprimiert man es dann auch nochmal, also diesen Public Key dann mit RIPE 160 und SHA256 doppelt zu hashen. Da ist es dann tatsächlich so, dass der Public Key nicht bekannt ist, solange eben die Adresse nicht schon mal verwendet wird. Also wo es praktisch nicht einen Output gibt, der wieder auf die gleiche Adresse zurückzeigt. Und da habe ich Statistiken gesehen, dass das zwischen 5 und 10 Millionen Bitcoin tatsächlich sind, wo das der Fall ist.

Wie Volker angesprochen hat, eben auch Exchanges, die sich das mal überlegen sollten, ob das eine gute Praxis ist, das so zu tun. Und die gibt es eben in der Variante P2PKH, also Public Key Hash. Und dann gibt es die, nachdem SegWit aktiv geworden ist, gibt es die natürlich da auch nochmal. Da kommt nochmal ein W dafür für Witness und die sind auch gehasht.

Und dann gibt es das TabRoot-Verfahren, was über einen SoftFork dazugekommen ist, wo die Public Keys wieder, wie beim ersten Verfahren, P2PK, direkt bekannt sind, was in der Natur der Sache liegt, weil man das nutzen möchte.

Also das hat dann wiederum Privacy Implications, dass man eben sagen kann, wunderbar, man kann Schnorr-Signaturen verwenden und damit das funktioniert, muss der Public Key, also darf er auch nicht gehasht sein, muss er bekannt sein, dann kann man damit Dinge tun, wo nicht mehr erkennbar ist, zum Beispiel Multisig, wie viele Parteien sind da beteiligt oder ist es überhaupt ein Multisig.

Gehashte und nicht gehashte Adressen

Ich würde da gerne direkt eine Frage anschließen und zwar, wenn wir jetzt diese einzelnen Adresstypen nochmal durchgehen. Also du hattest anfangs gesagt, P2PK, da wird ECDSR verwendet, also elliptische Kurvenkryptographie, um aus dem Private Key den Public Key zu errechnen, der dann wiederum sowohl auf der Blockchain als auch im Mempool sichtbar ist. Und jetzt, wenn wir nochmal die Adressformate so durchgehen, wo ist was sichtbar?

Also jetzt hast du gesagt, es gibt P2PK-Hash, da wird zusätzlich der Public Key nochmal gehasht. Also man hat von Private Key auf Public Key, kommt man über ECDSR, dann wird das nochmal gehasht, das ist das SHA256 und RYPEMD160, also du hast zwei Kryptografieverfahren, die nochmal verwendet werden, um das zu hashen. Und hier ist dann der Public Key nicht auf der Blockchain ersichtlich, aber im Mempool.

Also können wir das für die einzelnen Formate nochmal auseinanderdröseln und die in so Schubladen packen? Also die eine Schublade ist, okay, der Public Key ist direkt auf der Blockchain erkennbar. Und die andere Schublade ist, der Public Key ist nicht auf der Blockchain erkennbar, aber spätestens im Mempool. In dem Moment, wo man natürlich jetzt einen Spend machen möchte, wo man sie ausgeben möchte, da muss man ja signieren.

Und um diesen Vergleich dann durchführen zu können, also dass die Miner und natürlich auch alle anderen Nodes das verifizieren können, dafür muss dann der Public Key bekannt gegeben werden. Und das ist auch schon im Mempool der Fall. Und die Idee ist ja jetzt eine Change-Adresse zu verwenden, sodass, wenn was übrig bleibt von bei der Transaktion, dass das nicht wieder zurückgeht auf die gleiche Adresse. Aber der Public Key ist dann schon bekannt.

Und bei einer Change-Adresse, wenn die frisch ist, dann ist er da wiederum nicht bekannt, weil eben doppelt gehasht. Aber im Mempool ist er zu jeder Zeit bekannt, mit allen bekannten Verfahren. Volker, korrigiere mich, wenn ich falsch liege. Nee, da liegst du schon richtig. Ich glaube, wir sollten aber einmal auslisten, für die bekannten Adresstypen, sind sie gehasht oder sind sie nicht gehasht? Wir suchen es gerade mal aus dem Steglach.

Also Pay-to-Public-Key, das sind die Patoche-Points, ist nicht gehasht, ist also direkt on-chain sichtbar. Und damit in dem Szenario 2, die Quantencomputer sind verfügbar, aber noch teuer, ist angreifbar. Da kann sich so ein Ding zehn Jahre Zeit lassen, wenn es eine super Position sowann erhält. Das heißt, da hatten wir elliptische Kurvenkryptographie, die genutzt wird, den Public Key zu erstellen, vom Private Key aus. Und dieser Public Key ist dann auf der Chain die ganze Zeit ersichtlich.

Da können wir jetzt auch nachgucken in unserem Blogexplorer und die bekannten Patoche-Coins, Satoshis 20.000. Was sind das, Adressen oder so? Mit jeweils 50 Coins könnte man da ganz in Ruhe knacken. Genau, könnte. Das ist Pay-to-Public-Key. Man hat dann relativ schnell das aufgegeben, noch ein Jahr ungefähr, und hat ein neues Verfahren eingeführt. Und zwar nicht wegen Quantencomputern, sondern einmal aus Privacygründen und vor allem, weil die Dinger kürzer werden.

Pay-to-Public-Key. Ein Public Key ist 64 Byte lang. Ein Hash ist auch 64 Byte lang, aber ein Ripe MD 160 ist nur 160 Bit lang, nicht 256. Und deswegen hat man erst mal das Ding gehashed, wegen Privacy, mit dem Shard 256. Und um das dann zu verkürzen, hat man Ripe MD 160 drauf gemacht. Und das hat noch den Zusatzbonus, dass es zwei verschiedene Hash-Verfahren sind. Das heißt, wenn man irgendwas angreift, muss man jetzt drei verschiedene Sachen machen.

Man muss Ripe MD 160 knacken, um einen Shard 256 Hash zu finden, hinter dem dann ein Public Key ist. Und von dem Public Key muss man ein Private Key zurückrechnen. Das ist schon verdammt schwierig. Aus den On-Chain-Daten zurückzurechnen auf ein Private Key kann man wirklich ausschließen.

Ich hatte, Volker, als wir den Buchclub "Crocking Bitcoin" gelesen haben, den du ja übersetzt hast, das Buch von Karl Rosenbaum, habe ich das so in Erinnerung, dass Ripe MD 160 ein europäisches Verfahren ist und Shard 256 ein US-amerikanisches. Richtig. Also ich glaube, man hat da nochmal so eine geografische Diversifikation eingebracht. Ja, das ist richtig. Nach dem Motto, möglicherweise kommt das ja alles von der NSA und hat alle dieselbe Hintertünge.

Oder die selbe Organisation kennt die Hintertür für alle Verfahren. Also so etwas hat man das eben auch noch gemacht. Ripe MD 160 ist nicht so sicher. Es hat irgendwie wie viel Bit nur? 160 Bit ist entsprechend weniger Entropie als 256. Das kann man bei Hash-Verfahren, glaube ich, nicht so direkt sagen, weil da geht es um die Gleichmäßigkeit von dem Verfahren. Also wie gleichmäßig wird der mögliche Raum ausgenutzt, in dem sich diese Bits befinden können.

Und wenn der ungleichmäßig ist, dann hast du auch weniger effektive Entropie als die 160. Und das kann ich nicht beurteilen. Das könnte der Grund sein, warum es zwei Verfahren sind, um einfach irgendwelche Dinge bei Ripe 160, wo man sagt, das genügt nicht von der Sicherheit, um den Wind aus den Segeln zu nehmen, zu sagen, wir haben zwei Verfahren, dann reicht es nicht, eins nur zu brechen.

Was ganz interessant ist dazu noch, dass ich nach meinem Wissen, dass es das Pay-to-Public-Key-Hash tatsächlich von Anfang an gab. Also das wurde nicht über ein Software-Fog später eingeführt, sondern es war direkt schon in der ersten Version mit dabei. Wurde aber für das Mining von den Patoshi-Coins nicht verwendet. Da kann man jetzt auch noch spekulieren, warum eigentlich nicht. Die einfachste Annahme ist weniger Komplexität. Der Patoshi hat eigene Mining-Software wohl gehabt, nimmt man an.

Und da war es vielleicht dann einfacher, nicht noch das implementieren zu müssen mit dem Double-Hashing. Also das könnte es sein. Ich habe wieder was gelernt. Danke. Ich dachte, das wäre nachträglich eingefügt worden. Ich habe wieder auch was gelernt. Wisst ihr, dass es auch mal Pay-to-IP-Adress gab? Das war eigentlich in der ersten Version. Aber jetzt zurück. Wir hatten die Pay-to-Public-Key, wo man praktisch nur den Discrete-Log-Algorithm lösen muss.

Also vom Public-Key auf den Private-Key zurückrechnen. Wofür es theoretisch einen Algorithmus gibt, den Shores. Das ist genau der Shore-Algorithmus. Zu den ungehashten Verfahren gehört auch Taproot, das modernste. Kommt auch in die Schublade zu Pay-to-Public-Key. Es ist ein Public-Key. Den Grund, weshalb die das gemacht haben, sollten wir vielleicht später besprechen, um den Hörer nicht zu verwirren. Aber der ist sehr interessant.

Dann gibt es die gehashten Verfahren. Das ist Pay-to-Public-Key-Hash, wo das ganze Ding hinter diesen Doppel-Hashes versteckt ist. Es gibt Pay-to-Script-Hash, wo sich ein Script noch hinter dem Hash verbirgt. Das heißt, selbst wenn man den RIPE-MD-160 und den SHA256 geknackt hat, dann findet man dahinter immer noch nicht den Public-Key, sondern ein Script. Was heißt das genau? Bitcoin basiert auf einer Script-Programmiersprache.

Das, was auf der Blockchain liegt, plus das, was der Ausgeber in seiner Transaktion übermittelt, wird hintereinander gehängt und dann als Programm ausgeführt. Wenn das Ergebnis dieses Programms am Schluss "true" ergibt, dann ist die Transaktion gültig. In allen anderen Fällen ist die Transaktion ungültig. Das heißt, du kannst theoretisch ein beliebiges Programm daran hängen, von dem keiner weiß, wie das aussieht.

Der Einzige, der das weiß, wie das aussieht, ist deine Wallet, weil die das Programm erzeugt hat. Und dieses Programm ist dasselbe für alle Coins deiner Wallet. Diese Wallet kennt dann dieses Script und diese Wallet kann, wenn es eine UTXO, eine Coin, ausgeben will – spenden will – dann kann sie dieses Script in der Transaktion übermitteln, in den Mempool. Und dann würde der Node, der verifiziert, das Script hashen und mit dem Hashwert vergleichen, der in der Blockchain liegt.

Und wenn dieser Hash übereinstimmt, dann führt sie das Script aus. Du kannst eben irgendwas programmieren. Auf die Weise ist Multisig implementiert? Ja, es gibt zwei Verfahren für Multisig. Es gibt dieses Skript und es gibt ein Raw Multisig, wo du alle Public Keys beim Ausgeben in die Transaktion reintust und dann die nötige Anzahl Keys an Signaturen dazutust und dann den Operator CheckMultisig aufrufst.

CheckMultisig ist ein einfacher Operator, der aber eine sehr umfangreiche Berechnung innerhalb von Bitcoin ausführt. Nämlich jede Signatur, die du übergeben hast, mit jedem dieser Public Keys zu verifizieren und am Schluss zu sagen, ja, da sind genug Signaturen für genug Public Keys.

Die ersten Implementierung von Multisig oder auch die erste Implementierung von Segwit wird gerne über so ein Script Hash gemacht und dann später gibt es eine native Implementierung, wo man sagt, das brauchen wir jetzt nicht darüber zu machen. Das sieht man ja, wenn man sich ältere Adressen anguckt, dann sind die mit dem Script Hash.

Die fangen mit einer 3 vorne an, sodass man dann früher gesagt hat, das wird hier wahrscheinlich Multisig sein, weil die Adresse beginnt mit 3, heißt aber eigentlich ist ein Script Hash. Du weißt halt nicht, ist es ein Multisig oder hat irgendjemand seinen Beerbungsplan da drin programmiert. Sorry, wenn ich dich kurz unterbrechen darf, Volker. Wenn ich auf meinen Spickzettel gucke, die sind 2012 eingeführt. Bedürfte das eines Softworks oder? Weiß ich nicht.

Müsste so gewesen sein, aber damals waren die auch noch unkontrovers. Also in der Historie von Bitcoin bin ich nicht besonders gut bewandert. Wenn jemand an der ASAFI kennt, ist das viel besser als ich. Grundsätzlich neue Adresstypen, neue Algorithmen, das ist immer ein Softwork, weil man ja sozusagen Funktionalität erweitert und praktisch sagt, jemand anderes muss das ja nicht verwenden, wenn er nicht möchte, bleibt rückwärtskompatibel, weil man kann auch die alten Verfahren verwenden.

Da kommt hier was dazu und wir einigen uns darauf, dass das jetzt auch zulässig ist. Okay, da haben wir dann auch, wie eben, das verändert sich an der Kryptografie eigentlich nichts, außer dem Script Hash. Wir haben weiter Chart 256 und RipeMD 160. Korrekt. Plus ECDSA. Ja, plus das Script, was du nicht kennst. Also es ist noch schwieriger, das zurückzurechnen. Okay. Dann hast du das gleiche, also dann hast du Embedded SegWit.

Das ist Pay-to-Witness-Script Hash, richtig? Ich weiß nicht, ich bring das durcheinander. Das ist Pay-to-Witness-Script Hash. Da wird der ganze Witness, also Witness ist das zur Technologie, als Witness bezeichnet man das, was praktisch die Signatur, was der Signatur entspricht. Also der Beweis der Zeuge sozusagen, Witness heißt Zeuge, ist aber in der Kryptografie einfach der Beweis, dass die Aussage wahr ist oder der Beweis, dass die Spend Condition erfüllt ist.

Dieser ganze Klumpatsch, das kann ein Skript sein, das können Signaturen sein, das heißt Witness. Und mit dem SegWit wurde dieser Witness ausgelagert, der im Teil des Blocks sehr billiger ist und mehr Platz hat sozusagen. Und mit dem Pay-to-Witness-Script Hash hat man eine Zwischenlösung gefunden für Nodes, die noch nicht SegWit-kompatibel upgradet hatten, dass man trotzdem... Nein, für Wallets, die noch nicht upgradet waren. Ah, das ist irgendwie fürchterlich kompliziert.

Auf jeden Fall ist es rückwärtskompatibel zu alten Versionen, sodass du nicht SegWit können musstest, um trotzdem SegWit-Transaktionen machen oder beobachten zu können. Ja, verstehe. Da hätte ich gedacht, die wären klassisch in dem ganz normalen Pay-to-Script Hash drin gewesen. Und die anderen sind dann nativ, also die mit dem W drin. Nach meinem Wissen sind native SegWit-Adressen. Ja, kann sein. Aber auch da ist es gehashed. Also auch da sind die Adressen erstmal gehashed.

Also alle SegWits sind gehashed. Also ich sehe hier, dass die Pay-to-Witness-Public-Key-Hash RIPE-MD 160 verwendet und dann Pay-to-Witness-Script-Hash RIPE-MD nicht mehr verwendet, sondern nur noch SHA256 und natürlich ECDSR. Gut, das sind doppelt, das heißt, die sind größer, die Adressen. Wenn man der Logik folgt, wie du das eben beschrieben hast, müssen sie größer sein, oder? Okay. Das wusste ich alles 2017 mal, als das eine Rolle gespielt hat.

Aber die ganzen SegWit-Adressen, die wir jetzt, also ich wiederhole nochmal, Pay-to-Public-Key-Hash, Pay-to-Script-Hash, Pay-to-Witness-Public-Key-Hash, Pay-to-Witness-Script-Hash, die packen wir alle in die Schublade. Liegt nicht auf der Blockchain offen, der PubKey. Die gehören alle in die Schublade. Das gucken wir uns im Mempool nochmal an. Ist keine Gefahr auf der Blockchain für vermeintliche Quantenangriffe, ne?

Eine Einschränkung, wenn wir einen Lightning-Kanal haben, der geöffnet ist, ist es ein Multisig, wo das zwei von zwei eben auch veröffentlicht wird, der PubKey. Also wenn der Kanal offen ist, ist das auch nochmal ein Thema. Jetzt haben wir selten Kanäle, oder noch keine Kanäle, die so groß sind wie die Patoshi-UTXOs. Aber das kann natürlich mal ein Thema sein. Wenn wir sehr große Kanäle bekommen, die größer als 50 Bitcoin sind, dann wäre auch für die der PubKey bekannt.

Ich habe zuletzt mal aus Neugierde bei Amboss oder so geguckt. Wo sind wir da bei den größten Kanälen? Was sind das? 20, 25 Bitcoin oder so, ne? Bei Merceden hat irgendwie stehen geblieben, was ich gesehen habe, so an Größe. Aber kann gut sein, dass wir da schon jetzt jeden Satz sind. Ja, das will ich nicht beschwören. Ich habe da mal rumgestalkt aus Neugierde. Ich weiß gar nicht, ob das ein Problem wäre, ehrlich gesagt. Man muss sich das mal durchdenken. Ich meine, wir haben ja zwei.

Wenn du die angreifst, da hast du ja zwei Leute, die ausgeben können, beziehungsweise drei Leute. Du hast ja auf beiden Seiten des Lightning-Kanals vorsignierte Transaktionen, die diese Coins ausgeben. Wenn du jetzt als Dritter reinkommst mit deinem Quantencomputer und sagst, ja, ich gebe jetzt die Coin anderweitig aus, dann kriegst du Ärger mit den beiden Kanalteilnehmern, die natürlich sofort sagen, nee, nee, Moment mal.

Hast du völlig recht. Die Initiative ist nicht so richtig da, weil man kann natürlich Chaos stiften und irgendwie Penalty-Transaktionen und so weiter, aber so richtig selber gewinnen, muss man Glück haben. Du kannst nicht gewinnen, weil wozu das immer führt.

Also wenn so eine Runaway-Condition ist, mit zwei Leuten haben die Private Keys, was dann immer passiert ist, am Schluss der Miner kriegt alles, weil die beiden Leute versuchen, sich die Transaktion wieder allein zurückzugeben und geben immer höhere Fees, damit sie immer höhere Priorität kriegen. Und am Schluss kriegt einfach der Miner praktisch alles. Und deswegen ist es etwas, woran sich keiner beteiligen wird, glaube ich. Insofern kann man das, glaube ich, wieder zurückfahren.

Taproot - ein Sonderfall

Dann haben wir noch zwei Adresstypen. Einen, den wir auf jeden Fall noch besprechen müssen, Pay-to-Tab-Route. Den würde ich euch jetzt mal gleich auf den Tisch werfen. Und dann noch am Ende den Pay-to-Quantum-Resistant-Hash, den es ja eigentlich noch gar nicht richtig gibt. Lass uns erst mal Tab-Route angucken. Das ist eigentlich ganz interessant, weil der gehört in welche Schublade? Der gehört in die Schublade, der Key ist frei verfügbar, liegt auf der Blockchain.

Und das ist eigentlich nicht gut, oder? Ist eigentlich nicht gut. Es ist aber ein bisschen so, wie dass zwölf Wörter reichen auch statt 24. Das ist genauso sicher. Oder es ist auch sicher genug. Die Geschichte ist, wenn du haschst, kannst du nicht mehr die entscheidenden Vorteile von Tab-Route benutzen, nämlich dass du mehrere Signaturen zusammenfassen kannst zu einer.

Und was du derzeit machen kannst, ist, du kannst Public Keys mit Schnorr, mit ECDSA geht das nicht, aber mit Schnorr kannst du mehrere Signaturen aufeinander addieren, beziehungsweise multiplizieren. Also es ist eine Verknüpfung, es ist nicht wirklich eine Addition oder eine Multiplikation. Es ist eine Verknüpfung, die nennt man dann Addition. Kannst du praktisch aufeinander addieren und das entspricht dann der Summe der Signaturen.

Und du kannst, wenn du eine Einzelsignatur hast, kannst du anhand der Summe, die dann in der Blockchain liegt, feststellen, ob die gültiger Teil dieser Summe ist. Das heißt, du kannst, 15 Leute haben die signieren können, aber du hast nur diesen einen Public Key auf der Blockchain und jeder dieser 15 Keys verifiziert sich erfolgreich gegenüber diesen einen Key. Das geht aber nicht, wenn du den Key haschst.

Dann müsstest du deinen Public Key da offenlegen und dann gelten die anderen ja nicht mehr. Du hast dieses Aggregat, was da liegt und das darfst du nicht mehr haschen, weil sonst die Fähigkeit verloren geht, die du eigentlich erreichen wolltest. Das ist so der Grund, weshalb man das nicht hascht. Und der Peter Woyle, der da erheblich dran mitgearbeitet hat, der hat dazu auch, also in seinem Summary steht letzten Endes "Public Keys are public".

Das ist einfach so gemeint, dass die… Rat mal, warum die Public Key heißen. Er sagt, dass wenn es tatsächlich Quantencomputer gibt, irgendwann mal tatsächlich es schaffen, ein Discrete-Log-Algorithm zurückzurechnen von Public Key auf Private Key, wenn das jemals passiert, dann haben wir heute keine Ahnung, wie die Dinger aussehen. Wir haben keine Ahnung, auf welcher Technologie die sie basieren. Wir haben damit keine Ahnung, welche Eigenschaften sie haben.

Und damit können wir nicht sagen, etwas, was drei Jahre lang auf der Blockchain liegt, ist grundsätzlich viel sicherer als irgendetwas, was nur zehn Minuten im Mempool liegt. Also der Unterschied zwischen zehn Minuten im Mempool und drei Jahren auf der Blockchain ist ein konstanter Faktor. Das ist nichts Exponentielles, das ist einfach ein konstanter Faktor.

Und wenn du sagst, Quantencomputer wachsen irgendwann exponentiell und werden exponentiell immer schneller und immer billiger, dann bekämpfst du mit linearer Defensive, würdest du dann einen exponentiellen Angreifer bekämpfen wollen, und das ist sinnlos. Also du kannst keinen kategorischen Unterschied feststellen zwischen "Die Adresse ist on-chain sichtbar für Jahre" oder "Die Adresse ist im Mempool sichtbar für ein paar Minuten". Das ist einfach im Prinzip dasselbe.

Das ist letztendlich der sehr erhellende Satz, der auf der Konferenz fiel mit den vielen Developer*innen, die sich alle einig waren, dass es eigentlich scheißegal ist, ob es erst im Mempool revealed wird oder ob es schon auf der Blockchain liegt. Hat mich sehr gewundert. Das heißt, wenn wir unsere beiden Schubladen noch mal angucken, ist das jetzt gar nicht so scharf voneinander getrennt.

Also natürlich getrennt dadurch, dass die einen gehashed auf der Blockchain sind, die Adressen, und die anderen eben nicht. Aber letztlich wäre das Angriffsszenario, wenn es wirklich Quantencomputer gibt, die in der Lage sind, das zu machen, macht es keinen Unterschied. Auch schon deswegen, ein Quantencomputer wird immer das Problem haben. Und das ist jetzt einfach Quantentheorie. Der wird immer das Problem haben, dass die Kohärenz irgendwann mal zerfällt.

Also dass die Lebensdauer der einzelnen Kubits einfach endlich ist. Der ist im Bereich von bestenfalls Minuten. Und dann jetzt zu sagen, ja, du kannst irgendwie so ein Ding, da kannst du ja drei Jahre lang rechnen, wenn der auf der Blockchain ist. Nee, kannst du sowieso nicht. Nach zehn Minuten musst du neu anfangen. Ja, weil irgendein Kubit zerfallen ist. Du kannst dann jahrelang immer wieder neu anfangen. Aber du hast bei jedem Mal nur eine bestimmte Wahrscheinlichkeit, das auszurechnen.

Genauso gut kannst du sagen, du machst das nicht hintereinander mit einem Computer, sondern machst es einfach parallel, indem du tausend von den Dingen mietest, wenn es die dann wirklich mal irgendwann gibt. Dann mietest du halt tausend Stück parallel und greifst den Mempool an. Es ist einfach nicht ein kategorischer Unterschied. Es ist nur ein Detailunterschied. Entweder du hast ein Ding, was es technisch schafft, einen Key anzugreifen.

Dann kannst du es lange Zeit auf der Blockchain probieren mit öffentlichen Schlüsseln, oder du kannst es parallel ausrollen und den Mempool angreifen. Das ist immer eine Frage des Geldes. Und du kannst natürlich jahrelang parallel angreifen, aber das kostet so viel, dass es sich verbietet. Wahrscheinlich. Es ist nicht ein kategorischer Unterschied. Es ist nur ein Detailunterschied. Okay. Jetzt gesetzt den Fall, wir gucken uns die Adressen an, die den Public Key offen liegen haben.

Jetzt Pay-to-Public-Key ist einfach outdated vom Format, auch von den Gebühren und so. Taproot ist da sicherlich effizienter und auch günstiger, wenn man das verwendet. Wenn ich da jetzt ein Multisig aufsetze mit Taproot, bin ich dann sicherer gegenüber eines Quantenangriffs, eines gedachten? Vermeintlich würde man ja erst mal auf die Idee kommen, weil man sagt, es sind mehr Schlüssel.

Ich habe verschiedene Möglichkeiten, den aufzusetzen, dass man praktisch M of N sozusagen hat, oder N of M, dass man sagt, ich möchte fünf Schlüssel haben, oder es gibt fünf Schlüssel und davon müssen drei signieren, damit die Transaktion gültig ist. Dann könnte man jetzt auf die Idee kommen zu sagen, wenn drei Signaturen notwendig sind, dann hängen da drei Private Keys dahinter und es ist teurer, drei Private Keys zu rechnen, statt jetzt nur einen zu brechen für die Spending Condition.

Im Vorgespräch hatte Volker schon gesagt, das ist grundsätzlich richtig. Aber, wie er auch gerade schon angesprochen hatte, wenn wir in einer Situation sind, wo wir schon so weit sind, dass die Dinge innerhalb von zehn Minuten im Mempool ausgerechnet werden können, da bringt es dann auch nicht mehr so viel. Dann kann ich auch vermutlich drei Stück in der Zeit rechnen.

Also ja, es ist eine lineare Verlängerung, aber es hilft nichts gegen den exponentiellen Anstieg der Komplexität oder der Rechenleistung. Ja, ich bin nicht sicher, ob das stimmt, ehrlich gesagt. Weil die Sache, wie das funktioniert mit den mehreren Keys, ist ja, dass die sozusagen aufeinander addiert werden.

Das heißt, du hast Signatur A plus Signatur B plus Signatur C. Signatur von A plus Signatur von B plus Signatur von C, eine Signatur, und die entspricht der Summe von A plus B plus C und darüber die Signatur. Okay, also wenn du jetzt sagst, du kannst A angreifen oder du musst, also ich sage, du musst nicht A ausrechnen und B ausrechnen und C ausrechnen. Es reicht, wenn du die Summe von den dreien berechnest.

Das heißt, du kannst aus dem Public Key, der da liegt, einen Key zurückrechnen, der die Spend-Quantition gültig macht, auch wenn es nicht der Key ist, der benutzt wurde. Also du rechnest die Summe von den drei Dingern aus. Das ist natürlich die Besonderheit von Taproot, die auf der einen Seite es möglich macht, Dinge zu aggregieren, aber es dann auch einfacher machen würde, es zu brechen, weil man nur eins zurückrechnet, nämlich die Summe.

Beim klassischen Multisig wäre das vielleicht ein Thema, wo ich tatsächlich mehrere aneinander habe in dem Script-Hash. Das ist so, ja. Aber auch da würden die Core-Devs sagen, und zwar nicht, weil sie von Bitcoin-Core sind und Ock-Return wollen und diesen ganzen Bitcoin-Angreifen. Also die Leute, die wirklich Plan davon haben, die würden da auch sagen, ist dasselbe, weil die Größenordnung dasselbe ist. Die Order of Difficulty ist die gleiche.

Das heißt, du kommst mit einer linearen Zunahme von Signaturen einfach nicht weiter. Angenommen, du hast etwas, was sich jedes Jahr verdoppelt, eine Geschwindigkeit, die sich jedes Jahr verdoppelt, und du schaffst es irgendwann über ein Softfork, irgendwas achtmal so schwierig zu machen. Das heißt, nach drei Jahren ist es wieder auf null.

Weil nach drei Jahren hat sich die Geschwindigkeit der Angreifer verachtfacht, und nach vier Jahren hat sie sich versechzehnfacht, und nach fünf Jahren hat sie sich verzweidreißigfacht. Also du kommst mit solchen einfachen Verdoppelungen oder auch Verzehnfachungen, die sind nicht gegen eine quadratische Geschwindigkeitszunahme an.

Und diese quadratische Zunahme der Rechenleistung ist ja das, was wir voraussetzen müssen, wenn wir irgendwie annehmen wollen, dass Krankencomputer jemals gefährlich werden können. >> [Siebert] Nee, es braucht dann Verfahren, wo es gar nicht mehr offengelegt wird. Also man müsste dann, wenn man in der Angriffsklasse ist, dann dürfte auch im Mempool gar nicht mehr der Public Key veröffentlicht werden und später on-chain nur das, was absolut notwendig ist.

Also müsste man da neue Strategien fahren. Aber das ist, wenn ich es richtig verstehe, aber auch unabhängig erstmal davon, dass die Quantensicher sind. Na gut, der Hash muss quantensicher sein. Also den Hash, den ich da habe, den darf ich nicht einfach zurückrechnen können, um auf den Public Key zu kommen. >> [Hübner] Oder was auch immer den Public Key irgendwie verblendet.

Oder man nimmt eben ein ganz anderes Verfahren, was nicht mehr auf elliptischen Kursen basiert, sondern auf anderen Dingen, die es ja auch gibt.

BIP 360

>> [Siebert] Okay, ich würde ganz gerne zu den anderen Dingen, die es auch gibt oder geben kann, dann kommen. Und zwar ist es das letzte Adressformat. Das vorgeschlagen wird in BIP 360, Pay to Quantum Resistant Hash. In welche Schublade würden wir das stecken oder braucht das eine eigene Schublade? Wir haben ja unsere gehashten Formate, die nicht auf der Blockchain liegen, der Public Key und dann unsere Public Keys auf der Blockchain. Wo packen wir das jetzt hin?

>> [Hübner] Ich denke, es ist eine eigene Schublade, weil es irgendwo dazwischen ist. Ich muss dabei zugeben, es ist immer schwer, das zu erklären, wenn man es nicht vollständig versteht. Aber nach dem, was ich verstanden habe, findet da beides statt. Also einmal ist es ein anderes Verfahren, keine elliptische Kurven-Kryptografie mehr, sondern sogenannte GATA. Da kann Volker sicher gleich mehr dazu sagen.

Aber zum anderen gibt es eben auch Ansätze zu sagen, können wir nach Möglichkeit nicht Schlüssel offenlegen oder nicht mehr Schlüssel offenlegen als nötig? Können wir die vielleicht auch im Mempool einfach nur attestieren? Da hört es dann bei mir vom Verständnis auch auf. Was ich verstanden habe, ist eben dadurch brauche ich nicht alle, beispielsweise ein Multisig-Setup, muss ich nicht alle offenlegen, sondern nur Teile davon und damit bleiben die anderen dann sicher.

Oder ich attestiere sie nur. Aber das wäre noch mal betrachtenswert, wie das eigentlich ganz genau da funktionieren soll. Ich muss zugeben, ich habe das auch überhaupt nicht verstanden, aber da fällt dieser Begriff #256-Commitment auf einen PostQuanten-Kryptografie-Schlüssel. Könnt ihr das erklären? Liegt mir vor, ich habe das jetzt nicht. Also bei herkömmlichen Adressen werden PubKeys beim Spend offengelegt. Das haben wir ja jetzt dargestellt.

Das ist eine potenzielle Angriffsfläche, ob auf der Blockchain oder im Mempool. Und statt eines sichtbaren PubKeys speichert PayToQuantumResistantHash ein #256-Commitment auf PostQuanten-Kryptografie-Schlüssel. Okay, das heißt, er speichert den Hash in der Blockchain. Wie soll ein Node verifizieren, wenn er zu dem Hash das Preimage nie kennt?

Mir war der BIP360 ein bisschen suspekt, weil ich habe ihn gelesen und habe, genau wie ihr, auch den Quantenteil nicht richtig verstanden, weil ich vermute, dass es einfach zu viel Vaporware ist. Und ich halte es auch für völlig verfrüht. Ich meine, was der BIP360 gut macht, ist, er sagt, grundsätzlich ist es keine gute Idee, einfach umzustellen auf einen quantensicheren Algorithmus. Das hat eine Menge Gründe.

Und einer davon ist, dass Algorithmen zwar oft quantensicher sind, es gibt einen Haufen quantensichere Algorithmen, die dann aber ganz trivial mit einem herkömmlichen Computer geknackt werden können. Und es gibt wahrscheinlich eine Menge quantensichere Algorithmen, die nicht einfach mit einem herkömmlichen Computer geknackt werden können, aber die eben kompliziert mit einem herkömmlichen Computer geknackt werden können. Man hat es nur noch nicht probiert.

Und das Wichtigste bei Kryptografie ist, wie beim Investieren, "time in the market". Also wenn so ein Ding 30 Jahre alt ist, wie ECDSA, dann ist schon von so vielen guten Leuten versucht worden, es zu knacken. Wenn das nicht geknackt worden ist, dann ist es wahrscheinlich sicher. So AES und so ein Zeug. Wenn du jetzt sagst, wir stellen um auf einen neuen Algorithmus, der ist quantensicher und die NIST hat ihn veröffentlicht und er ist ganz toll.

Ja klar, das dauert wahrscheinlich sechs Monate bis er geknackt ist, wenn der mal wirklich ausgerollt wird. Und deswegen sagt der BIP360, wir nehmen zwei Verfahren. Wir nehmen ein herkömmliches und hauen noch Quanten obendrauf, ein quantensicheres Verfahren. Und das kombiniert gibt dann die Sicherheit. Das ist so ein bisschen wie mit ECDSA plus Hash. Also du legst mehrere Barrikaden in den Weg. Das ist gut an dem BIP360.

Schlecht ist, dass er jetzt schon kommt, weil meiner Ansicht nach es völlig verfrüht ist, über Implementationsdetails sich zu unterhalten. Denn wir sind im Moment noch wirklich in der Phase, wo man sagt, wir wissen nicht, auf welchen Technologien sich Quantencomputer jemals durchsetzen werden. Werden das Photonen sein, dann spielt die Temperatur keine Rolle, wohl aber die Fehlerrate. Werden das Ionen sein, dann spielt die Komplexität keine Rolle. Eine Rolle mit den ganzen Lasern.

Werden es Superconductor sein, dann spielt die Temperatur eine Rolle und die Zerfallszeit und so weiter. Also du hast keine Ahnung, welche Eigenschaften diese Dinger hinterher haben werden. Es kann ja sein, dass die bei Zimmertemperatur zu betreiben sind. Dafür zerfallen die Kohärenzen aber nach einer zehntel Sekunde. Und zwar immer. Also auch physikalische Gegebenheiten. Du kannst einen Photon nicht jahrelang in so einer Glasfaser rotieren lassen,

ohne dass die irgendwann interagiert. Es geht nicht. Du kannst ausrechnen, dass es nicht geht. Das heißt, du weißt nicht, gegen was du kämpfst. Kämpfst du gegen etwas, was jeder haben kann, was aber nur zehn Millisekunden Rechenzeit hat und niemals mehr haben wird? Oder kämpfst du gegen etwas, was unendlich lange rechnen kann, aber Millionen pro Minute an Energie verschlägt, um das Zeug zu kühlen? Keine Ahnung. Und wie willst du gegen so etwas jetzt einen Algorithmus festlegen?

Ich halte es nicht für sinnvoll. [Siebert] Das Argument ist, man wird es mitbekommen, dadurch, dass tatsächlich dann Coins verschwinden. Also zum Beispiel die Patoshi-Coins, wo man dann sagt, warum werden davon Einzelne jetzt ausgegeben?

Also es ist mit Ansage. Das finde ich an dem BIP 360 ganz gut, dass es schon auch darstellt, dass wir da einen gewissen Schutz haben und ein gewisses Shield haben, bis es dann mal dahin geht, dass man umstellen muss, weil tatsächlich eben die Adressen, die am meisten Wert speichern, zuerst angegriffen werden würden. Und das liegt in ferner, ferner Zukunft. Vermutlich, und wie Volker auch gesagt hat, sind andere Dinge erst mal viel wichtiger.

Also Krebsforschung zum Beispiel kann man viel mehr gute Dinge tun und Geld mit verdienen, als jetzt 50 Bitcoin vermutlich abzuziehen. [Siebert] Ja, und auch noch was. Ich würde mal sagen, bevor du einen Quantencomputer baust, um die Patoshi-Coins auszugeben, guckst du noch mal in alten Daten und versuchst, dem Satoshi auf die Spur zu kommen und seinen alten Rechner zu finden, wo die Private Keys drauf sind.

Ich glaube, das ist viel, viel versprechender und viel einfacher und viel billiger, auf andere Weise an die Patoshi-Coins dran zu kommen. Und du kannst ja auch immer noch nicht ausschließen, dass der Satoshi noch lebt und dass er seine Private Keys da hat.

Das heißt, es kann auch sein, Satoshi sitzt da, ist vielleicht deutscher, hört diese Folge und sagt dann, ich warte noch ein paar Jahre und wenn dann irgendwie Fortschritte sind mit den Quantencomputern, dann gebe ich mal so eine von meinen Blocks aus, damit die denken, dass der Quantencomputer jetzt da ist. Du weißt bei Bitcoin einfach nichts. Du kannst nicht beweisen, dass es ein Quantencomputer war, der es ausgegeben hat.

Deswegen kannst du ja auch nicht sagen, wir frieren die Patoshi-Coins ein, wir machen ein Soft-Fork, da werden einfach die ersten 500.000 Blocks ungültig gemacht oder werden einfach als non-spendable markiert in unserer Fork. Wir erlauben nicht, dass sie ausgegeben werden, um uns vom Quantencomputer zu schützen. Oder solche Späße. Das kannst du nicht machen. Du nimmst da möglicherweise dem einen Menschen, dem wir alles zu verdanken haben, alles weg, quasi. Das ist auch nicht gerade nett.

Doch lieber das Coinbase-Roulette. Ja, auf jeden Fall. Aber die würden natürlich als Erste auf irgendwas Quantenhartes umsteigen oder jedenfalls ihre Adresse nicht mehr öffentlich machen. Ich glaube, wir sind uns einig. Vielleicht liegt es auch an unserer Unwissenheit, aber ich kann mir vorstellen, wir können uns einigen. Das ist sehr früh mit BIP360 und die Gefahr ist noch nicht so richtig da.

Der Fakt, dass du es noch nicht hinter dir durchleuchtet hast, Volker, zeigt mir, dass wir wirklich sehr early sind. Weil ich glaube, du wärst einer der Ersten, der es dann sonst erklären könnte. Ich würde trotzdem ganz gerne mal auf die Idee hinter dieser Post-Quanten-Kryptographie noch mal eingehen. Weil das haben wir in den Folgen davor nicht gemacht. Wir waren da sehr ausführlich mit Sebastian, aber wir haben nicht wirklich erklärt, wie funktioniert diese Post-Quanten-Kryptographie.

Können wir das mal umreißen? Da gibt es ja verschiedene Methoden. Und vielleicht können wir einfach mal zwei skizzieren. Wenn wir anfangen zum Beispiel mit dem Lattice-Verfahren, also mit diesen Gattern, kriegt man das umrissen in drei, vier Sätzen? Drei, vier wird mutig, aber ich kann es versuchen. Ich kann es mal auf eine ganz einfache Version davon versuchen zu umreißen.

Wir haben ja bei den Public-Private-Key-Verfahren die Geschichte, dass du Primzahlen miteinander multiplizierst und dann modulo irgendwas nimmst und auf diese Weise vorwärts sehr schnell rechnen kannst, aber rückwärts fast überhaupt nicht. Das ist dieses Discrete-Logarithm-Problem. Da du das aber mit dem Shore-Algorithmus theoretisch angreifen kannst, braucht man ein Verfahren, bei dem der Shore-Algorithmus nicht geht oder für das es kein bekanntes Verfahren gibt.

Und eines dieser Verfahren nennt sich Lattice oder Gatter. Da passiert Folgendes. Du hast nicht Primzahlen letzten Endes oder aus Primzahlen sich ergebende Zahlen, sondern du hast ein hochdimensionales Gitter. Also ein Gitter, was nicht nur in zwei oder drei Dimensionen ist, sondern in mehreren tausend Dimensionen. Das besteht aus lauter Punkten. Diese Punkte erreichst du, indem du Vektoren miteinander addierst. Ich mache das jetzt einfach mal zweidimensional.

Wir bleiben im zweidimensionalen Raum, weil das einfacher ist. Wir haben x- und y-Koordinaten. Und du sagst mal, der eine Vektor, der in x-Richtung zeigt, ist ein Schritt nach Richtung x und null Schritte Richtung y. Und der Vektor, der in y-Richtung zeigt, ist ein Schritt Richtung y und null Schritte Richtung x. Jetzt kannst du mit diesen beiden Vektoren jeden Punkt erreichen, der sich... Also dann kannst du einen Gatter aufspannen aus diesen beiden Vektoren,

der die Punkte 0,1, 0,2, 0,3, 0,4 usw. erreicht und auch 1,1, 1,2, 1,3, 1,4 bis 5700 in die eine Richtung und 6900 in die andere Richtung. Du kannst also diese ganzen integralen Gitterpunkte erreichen. So, das ist jetzt dieses 1,0 und 0,1-Vektoren sind jetzt dein Private Key. Die entsprechen dem Private Key. Du kannst damit sehr leicht jeden Gitterpunkt adressieren. Jetzt gibst du als Public Key jemandem einen anderen Vektor, mit dem es sehr schwierig ist, jeden Gitterpunkt zu erreichen.

Es ist auch möglich, aber es ist schwierig. Und es sieht so aus, zum Beispiel, der eine Vektor ist 583 in x-Richtung und 712 in y-Richtung. Und der andere ist 13 in x-Richtung und -581 in y-Richtung. Und die beiden Vektoren gibst du dem anderen. Das ist der Public Key.

Und die Signatur, oder das, was entspricht, das Äquivalent einer Signatur ist, oder diese Aufgabe, eine Signatur zu checken, du gibst ihm einen Gitterpunkt, du gibst ihm einen Punkt, der nah an einem Gitterpunkt liegt, aber nicht mit einem Gitterpunkt identisch ist. Und die Aufgabe ist, finde die Vektorkombination, die den nächsten Gitterpunkt findet. Das ist ganz, ganz einfach, wenn du diese Urvektoren hast, die nur 1, 0 und 0, 1 sind. Die addierst du einfach aufeinander und dann bist du da.

Wenn du aber sowas hast wie 5386 in die eine Richtung und 712 rückwärts in die andere Richtung, dann ist das verflucht schwierig. Weil jedes Mal, wenn du das eine um 1 erhöhst, gehst du gleichzeitig beim anderen auch in eine andere Richtung. Das musst du wieder kontern. Wenn du mit dem anderen hochgehst, dann änderst du auch wieder das vom ersten. Also die sind nicht linear unabhängig, sondern eben linear abhängig.

Und damit beeinflussen sie sich gegenseitig und damit ist es unheimlich schwer, da hinzukommen. Das ist schon zweidimensional schwierig. Aber mach das mit 2000 Dimensionen und dann wird es richtig lustig. Also dann ist klar, das ist mindestens so sicher wie so eine elliptische Kurve. Zumindest die Intuition sagt mir das. Mathematisch ist es vielleicht anders, aber sie erscheint sicher.

Und sie ist nicht durch Shore angreifbar, weil das nichts Wiederkehrendes ist, was man mit der Quanten-Fourier-Transformation irgendwie angreifen könnte. Und das ist eigentlich ein schöner Algorithmus. Das Problem bei der Geschichte ist, so eine Signatur ist dann halt mal ein paar 100 Kilobyte lang. Und da ist so wenig Platz auf der Blockchain. Das ist das Lattice-Verfahren, soweit ich es verstanden habe. Aber vielleicht kannst du den Link auf das Video von Veritasium hinterlegen.

Das ist nämlich sehr schön erklärt. Auch wenn man furchtbar viel Werbung gucken muss. [Lachen] Guckst du nicht im Brave-Browser, da wird sie weggedruckt. Gute Idee. Genau, da gibt es das Video von Veritasium, wo er das erklärt. Ich muss es mir ein paar Mal angucken, bis ich es einigermaßen verstanden habe. Aber ich wäre nicht in der Lage gewesen, es so zu erklären. Dann gibt es, vielleicht können wir das noch ganz kurz umreißen, diese Lampert-Signatures.

Efi Cantillon, siehst du dich in der Lage, die kurz zu umreißen? Ich kann es definitiv nicht so gut umreißen wie Volker. Von daher würde ich ihm da noch mal das Wort geben. Erklärung zu den Lattice-Signaturen. Also Lampert-Signaturen, die sind von Leslie Lampert erfunden worden. Das ist der Typ, falls noch irgendwelche alten Säcke das hören, das ist der Typ, der LaTeX geschrieben hat. Der Leslie Lampert. Also ein Urgestein der Computergeschichte. Lampert-Signaturen sind eigentlich ganz einfach.

Du hast einen Asch von einer Message. Der Asch ist 256 Bits lang. Der repräsentiert die Message. Und jetzt erzeugst du für jedes Bit dieses Aschs ein Paar von Zufallszahlen. Ein Paar aus Zufallszahlen. Du hast für jedes Bit von den 256 eine Zufallszahl. Du hast also 512 Zufallszahlen, jeweils paarweise gebündelt. Warum paarweise? Weil die eine Zufallszahl steht für den Bitwert 0 und die andere Zufallszahl für den Bitwert 1.

Dieses Asch-Bit. Diese Zufallszahlen, die Asches dieser Zufallszahlen, die Zufallszahlen haschst du und die Asches dieser Zufallszahlen die übermittelst du an den Empfänger. Der hat jetzt also einige Infos über deine Zufallszahlen. Die Zufallszahlen sind sozusagen entsprechend deinem Private Key. Der hat aber keine Info darüber, sondern der hat nur diese Commitments. Wenn der das jetzt prüfen soll, muss er in die Lage versetzt werden, das zu prüfen.

Das heißt, er kriegt jetzt für die tatsächlichen Werte, die dein ursprünglicher Message-Hash hat, also das, was er verifizieren soll, für die tatsächlichen Werte, gibst du ihm jetzt die zugrunde liegenden Zufallszahlen. Also nehmen wir an, das Bit 0 von deinem 256-Bit-Hash hat den Wert 1. Dann gibst du ihm die Zufallszahl, die dem Bit 1 entspricht, an Position 0. Das Bit 1 hat dann meinetwegen den Wert 0, das Bit 2 hat den Wert 0, das Bit 3 hat den Wert 1 und so weiter.

Gibst ihm dann immer die entsprechende Zufallszahl, die du hattest, und er kann diese Zufallszahl haschen und vergleichen mit dem, was vorher als Public Key sozusagen veröffentlicht worden ist. Und damit verifiziert er das. Dauert natürlich furchtbar lang, ist auch 64 Kilo Bit an Daten, also 8 Kilo Byte, ist mühsam und langsam, und du kannst das ganze Ding nur einmal benutzen, weil jetzt weist er ja für jede Bit-Position die Hälfte von deinem Private Key.

Das darfst du also nie noch mal benutzen. Und das heißt, du veröffentlicht ständig neue Public Keys und erzeugst neue Zufallszahlen. Das ist alles sehr rechenaufwendig und sehr platzaufwendig. Deswegen sind die auch nicht gerade so der weiße Platz der Schluss. Also ich habe gerade gesehen, weder Lattice oder zumindest so, wie wir es beschrieben haben oder benannt haben, noch Lampard Signatures sind in diesem BIP 360 drin, zumindest so in der Reinform.

Die Algorithmen heißen Falcon, Sphinx Plus, and Crystals, die Lithium. Was genau die für Probleme aufgeben, die man zu knacken hat, kryptographisch, das weiß ich nicht. Vielleicht steckt da auch einiges von dem drin, was wir eben beschrieben haben. Aber mir ging es auch so ein bisschen darum, dass man sich einfach nur mal anguckt, welche grundsätzlichen mathematischen oder kryptographischen Probleme kann man aufmachen, an denen auch dann Quantencomputer zu knacken haben.

Also zumindest das Falcon ist so ein gitterbasiertes Algorithmus. Ich hätte mir die anderen jetzt auch nicht angeguckt. Aber das ist schon die Komplexität. Okay, sehr gut. Das sind die von den Nichtveröffentlichten, die haben das schon ein paar Jahre. Letztes Jahr im Frühjahr wurde irgendwas veröffentlicht. Das PDF habe ich mit den zugelassenen NIST-Algorithmen. Kann ich vielleicht verlinken? Ich muss mal gucken, ob ich das rausgeben darf. Nee, warte mal, ist ja veröffentlicht.

Müsste eigentlich, 24 hatten die, haben die die veröffentlicht. Das wird im BIP 360 auch beschrieben, dass es einen Wettbewerb der NIST gab, an dem die teilgenommen haben. Da muss man jetzt nicht auf die Idee kommen, dass NIST die rausgibt oder dass die vom amerikanischen Staat sind, sondern das ist ein Wettbewerb, wo Teilnehmer ihre Lösungen reinnehmen, also submitten können, übermitteln können. Und das sind dann Gewinner davon, nehme ich mal an, oder die, die in die Endauswahl gekommen sind.

Okay, ich würde gerne mal zwischenresümieren.

Zusammenfassung Adressen

Wir haben die beiden Schubladen aufgemacht, haben unsere Adressen einsortiert, haben geguckt, wo liegt der Pupkey im UTXO, respektive auf der Blockchain, wo liegt er oder wo würde er dann spätestens im Mempool offenbart werden. Wir haben uns BIP 360 angeguckt, was ja noch sehr experimentell und noch nicht wirklich implementiert ist.

Ein alternativer Lösungsvorschlag

Jetzt gäbe es noch die Idee zu schauen, was könnte man gucken mit den bestehenden Mitteln. Und zwar gibt es da einen Vorschlag von Matt Corello, den wir gestern in unserem Vorgespräch schon mal diskutiert haben. Das wäre ja was, was ganz konkret ist. Was könnte man da machen, wenn man jetzt wirklich Angst vor so einem Quantenangriff hat? Ich glaube, es war Matt, ich bin nicht ganz sicher, aber ich glaube, es war Matt. Er hat vorgeschlagen, dass man einen Soft Fork macht.

Wenn wir plötzlich von einem Quantencomputer überrascht werden sollten, ja, den irgendwie die Chinesen im Keller zusammen gebastelt haben und jetzt die ganze Welt damit angreift, dann könnte man relativ schnell einen Soft Fork organisieren, der sich auf die Taproot-Adressen bezieht und der sagt, dass ein normaler Keyspend bei Taproot-Coins nicht mehr akzeptiert wird, sondern nur noch einen Scriptpath spend.

Das setzt natürlich voraus, dass die Leute vorher schon in aller Ruhe mal ihre ganzen Coins auf Taproot-Adressen gemoved haben, geschoben haben, und dass diese Taproot-Adressen auch einen alternativen Scriptpath spenden. Da könnten wir zum Beispiel Liana Wallet mal ein bisschen pushen, die sind sowieso total geil. Also Liana Wallet kann ich wärmsten empfehlen. Ich bin nicht gesponsert von denen, das ist einfach nur eine richtig geile Wallet, guckt euch mal an.

Die nimmt Taproot und kann da sehr komplexe Spendbedingungen mit reinbauen, ohne dass es zusätzlich einen Platz auf der Blockchain braucht, weil eben alles in diesen einen Pubkey reingedampft wird, was da drin ist.

Und man kann jetzt sagen, das normale Ausgeben, also ein Quantencomputer kann natürlich auch von einem Liana Wallet zu dem Pubkey einen Private Key ausrechnen, der dann spendable wäre, außer wenn alle Nodes sagen, nein, ein einfach Keyspend kannst du nicht mehr ausgeben, du musst den Scriptpath spenden, und das geht wiederum nicht mit einem Quantencomputer, weil der natürlich nicht weiß, wie das Script aussieht.

Das ist so eine Idee, aber die hat natürlich auch den Pferdefuß, dass wenn du das ausgibst, der Scriptpath spend natürlich im Mempool ist und im Mempool spätestens ist das Ding angreifbar. Also alle Verfahren scheitern daran, dass irgendwann das Zeug im Mempool landet, solange es Peer-to-Peer ausgegeben wird. Du kannst dich nur schützen, wenn du es selbst meinst.

Wenn du selber einen Miner hast und deine eigene Transaktion in deinen eigenen Block tust und dann veröffentlichst und dann musst du beten, dass keiner deinen Block ungültig macht. Das ist die sicherste Methode. Die zweitsicherste Methode ist, du hast einen API zu einem Miner und dem Miner musst du vertrauen und dann gibst du dem privat deine Transaktion und der meint und veröffentlicht dann und betet, dass keiner seinen Block ungültig macht.

Sprich, du greifst einfach auf eine trusted Entity zurück, die mehr Hash-Power hat als du selber. Und die drittsicherste Methode ist, du broadcastest das in Peer-to-Peer-Net und dann sieht es jeder und kannst theoretisch angreifen. Aber wie gesagt, das ist alles extrem theoretisch. Genau, und für die Variante verfügbar und teuer. Es gibt den Quantencomputer, den hat nicht jeder, kann diese Taproot-Variante ausreichend sein.

Da muss man nicht unbedingt auf ein neues quantensicheres Algorithmus umsteigen. Und das ist ja eine Progression, hatten wir gesagt. Das heißt, wenn sie verfügbar und billig werden, spätestens dann muss man sich Gedanken darüber machen, dass sie nicht im Mempool offengelegt werden. Und auch dann müsste es nicht BIP360 sein. Auch dann könnte es ein Taproot-kombiniertes Verfahren sein, was dazu gehört, dass die dann nur attestiert werden oder auch da gehäscht drin liegen.

Worauf ich hinaus will, und Volker hat das ja auch schon gesagt, wenn es neue Verfahren sind, dann sind die nicht erprobt und dann sind die möglicherweise unsicher oder es beweist sich über die Zeiten. Von daher ist es deutlich attraktiver, Dinge wie Taproot zu nutzen, um quantensicherer zu werden, als etwas völlig Neues zu implementieren. Also spannend.

Auf welchem Quanten Paranoia Level bist du?

Ich glaube, wir haben jetzt das Spektrum ganz gut umrissen. Was ich zusammenfassend mit euch gerne noch mal machen würde, wenn wir das Quantenparanoia-Level aufteilen auf ein Spektrum. Wenn ich jetzt ganz ... Fangen wir mal an der Volker-Seite an. Ich bin ganz entspannt und sag, Quantencomputer kommen eh nicht. Und wenn, dann greifen die jetzt sowieso erst mal nicht meine UTXOs an oder meine Coins.

Und dann ist es eigentlich auch egal, ob das erst gecoolt, das erst revealed wird oder schon auf dem UTXO, sprich auf der Blockchain liegt. Dann kannst du dich ganz entspannt zurücklehnen und sagen, eigentlich ist es egal, welches Adressformat man nimmt, oder? Würde ich dich da richtig repräsentieren, Volker? Ja, aber man muss natürlich auch die netzwerksozialen Auswirkungen betrachten.

Wenn ein Quantencomputer die Wallet von Coinbase angreift, dann ist Bitcoin augenblicklich nicht mehr so viel wert, wie es vorher war. Und das betrifft natürlich auch meine Coins. Aber meine Coins werden nicht geklaut. Also die Kaufkraft wird schnell sinken. Das wird irgendeinen Preissturz geben. Ja, mit Sicherheit. Aber wer weiß, wozu das führt. Wenn Leute in Situationen reingeworfen werden, die sie nicht kennen, dann kommen sie auf kreative Ideen. Die werden dann hochkommen.

Das ist unausweichlich, so ist Menschheit. Das ist zum Beispiel eine Möglichkeit, die sich bieten könnte. Es geht ja nur um Konsens. Alles, was einen Konsens findet, ist durchsetzbar. Du könntest sagen, okay, da war ein Angriff, der kann nur ein Quantencomputer gemacht haben. Den kannten wir vorher nicht, wir sind völlig konsterniert. Was machen wir? Wir sagen, wir haben den UTXO-Set von gestern. Wir entwickeln jetzt irgendwas, was gegen dieses Ding resistent ist.

Und dann fangen wir mit diesem eingefrorenen UTXO-Set in ein, zwei oder drei Jahren wieder an. Kannst du machen. Der Typ, der dir die Coins geklaut hat, mit seinem riesigen Aufwand, der guckt dann dumm, weil es gibt zwar noch dieses nicht eingefrorene Bitcoin-Netzwerk, aber dem traut keiner mehr. Das heißt, keiner wird den Lamborghini dafür ausliefern, wenn er auf der Chain irgendwelche Coins kriegt.

Das heißt, das ist der ultimative Fork, der dann sagt, okay, wir fangen irgendwann neu an mit dem alten UTXO-Set. Würde spannend, ja. Aber auf so Ideen haben wir da einen kommenden. Das ist theoretisch total spannend, dass ein Angreifer sich tatsächlich darüber Gedanken machen muss, was er da angreift, weil wenn er zu viel versucht zu klauen, dann zerstört er sich den eigenen Wert. Das kann natürlich auch eine Motivation sein.

Es kann ja auch Angreifer geben, denen der Wert egal ist, die einfach nur Chaos stiften wollen. Aber das ist auch nicht abziehbar. Ja, und natürlich ist es nicht einfach, wieder mit demselben UTXO-Set anzufangen, weil ich meine, der UTXO-Set ist definiert durch die Spend Condition. Und die Spend Condition hängt genau an dem, was der Quantencomputer angreift. Du müsstest dann also Kreativität bringen. Eine Idee ist zum Beispiel bei dem Neuanfang.

Dann wird es so definiert, dass eben nicht es reicht, die Signatur zu veröffentlichen, zum Ausgeben, sondern die Signatur bezogen auf den dazugehörigen XPAP und nicht auf den dazugehörigen Public Key. Du musst sozusagen mit dem Private Key des XPAP signieren, der dazugehört. Das ist eine Codeänderung, weil sonst hast du wirklich das Problem, wie fängst du mit dem UTXO-Set neu an, wo der Set angegriffen werden kann. Du musst dann die Spend Condition mit anpassen.

Aber was ich sage, ist, egal mit welchem Problem die Menschheit jemals konfrontiert worden ist, wir sind immer drüber gekommen, weil es gebiert einfach Kreativität. Aber die gebiert es eben nicht zehn Jahre vorher. Die richtigen Ideen kommen, wenn das Problem kommt. Deswegen mache ich mir mittelfristig keine echten Sorgen darum, dass ich das Problem löse. Wir lösen jedes Problem. Aber die Ideen bilden sich in unseren Gehirnen erst dann, wenn sie wirklich mit dem Problem konfrontiert werden.

Ansonsten ist es ein bisschen in den Wolken rumstochern und einfach nicht die richtigen Ideen. Im Vorgespräch Eiffé Cantillon hattest du ja eigentlich ganz treffend gesagt, alle Adressen, wo weniger als 50 Bitcoin drin liegen, die können eigentlich entspannen. Aber die 1000 Adressen sind interessanter, mindestens. Genau. Ich hatte eingangs gesagt, Quantencomputer werden immer Kosten verursachen. Die Kosten können sinken.

Aber es ist immer so eine Kosten-Nutzen-Berechnung zu sagen, ich versuche Coins zu klauen und dann nehme ich natürlich erst mal die, die am meisten rumkommen und die am einfachsten zu rechnen sind. Also die, wo der Public Key noch gehashed ist, sind ja denkbarerweise auch angreifbar. Aber da muss erst mal noch ein anderes Verfahren her, wo man den Public Key überhaupt zurückrechnet. Und das ist dann noch viel teurer. Also die wird man ganz zum Schluss machen, wenn man das kann.

Man fängt natürlich vermutlich mit den Patoche Coins an. Da haben wir gerade über Coinbase gesprochen oder andere Exchanges, die Adressreviews machen. Sind auch interessant, aber vielleicht werden sie nicht angegriffen, weil das zu prominent wäre oder zu viel Chaos verursachen würde. Wobei, ich glaube, wenn Patoche Coins sich bewegen, ist auch schon ziemlich Chaos da.

Wenn wir jetzt das Quantenparanoia FUD Level nochmal angucken, also Level 1 ist "Ich bin total entspannt, lehne mich zurück" und "Mich juckt das eigentlich alles nicht", ich sage, da wird sowieso eine Lösung gefunden, also alles, was ihr jetzt eben gesagt habt. Wenn ich jetzt auf Quantenfud Level 2 bin, Paranoia, dann könnte ich, was könnte ich dann tun?

Dann könnte ich auf jeden Fall gucken, dass ich meine Coins in Adressen habe, wo der Public Key nicht im UTXO liegt und dann in irgendein dieses gehashten Formate gehe, oder? Das wäre dann zum Beispiel Segwit, wo wir wahrscheinlich sowieso alle drinstecken, weil das noch das aktuellste, gebräuchlichste Format ist.

Ja. Ja, und dann wäre der nächste Level, ich habe wirklich Quantenparanoia und ich engagiere mich jetzt oder bleib da dran und gucke, was die Lösungen wie BIP360 bringen oder eben dieses Szenario, was wir mit dem erweiterten Tabroot, mit den Skripten da, was man damit machen kann, oder? Aber das würde ja ein Softfork bedingen.

Also wenn du jetzt, wenn du wirklich Quantenparanoia hast, dann bleibst du einfach auf einem gehashten Format, ja, dann bleibst du einfach bei BIP32 oder irgend so was, wo es ein Hash ist, gehst nicht auf Tabroot. Entschuldigung, blödsinn, Segwit, Segwit und nicht Tabroot, BIP32 ist ja schon ein Public Key.

Also im Zwischengrund könnte noch Multisig kommen, allerdings nicht im Tabroot, sondern im klassischen Segwit oder nativen Segwit, Multisig, also das würde zumindest linear die Komplexität erhöhen, weil ich mir so Private Keys plötzlich zurückrechnen muss. Ja, richtig.

Aber dann hast du natürlich auch, dann hast du die Komplexität von dem Multisig und dann ist die Wahrscheinlichkeit, ich würde sagen, die Wahrscheinlichkeit, wenn du jetzt auf Multisig umsteigst, ist die Wahrscheinlichkeit, dass du deine Coins verlierst, weil du vergisst, irgendeinen der Public Key ist, dir aufzuschreiben, oder weil du dann doch einen von den Seats zu viel verlierst oder weil du vergessen hast, wie der ganze Setup funktioniert und derjenige, der dir dabei helfen soll,

klaut anstattdessen die Coins. Die Wahrscheinlichkeit, dass du auf diese Weise die Coins verlierst, ist so viel höher als die, dass es einen Quantencomputer gibt, der dir die klaut, dass ich das nicht empfehlen würde. Ich folge bei dir. Wir waren jetzt schon bei Quantum Foot Level 2, wo jemand schon, oder 3, weil Paranoia Level hoch ist, und dann zum Beispiel, ich steige jetzt um auf BIP 360 und gibt es noch gar nicht, ach nee, was kann ich noch machen?

Also wenn man an dem Paranoia Level ist, dann vielleicht vorher nochmal über Multisig nachdenken. Ja, ich würde sagen, bei Quantum Paranoia Level 2 verkauf deine Bitcoin-Kaufaktien, fertig. [Lachen] Oder geh zu so einem Dienstleister wie Casa oder so was und schließ eine Versicherung ab, dass die dich rauszahlen müssen, wenn sie die Coins geklaut bekommen.

Also dann musst du auf den Third Party gehen, weil gegen so einen Quantencomputer, der verfügbar ist und funktioniert und so was angreifen kann, technisch, gibt es nicht wirklich einen effizienten, effektiven Schutz. Es gibt, wie gesagt, diese Geherrschtenadressen sind verdammt gut. Und wenn man sich dann darüber auch noch Gedanken macht, dann sollte man einfach aus Bitcoin rausgehen. Das hat keinen Zweck.

Zusammenfassung Quanten FUD Folgen 1-3

Also ich muss sagen, ich habe jetzt in diesen drei Folgen über Quantencomputer, Post-Quanten-Kryptographie und Bitcoin und Quantenfad, habe ich sehr, sehr viel gelernt. Und für mich ist jetzt erstmal dieser Gaul durchs Ziel geritten. Und das zeigt sich für mich, dass es eigentlich im Moment wirklich keine Gefahr ist, aber dass es gut ist, sich da Gedanken drüber zu machen und dass es jetzt Bordmittel gibt, mit denen man sich eigentlich schon ganz gut wappnen kann.

Das erste Bordmittel ist, nicht mehr als 50 Coins zu haben. Hättet ihr da noch eine Zusammenfassung? Also wie würdet ihr, euch gebührt da das letzte Wort. Also für mich fährt das durchs Ziel. Ich glaube, wir werden jetzt erstmal keine Folge mehr dazu machen. Es sei denn, es tut sich was in den nächsten ein, zwei Jahren. Dann greife ich das nochmal auf. Aber ich bin jetzt eigentlich zufrieden damit. Seid ihr happy? Ja, mir war das total wichtig.

Also das, was ich von Volker gelernt habe und die Diskussion, die wir heute hier gemacht haben und auch im Vorgespräch, die beruhigt mich, weil ich nach den ersten beiden Folgen selber an so einem Punkt war, ja, da muss man was machen und da könnte ja was kommen und es ist gut, sich jetzt vorzubereiten. Und ja klar, Gedanken machen ist immer gut, aber bitte nicht in Panik verfallen und keine vorschnellen Aktionen.

Und es gibt genug Möglichkeiten, wie Volker sagt, die man implementieren kann oder die man nutzen kann, wenn die Sache konkreter wird. Und sie ist völlig unkonkret. Ja, ich würde auch sagen, Quantencomputer. Ich bin 62 und ich werde sie wahrscheinlich nicht mehr erleben. Wenn doch, wow. Aber ich glaube nicht wirklich dran. Also sicher nicht in den nächsten zehn Jahren.

Und wenn doch, wie gesagt, wenn das irgendwie passiert, dann eisertipp, verkaufe die Bitcoin, stack alles in Aktien von Pharmaunternehmen und Materialwissenschaftsunternehmen, die davon profitieren, dass es einen Quantencomputer gibt, der wirklich funktioniert. Die gehen dann schneller to the moon als Bitcoin je konnte. Okay, das ist eine Aussicht. Dann sieht die Welt nicht völlig anders aus. Ja, ich bin gespannt.

Also was mich tatsächlich, das habe ich ja auch in der Folge mit Sebastian gesagt, da so ein bisschen, ja wie soll man sagen, erstaunt gemacht hat, ist, dass eben die US-Regierung da tatsächlich ganz konkrete Pläne hat und Milliarden da reinsteckt, ihre Behörden postquantensicher zu machen, also quantenresistent zu machen. Und das ist ja jetzt nicht in zehn Jahren, sondern ab jetzt, ab 2025. Und bis 2030 soll das alles passiert sein. Fand ich interessant.

Und da hat mir das nicht gereicht, dass alle Bitcoiner sagen, ach nee, das ist auch keine Gefahr. Deshalb wollte ich das alles mal so richtig differenziert durchleuchten. Aber das haben wir jetzt, glaube ich, auch gemacht. Ja, ich glaube, da steckt eher dahinter, dass kein Bürokrat an irgendwas schuld sein will. Und es ist relativ billig für die zu sagen, gut, wir drucken ja das Geld selber, dann machen wir irgendwelche Forschungsprogramme und lassen da mal forschen.

Und wenn die ein Ergebnis haben, dann sagen wir einfach, jede Behörde soll das jetzt benutzen. Und dann wahren wir es nicht, wenn es schief geht. Also es ist nicht, glaube ich, so, dass die wirklich kommen, sehen, dass das kommt und sich dagegen schützen wollen. Weil sie werden es nicht umsetzen können. Weil die haben das gleiche Problem mit Signaturen, die viele, viele hundert Kilowatt groß sind und so weiter. Das verzerrt alles. Das macht ganz viel Kommunikation unmöglich und so weiter.

Die werden das, wenn überhaupt, dann in den kritischsten Teilen einsetzen. Und dann wird natürlich passieren, dass irgendjemand so einen Algorithmus mit einem klassischen Computer knackt und dann stehen sie nackig da. Ich glaube, das ist eher so, sie wollen das jetzt ausrollen, a) weil die Bürokraten wollen es ausrollen, damit sie nicht schuld sind.

Und die Techniker wollen es ausrollen, damit das Ding 30 Jahre Zeit hat, um gehackt zu werden von allen Seiten, damit sich die Schwachstellen finden. Damit man dann in 20 oder 30 Jahren was hat, was wirklich funktioniert. Weil dann vielleicht die Dinger wirklich kommen. Ich glaube, das ist realistischer als anzunehmen, die haben da jetzt braune Unterhosen und sehen, dass es furchtbar dringend ist, da jetzt was zu machen. Das glaube ich anhand.

[Siebert] Wenn die deutsche Bürokratie irgendein Maßstab ist, den man da anlegen kann, dann stellt man natürlich ein Ziel bis 2030, damit es dann bis 2050 auch wirklich da ist. [Hübner] Ja, in abgespeckter Form.

Tschüss und Danke an Volker und Effet Cantillon

[Siebert] Okay. Ja gut, ich danke euch ganz, ganz herzlich. Das hat mir riesen Spaß gemacht, diese Folge mit euch vorzubereiten. Ich muss mich noch mal entschuldigen, dass meine Vorbereitungen für die Folge ein bisschen durcheinander waren. Ich habe euch ein riesen Dokument geschickt mit einer Sammlung an Sachen und wir mussten erst mal uns treffen, damit wir das alles ein bisschen sortieren. Freut mich mega und ich kann es gar nicht abwarten, mit euch noch mal eine Folge zu machen.

Es kommt bestimmt wieder ein spannendes Thema, wo wir uns wieder in dieser Runde treffen können. [Hübner] Ich mich genauso. Bitteschön, gerne. [Siebert] Super. Ganz, ganz herzlichen Dank. Habt einen schönen Tag. Focus on the Signal, not on the noise. [Hübner] Not on the quantum. [Musik] (lacht) Not on the quiet zone, yo! Ciao!

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android