Der rätselhafteste Krypto-Hack aller Zeiten
"Unsolved Mysteries", Bild von Crusty Da Klown via flickr.com. Lizenz: Öffentliche Domäne
Ein mysteriöser Hack beunruhigt derzeit die Kryptoszene, vor allem um Ethereum: Alte Wallets werden ausgeräumt, und keiner weiß, warum.
Vielleicht kennt ihr das. Es war 2015, man konnte Ethereum beim Crowdsale für etwa 30 Cent kaufen, und ihr habt es verpasst, euch einzudecken und einen fast zehntausendfachen Profit abzustauben. Hätte man damals, nur ein paar hundert Euro — oh, hätte man doch!
Aber nun gibt es eine Nachricht, die euch vielleicht tröstet. Denn es ist nicht immer einfach, Ethereum-Millionär zu sein. Wer derzeit große Beträge auf einer Ethereum-Adresse verwahrt, dürfte ins Schwitzen geraten. Und wer nicht schwitzt, sollte damit beginnen. Dringend.
Denn das Universum holt sich zurück, was es so großzügig verschenkt hat.
Als würde einem der Boden unter den Füßen weggezogen!
Über dem, was auf Ethereum in den letzten Monaten passiert, liegt noch relativ viel Nebel, und in der Regel werden Details nur hinter vorgehaltener Hand verraten. Doch über das Folgende scheinen sich alle weitgehend einig zu sein:
Mehr als 5.000 Ether sowie eine unbekannte Menge an Token wurden seit Dezember 2022 von Adresse gestohlen, die zwischen 2014 und 2022 erzeugt wurden. Die Diebstähle fanden auf 11 Blockchains statt, darunter auch Bitcoin, aber mit einem Fokus auf Ethereum, und umfassten neben BTC und ETH zahlreiche Token oder NFTs. Der Großteil der gestohlenen Token wurde mittlerweile in ETH gewechselt.
For the past 48hrs I've been unwinding a massive wallet draining operation 😳😭
I don't know how big it is but since Dec 2022 it's drained 5000+ ETH and ??? in tokens / NFTs / coins across 11+ chains.
Its rekt my friends & OGs who are reasonably secure.
No one knows how. pic.twitter.com/MafntG7RkP
— Tay 💖 (@tayvano_) April 18, 2023
Und am schlimmsten: Keiner weiß, was geschah. Es ist, als würde einem der Boden unter den Füßen weggezogen.
Die Opfer sind nicht Newbies, Gelegenheitsuser oder Amateure. „Das ist NICHT eine billige Phishing-Seite oder ein beliebiger Betrüger. Es hat KEINEN Noob erwischt. Es trifft NUR OGs [Original Gansters = Early Adopter]“.
Die meisten der betroffenen Adressen gehören aktiven Usern, die viele Wallets führen, mit Token oder im Space arbeiten. Teilweise werden die Token sogar direkt in der Wallet gegen Ether gewechselt, dann heraustransferiert und später gebündelt.
1001 Möglichkeiten, wie man Coins verlieren kann
Was genau vorfiel, bleibt rätselhaft, und man könnte stundenlang spekulieren. Johannes Pfeffer von corpus.venture bestätigt aber, dass alle „im Dunkeln stochern“, was genau vor sich geht.
Ist etwas mit der Kryptographie kaputtgegangen? Das wäre der Supergau, der schwarze Schwan, die nukleare Option, die den ganzen Kryptomarkt zerstören könnte. Billionen von Dollar basieren darauf, dass ECDSA, also Signaturen auf Basis elliptischer Kurven, halten. Hat ein Geheimdienst einen Quantencomputer angeworfen, der ECDSA potenziell brechen kann? Oder ist es ein potenzieller Angriff, der vor kurzem vorgestellt wurde?
Man kann, höchstwahrscheinlich, entwarnen. Denn es sind auch Adressen betroffen, die noch niemals etwas versendet haben. Sie haben weder Nonces noch den öffentlichen Schlüssel enthüllt, was selbst die potenziellen, aber hochspekulativen Angriffe, über die man derzeit nachdenkt, unmöglich macht. Daher schließt Johannes ein Scheitern der Kryptographie zu „99,99 Prozent“ aus.
Dass Adressen bestohlen wurden, die noch nie Transaktionen gezeichnet haben, ist freilich nicht weniger besorgniserregend. Wenn es nicht mal hilft, Coins auf einer Cold Wallet zu verwahren und niemals anzurühren – was schützt einen dann überhaupt? Doch diese kleine Zahl von Vorfällen gibt uns auch gute Hinweise darauf, was der Grund für die Serie von Einbrüchen in Wallets von Early Adoptern sein könnte. Zumindest wissen wir, dass es nichts mit dem zu tun hat, was während einer Transaktion passiert.
Möglicherweise wurde der Seed, von dem aus die Schlüssel abgeleitet werden, mit einem kaputten Verfahren geschaffen? Denn eine Wallet sammelt zunächst Entropie, um durch diese den Seed zu bilden. Wenn die Entropie zu gering ist, ist der Seed und damit auch der Schlüssel potenziell unsicher. Vor kurzem kam erst heraus, dass die Trust Wallet, eine Browser Wallet, nur eine Entropie von 32 bit verwendet – viel zu wenig. Mit so wenig Entropie kann man unmöglich einen sicheren Schlüssel erzeugen.
Dies trifft sich ganz gut mit Gerüchten darüber, dass im Darknet ältere Bitcoin Paper Wallets gecrackt werden. Eventuell wurden diese früher mit zu wenig Entropie gebildet, so dass es heute möglich ist, sie durch Brute-Force-Angriffe auszuräumen. Über solchen Szenarien wird schon lange nachgedacht, weshalb vermeintliche Paranoiker empfehlen, die Entropie für einen Seed auszuwürfeln.
Rumours on the dark net that someone has been cracking older $BTC paper wallets.
At first I didn’t believe it, but this is too coincidental now
I’ll be moving funds off Trezor into armoury.
This means Trezor 12 and 24 word is potentially vulnerable.
RIP #Bitcoin https://t.co/Ht38u7YKJp
— Crypto Bitlord (@crypto_bitlord7) April 24, 2023
Allerdings ist die TrustWallet zu neu, um etwas mit den Diebstählen zu tun zu haben. Der lange Zeitraum, über den hinweg die Adressen hin entstanden sind, und die Breite der betroffenen Wallets macht es zudem unwahrscheinlich, dass es sich um einen Bug in der Schlüsselgenerierung handelt.
Recent reporting on @tayvano_’s thread has incorrectly claimed that a massive wallet draining operation is a result of a MetaMask exploit.
This is incorrect. This is not a MetaMask-specific exploit. https://t.co/MiJ3QgslMy
— MetaMask 🦊🫰 (@MetaMask) April 18, 2023
So waren User von MetaMask betroffen, aber auch von Hardware-Wallets wie Ledger. Auf Twitter erklärt MetaMask öffentlich, dass es sich um keinen MetaMask-spezifischen Hack handele – man aber auch nicht wisse, was die Ursache sei. Der Bug in der Generierung von Schlüsseln wird damit deutlich weniger wahrscheinlich.
Aber was dann? Ein Leak von Seeds? Eine Malware? Das ist die Option, die derzeit am plausibelsten scheint. Johannes Pfeffer tippt „auf einen Trojaner, der aufgrund seiner Verteilungsart hauptsächlich bei OGs auftaucht.“
Dafür gäbe es Dutzende Optionen: Eine Web3-App wurde kompromittiert und hat Schadcode in die Wallet injiziert. Oder war es der Bug in IOS, der vor kurze herauskam, und der es erlaubte, Code mit Kernel-Privilegien auszuführen? Oder der LastPass-Breach, durch das womöglich manche Early Adopter ihre Seeds gespeichert haben. Im Prinzip könnte man die Ursache bei jedem großen Zero-Day-Exploit der letzten Jahre suchen.
Aber wie verträgt sich das mit Hardware-Wallets? Eigentlich sollten diese sicher vor Malware sein, da sie nie direkt online gehen und in einer gesicherten Umgebung außerhalb des eigentlichen Betriebsystems operieren. Hat jemand die Betriebssysteme von Trezor und Ledger gehackt? Kann Malware auch Hardware-Wallets befallen?
Oder ist es eine Kombination verschiedener Angriffe? Hat ein Hacker Seeds oder private Schlüssel gesammelt, und hat er die Liste nun verkauft oder räumt sie ab? Wenn ja, wie viele sind noch betroffen?
Derzeit gibt es noch viel mehr Fragen als Antworten – und eventuell sollte man auch alles, was gesagt wird, nicht ganz wörtlich nehmen. Manchmal vergisst man, dass man eine Seed von der Hardware-Wallet woanders hin exportiert hat, oder dass man doch schon mal eine Transaktion getätigt hat. Was auf den ersten Blick wie gebrochene Kryptographie wirken mag, kann auf den zweiten Blick nur ein gebrochenes Gedächtnis sein.
Doch es bleibt beunruhigend: Es gibt mehr Möglichkeiten, Kryptowährungen zu verlieren, als wir hier aufzählen können.
Er ( alliedchargeback@swissmail.com ) könnte das wissen, weil er angeblich gestohlene Coins zurückholen kann.
Ich hätte noch eine mögliche Erklärung parat… Erst vor ca. zwei Monaten haben wir uns bei Monero über einen ungewöhnlichen, kurzzeitigen Hashrate-Sprung gewundert, in der Spitze über 1GH/s, was bei RandomX mindestens 100.000 moderne Ryzen CPUs oder 10.000 APYCs bedeuten würde:
https://www.reddit.com/r/Monero/comments/11e2u63/the_curious_case_of_hashvault_1ghs_occasional/
Letztere sind sündhaft teuer, erstere eben auch nicht günstig und man kann diese nicht wie GPUs zuhauf in einem Rechner bündeln, sondern benötigt für jede CPU ein Motherboard, Netzteil & Co. – Es gibt multi-CPU Motherboards, diese sind aber ebenfalls sündhaft teuer.
Es gab scheinbar zwei Testläufe, aber profitabel ist das kaum, die Hashrate stellte damals ca. 1/3 der gesamten HR und bei insgesamt 432 XMR + Fees täglich wären das überschlagen vielleicht 150 XMR binnen 24 Stunden, die Spikes waren aber jeweils nur ca. 4-6 Stunden für wenige Tage, insgesamt waren es bei zwei „Angriffen“ von jeweils mehreren Tagen ca. 330 XMR zu je 150$, ein Ertrag von ca. 50.000 USD.
Man überlege sich, woher man diese CPU Power bekommen könnte… Entweder ein Supercomputer oder ein Cloud-Cluster von möglicherweise 10-100 Tausenden an Servern, exklusiv. Mir fallen auf die Schnelle nicht viele ein, die das leisten können (selbst zu Lasttiefen, man sieht ja in der Hashrate deutliche Schwankungen, jeweils auf Tages/Nachtzeiten) – Amazon, Google, Microsoft, wer noch? NSA?
Eine andere Möglichkeit wäre, wie der „Large Bitcoin Collider“, über den Du hier https://bitcoinblog.de/2017/04/06/das-weiss-ja-keiner-einige-behaupten-das-weil-sie-die-alternative-aengstigt/ vor Jahren berichtet hast, zu versuchen, neue Keys zu generieren. Die Methode lässt sich bei Bitcoin und Ethereum sehr effizient implementieren: Generierte public Keys gegen das aktuelle UTXO bzw. die aktuellen Unique Wallets prüfen – in Millisekunden, man benötigt keine Node oder gar Blockchain dafür.
Hier wird bei Monero ein riesiger Nachteil plötzlich zum Vorteil: Selbst mit einer synchronisierten Node benötigt man auf einer modernen CPU durchaus eine halbe Stunde, um die generierten Keys auf Eingänge zu prüfen, denn man muss tatsächlich jeden Output auf der Blockchain mit seinem Schlüssel scannen. Unmöglich, einen Brute Force Key Generierungsangriff zu fahren, denn selbst wenn man eine Kollision findet, bekommt man sie nicht mit.
Netter Bonus-Vorteil von Monero.
Was meinst du, wie sehr kann ein Supercomputer Outputs finden und die Suche parallelisieren?
Klar, das Scannen der Outputs mit dem Zufallsschlüssel kann man perfekt parallelisieren, die Outputs müssen aber für jeden Schlüssel einzeln gescannt werden. Vielleicht kann man mit einem Batching in der Art „generiere 1.000 Schlüssel“ und prüfe diese jeweils für Output X um 10% effizienter implementieren, aber das ist es schon. Mit 10 CPUs braucht man statt 30 Minuten pro Key „nur“ noch 3.
„dummerweise“ hat Monero erst vor einigen Monaten „Prefixes“ eingeführt, die den Scanvorgang um etwa x10 beschleunigen, da man mit einem zusätzlichen Bit pro Output als Empfänger gleich einen großen Teil ausschließen kann, ohne die Privatsphäre zu berühren. Aber selbst das ist nicht praktikabel, denn ein Bitcoin/Ethereum Key lässt sich unterhalb einer Millisekunde prüfen, ob die Wallet eine non-zero Balance hat, bei Bitcoin aktuell knapp 50 Mio., bei einer >0,01 Balance sind wir nur noch bei ca. 12 Mio. und lässt sich als geordnete Liste darstellen, die innerhalb von Nanosekunden nach einem Match durchsuchbar ist: https://cdn.glassnode.com/placeholders/metrics/addresses.MinPointZero1Count.png
Bei Monero kann man zwar das TXO Set auch als geordnete Liste darstellen, aber es bringt nichts, da eine einfache Suche nach einem Match nicht ausreicht, man muss den Key für jedes einzelne probieren (dauert einzeln auch Nanosekunden, aber mittlerweile wohl knapp Milliardenfach, kann die Zahl nachreichen). Als User, der seine Seed von einem Cold Wallet herstellen will, ist das nicht so tragisch, denn man kennt ungefähr das Datum der Erstellung und scannt erst ab dieser Höhe, aber als Angreifer sind gerade die frühen Outputs vielleicht lukrativer als spätere, da sie damals nicht viel wert waren… Man merkt beim Sync, dass die ersten ca. 30% der Blockchain ziemlich zügig gescannt werden, dann wird es richtig langsam, als RingCT eingeführt wurden und die Transaktionen ~14kB schwer waren, Bulletproofs haben sie dann um 80% optimiert, Bulletproofs+ dann nochmal um fast die Hälfte.
Warum das eigentlich ein großer Nachteil für Monero ist? Der Scan des Wallets hat durchaus lange gedauert, aber mittlerweile mit den Prefixes ist das kein großes Thema mehr, weil die Wallet ja weiß, wo sie das letzte Mal aufgehört hat und ein Scan von mehreren Tagen History dauert wenige Sekunden auf einer lokalen Node, über eine schnelle Remote Node vielleicht 30 Sekunden, ohne irgendeinen Schlüssel mit der Remote Node zu teilen übrigens.
Ich habe auch keine Sorgen, dass wir schon heute x100 skalieren könnten, ohne irgendwelche Änderungen am Code. Würde halt dauern, dynamische Block Size würde das von heute auf morgen verhindern, wir bräuchten wahrscheinlich mehrere Monate (auch das kann ich berechnen und nachreichen). Zudem sind Bulletproofs++ bereits mehr oder weniger fertig für die nächste Hard Fork und es wird intensiv an Seraphis / Jamtis gearbeitet, was man Monero 2.0 nennen könnte, weil es das größte Update in der Geschichte Moneros sein wird und nicht ohne neue Adressen auskommen wird. Dafür dann Ring Größen von 128-512 (je nach Optimierung), viel bessere & einfachere Möglichkeiten von Audits, denn heute bringt ein View Key ohne Key Images (welche ohne Spend Key nichts erlauben) aller eingehenden Transaktionen nur soviel, welche Eingänge es gab, aber nicht, ob diese schon wieder für ausgehende Transaktionen genutzt wurden. Das ist auch ein Problem beim Change, denn der poppt beim View Key alleine als eingehende Transaktion auf und wenn ich Dir 1 XMR von einem 10 XMR Output schicke, sieht mein Auditor 9 XMR Eingang bei mir. Aber wie gesagt, bereits in Arbeit, selbst Testcode ist schon vorhanden, aber bis das alle Code Reviews und externe Audits durch hat, kommt höchstwahrscheinlich eine Zwischenfork mit Bulletproofs++ und moderaten Optimierungen bei der Größe und Verifikation der Transaktionen von 10-30% bei leicht erhöhter Ring Größe (20-25 ist mein Tipp).
Wem das nicht zu viel ist, kann gerne zur MoneroKon in Prag kommen, muss dann aber auch mit meiner Anwesenheit klarkommen. Christoph bekommt als Journalist freien Eintritt, alle anderen müssen 132€ für die drei Tage Konferenz berappen. Zahlbar per SEPA, Kreditkarte (geht nicht ohne) und natürlich Monero und Bitcoin. Ist übrigens eine Non-Profit Veranstaltung, eventuell anfallende Gewinne fließen in das Budget der nächsten. Die (vorläufige) Schedule ist schon online und ich würde mich freuen, wenn „der Bergmann“ auch dabei wäre!
Diese Methode vom „Large Bitcoin Collider“ wäre Brute Force für alle möglichen Keys, 10 hoch 77 bei ETH, auch bei Millisekunden pro Key würde das viele Millionen Jahre dauern. Darauf beruht ja das ganze System.
Mit jeder neuen Adresse verringerst Du den Space der Keys, Du suchst ja nicht nach einem bestimmten. Der LBC hatte damals (nach eigenen Angaben) bereits drei Kollisionen bei Bitcoin gefunden. Natürlich ist das nicht nachweisbar, aber Kollisionen sind unabdingbar, siehe Mining Difficulty und es kommt trotzdem noch gelegentlich zu orphaned Blöcken.
Aber man kann sich das mit den Vanity-Adress-Generatoren etwas einfacher vor Augen führen. Selbst Christoph hat damals die 1bergmann Adresse binnen weniger Tage auf damals durchschnittlicher Hardware generiert.
Oder stell Dir mal vor, wenn Du öfters „Mensch ärgere Dich nicht“ spielst, wie oft es vorkommt, dass jemand in der Runde 6, 7 oder 8 Mal eine „6“ hintereinander würfelt. Mir ist das jedenfalls schon einige Male vorgekommen, die Wahrscheinlichkeit dafür kannst Du Dir ausrechnen.
Das Thema scheint aber bis jetzt nicht so wichtig zu sein, dass sich Core-Entwickler von Bitcoin oder Eth darum kümmern, ebensowenig kommt es in den populären Podcasts vor. Bei Unsicherheit in der Cryptographie gäbe es kein anderes Thema mehr.
Dieser Kommentar blieb mir vorhin verborgen, wahrscheinlich weil ganz unten.
{SARKASMUS AN}
Ja, man kann auf die Core-Entwickler hoffen, einen Greg Maxwell, der wirklich sinnvolle Erweiterungen für Bitcoin entwickelt hat, etwa Confidential Transactions. Waren aber nicht gut genug für Bitcoin, aber immerhin für seinen Liquid Shitcoin. Ein LukeDashJr (dienstältestes Core Mitglied), der vor ca. 2 Jahren für sein Hurricane-geschädigtes Haus gebettelt und vor ein paar Monaten behauptet hat, seine Bitcoin Wallets im Wert von mehreren Millionen Dollar würden gehackt worden. Aber er hat immer Gutes getan, in der Gentoo Linux Binary, die er gemanaged hat, hat er das böse Satoshidice Gambling unterbunden, dafür hat er etliche Bibelverse auf die Bitcoin Blockchain gebracht.
{SARKASMUS AUS}
Soll ich mit Trollen wie Adam Back, Jimmy Song, Giacommo Zucco und Co. weitermachen?
Wenn die das alles nicht für wichtig erhalten, dann können wir getrost um unsere Coins sein. Gute Nacht!
Hallo Paul,
so schnell trifft man sich in den Kommentaren wieder 😉
Auch wenn dies von Dir sarkastisch ausgedrückt wurde, was ist aber bitteschön an einem Riccardo Spagni (Fluffypony) besser? Ich habe nichts gegen ihn und seine Geschichte mit dem Bootsunfall wo er seine Monero Private Keys verloren haben soll, aber für einen ehemaligen Mitgründer und Entwickler war das auch schon eine bemerkenswert „komische“ Angelegenheit.
Also ich kenne die Personen weder persönlich, noch verfolge ich deren Kommentare auf Twitter oder sonstigen Portalen. Ich habe aber allen Respekt vor deren Absichten, mit Bitcoin eine Alternative zum bisherigen Fiat-Geldsystem zu schaffen, und ich finde es deshalb ungerechtfertigt, sie pauschal als Trolle zu verunglimpfen. Zum Beispiel finde ich es interessant den Blockchain Status über Satelliten zu propagieren, oder mit Liquid eine zweite Ebene einzuführen, auch wenn es derzeit noch wenig Anwendung dafür zu geben scheint. Zumindest setzen sie sich für das Bitcoin Ökosystem ein, auch wenn es vielleicht auf eine Weise geschieht, die nicht jedem gefällt. Mit Sicherheit gehört dazu auch Umsätze und Erträge zu generieren, aber ich habe nicht den Eindruck, dass sie dies auf irgendeine betrügerische Weise versuchen. Je mehr libertär denkende Leute sich in Krypto engagieren, und sich für deren Verbreitung einsetzen, um so besser. Es ist ja auch ein Grundgedanke des Libertarismus anderen zuzustehen ihre eigenen Ansichten zu vertreten, und umzusetzen.
Hoi, die Bubble der Aktiven hier ist ja auch nicht gerade groß 😉
Guter Einwand, lass mich aufklären… (Vorsicht, biased, da ich ihn persönlich kenne, er ist noch viel sarkastischer als ich, hält sich aber mit Kritik zu Bitcoin zurück). Erstmal war er nie Entwickler, sondern Lead Maintainer, nach dem frühen Fork von thankful_for_today, der Monero Merge Mining mit dem Bytecoin Scam durchsetzen wollte und 7 OGs weggeforkt haben. Fluffy hat aber nach und nach seine Macht an andere verteilt, er ist auch nicht mehr Maintainer.
Das „boating accident“ ist ein running Gag in der Community, eine Art Fluffy´s, Monero zu promoten. Warum? Bei Monero gibt es anders als bei Bitcoin eine plausible Abstreitbarkeit. Wenn Du in einem Regime lebst, das Zugriff auf Deine Coins will, die Du irgendwann nachweislich gekauft hast, kannst Du bei beiden behaupten, sie bei einem Bootsunglück verloren zu haben. Dumm nur, dass Du die Bitcoin dann auch nie wieder anfassen darfst, weil es jeder mitbekommt, bei Monero wird Dein Output statistisch 16 Mal von anderen Transaktionen verwendet, manche nie, mache über 100 Mal, Du hast keinen Einfluss darauf.
Ähnlich sieht es mit seiner ständigen Aussage „don‘t buy Monero“ aus, wofür er immer Kritik von einigen bekommen hat, er hat den Satz erst einige Jahre später um „unless you have a use for it“ vervollständigt. Ihm ging die Spekulation um Krypto immer gegen den Strich und gipfelte in seiner Ankündigung, auf einer Konferenz etwas großes anzukündigen, worauf er sarkastisch die „Monero Enterprise Alliance“ angekündigt hat, hat viele Trader sehr erbost, weil sie auf steigende Kurse gesetzt haben, aber das Gegenteil eingetroffen ist. Genau damit wollte er den Leuten zeigen, dass einzelne Personen oder deren Ankündigungen Bullshit sind. Was zählt, ist was geliefert wird.
Ähnlich mit dem Barolo Meme, Fluffy ist ein leidenschaftlicher Weinsammler.
Die einzige mir bekannte „valide“ Kontroverse war um die Auslieferung aus den Staaten nach Südafrika, wo er vor Jahren, noch vor Monero bei seinem früheren Arbeitgeber 100k Dollar veruntreut haben soll. Kann ich nicht beurteilen, hab ihn seitdem auch nicht persönlich gesehen und geht mich auch nichts an. Er hat aber damals zum Schutz des Projekts seinen Zugang zum aus Spenden gespeisten Dev Fund sofort abgegeben und es wurden neue Keys generiert, gleiches gilt für das GitHub Repo.
Ich kenne die Personen auch nicht persönlich, aber ich verfolge ihre Aussagen nicht nur auf Twitter oder YouTube, sondern habe mit allen schon auf Twitter diskutiert. Bis auf Adam Back hat das meist in einem Ban geendet, sie wollen keine Gegenargumente unter ihren Aussagen sehen, auch wenn viele erstmal auf die Diskussion eingestiegen sind. Sobald es tiefgründig wurde, folgte der Ban.
Satelliten hören sich in der Tat cool an, kennst Du aber jemanden, der sie nutzt oder brauchen würde? AFAIK war das nur PR, denn es gibt nur eine punktuelle Abdeckung an ein paar Orten. Meine Meinung zu Liquid ist auch negativ, weil man Bitcoin geklont hat, mit größerer Block Size, schnelleren Blöcken, aber auf ein paar trusted Nodes, die die Gebühren kassieren sollen (bislang eher dürftig). Dazu hat man Confidential Transactons eingebaut, die für Bitcoin zu böse waren, um implementiert zu werden. Meine Vermutung ist eher, dass man es für den Geldgeber Tether gemacht hat (seit Jahren und Anfang einziges Asset neben Bitcoin auf Liquid).
Paul – mich wundert, dass du beim Thema „Wahrscheinlichkeit“ immer mit Gefühlen argumentierst oder eigenen Erfahrungen, wo du sonst so logisch bist. Wahrscheinlichkeit ist nur Mathematik. Unser Gefühl versagt einfach bei großen Zahlen.
Danke für den Hinweis / die Frage!
Ich bin ein Mensch und habe natürlich auch Gefühle, insbesondere in der Ineraktion mit Menschen. Bin auch kein Journalist, der in der Regel objektiv berichten sollte (was imho utopisch ist, aber man strebt das Ziel an).
Konkret wo argumentiere ich mit Gefühlen bei der Wahrscheinlichkeit? Vielleicht kann ich es sachlicher ausdrücken.
In der subjektiven Erinnerung an eigentlich unwahrscheinliche Ereignisse, wie Christophs Vanity-Adresse oder das Mensch-ärgere-dich-nicht oder Erfolge des Large-Bitcoin-Colliders sehe ich eine gefühlsmäßig falsche Einschätzung von Wahrscheinlichkeiten bei dir.
Kahneman hat in seinem Buch „Schnelles Denken, Langsames Denken“ dazu ein Kapitel „Seltene Ereignisse“. Zitat: „Menschen überschätzen die Wahrscheinlichkeiten unwahrscheinlicher Ereignisse; Menschen übergewichten unwahrscheinliche Ereignisse bei ihren Entscheidungen.“ Davon lebt z.B. das Lottospiel.
Natürlich kann auch ein sehr unwahrscheinliches Ereignis, wie 6 mal hintereinander eine 6 (1 zu 46000) beim Würfeln jederzeit eintreten und natürlich kann ein Large-Bitcoin-Collider schnell eine Adresse mit Guthaben finden – Zufall eben. Aber wie oft kommt das auf Dauer vor, – hier bleibt es bei der Mathematik.
Sollte man seinen Lebensplan darauf aufbauen, dass man mal im Lotto gewinnt oder sollte man nicht in Bitcoin investieren, weil schon einmal eine Adresse mit Guthaben gefunden wurde?
Und dass in den letzten Ereignissen gleich mehrere Adressen durch Brute-Force abgeräumt wurden – da würde ich doch lieber erst nachrechnen, wie viel Rechenleistung das denn benötigt, bevor Panik aufkommt.
Okay, etwas sachlicher, auch wenn das Thema durchaus einer Bachelorarbeit würdig wäre…
https://github.com/JeanLucPons/BTCCollider
Bei einer Entropy von vollen 160bits aktuell „wahrscheinlich“ sicher, aber ich habe schon Adressgeneratoren mit 32 oder 64 Bit gesehen. Gehen wir von 128 Bit aus, braucht eine alte 1050 Ti GPU statistisch 42.000 Jahre, um eine Kollision zu finden.
Wir haben bei Bitcoin laut einer Recherche über 1 Milliarde genutzter Adressen:
https://cryptoslate.com/research-bitcoin-has-over-1-billion-unique-addresses-leaving-eth-ltc-in-the-dust/
Um eine Kollision mit irgendeiner davon zu finden, bräuchten wir bei 128 Bit lediglich ca. 20 Minuten. Aber das wäre zu einfach, denn spätestens seit HD Wallets werden aus einem Key potenziell unendlich Subadressen generiert, man müsste also auch diese generieren.
Bleiben wir also bei den von mir recherchierten 12 Millionen Adressen mit Balance größer 0,01 BTC. Bei 128 Bit Entropie, dann wären es ca. 30 Stunden, freilich nur wenn alle mit einer 128 Bit Entropie erstellt worden wären. Wenn nur jedes Tausendste Wallet so erstellt wurde, sind es 30.000 Stunden oder 1.250 Tage bis ich statistisch eines davon finde. Mit einer einzigen (eher alten) GPU. Bei 100.000 GPUs gleichzeitig wären es wieder etwa 20 Minuten.
Aber meine Annahme mit jedem Tausendsten schlecht generiertem Wallet ist nicht belegbar, also hier noch mit vollen 160 Bit Entropy:
Eine Kollision lässt sich laut oben genannter Quelle binnen 3.300.000.000 Jahre finden, für eine bestimmte Wallet und mit einer 1050T GPU. Da das parallelisierbar ist, können wir mit 100.000 GPUs also auf 33.000 Jahre kürzen. Wir suchen aber keine bestimmte Kollision, sondern irgendeine in unserem Set von 12 Millionen. Und dann komme ich statistisch auf fast genau einen Tag.
Ich bin aktuell unterwegs und mobile only, kann also sein, dass ich irgendwo ein Komma falsch gesetzt oder einen Gedanken übersprungen habe, rechnet bitte selbst nach. Auch habe ich nur eine Datenquelle genutzt, die vielleicht nicht akkurat sein könnte, aber bei 7 Zeilen Code dürften wenige Nanosekunden reichen, er nutzt hier auch nur die GPU, die CPU wäre also für den Abgleich in der Liste verfügbar.
Interessante und wichtige Diskussion! Soweit ich sehe, geht es bei diesem Collider auf Github um eine spezielle, nur partielle Kollision. Aus der Beschreibung:
„BTCCollider generiert BTC p2pkh-Adresspaare (und die dazugehörigen privaten Schlüssel), die das gleiche Präfix haben. Er sucht nach einem Paar unterschiedlicher HASH160, die mit denselben Bits beginnen (eine partielle Kollision), indem er die sogenannte „Distinguished Point“-Methode verwendet, die es ermöglicht, das Geburtstagsparadoxon durch parallele Berechnungen effizient zu nutzen. BTCCollider unterstützt Multi-GPU mit CUDA und basiert auf dem VanitySearch-Verfahren.“
Ein anderer, verteilter Collider ist dieser:
https://lbc.cryptoguru.org/man/theory#instant-check-all
Die Absicht wird so beschrieben:“ Gegeben eine Bitcoin-Adresse ‚adr1‘ von einem zufälligen (unbekannten) privaten Schlüssel mit einem numerischen Wert zwischen 2hoch160 und 2hoch256: Finde einen anderen privaten Schlüssel im Intervall zwischen 0 und 2hoch159, der zu derselben Bitcoin-Adresse führt.“
Auch eine spezielle Kollision.
Wenn ich es richtig verstehe, wird bei beiden nicht der ganze Adressraum abgesucht, über den alle Adressen mit Guthaben erreichbar wären.
In meiner Kalkulation habe ich das Geburtstagsparadoxon außer Acht gelassen, welches mit steigender Anzahl von Ergebnissen die Wahrscheinlichkeit einer Kollision darunter massiv steigert. Nichtsdestotrotz halte ich es für eine valide Möglichkeit, dass Adressen attackiert werden, die einen Generator mit schwächerer Entropie als 160 Bit genutzt haben.
Eine ausführliche Diskussion auch hier:
https://bitcoin.stackexchange.com/questions/22/is-it-possible-to-brute-force-bitcoin-address-creation-in-order-to-steal-money
Ein weiterer Aspekt ist der wirtschaftliche: Wer schon so viel in Rechenleistung investiert, wird mit Bitcoin-Mining viel leichter sein Geld verdienen als mit der Suche nach Kollisionen.
Der ist einfach erklärbar: ASICs, welche CPU & GPU Mining um etliche Potenzen outperformen.
Ich gehe nicht davon aus, dass die veranschlagten 100k CPUs im Spike der Monero Hashrate regulär verwendet wurden, viel wahrscheinlicher ist ein interner oder externer Hack bei einem der großen Cloud Provider.
Christoph:
Ich finde es unglaublich, dass auch nach Jahren der Crypto-Entwicklung die grundsätzliche Frage nach der Sicherheit der Cryptographie immer noch Verunsicherung erzeugt.
Kennst du nicht einen Fachmann, z.B. bei Bitcoin.de, der hierzu einen Artikel schreiben kann und dann in den Kommentaren auch Fragen beantwortet?
Die Sicherheit davon Algorithmen ist nicht binär. Gerade bei rng gab es schon etliche Probleme, selbst bei Linux Distributionen und die Seed Generierung basiert vollständig darauf, es sei denn man erwürfelt sie tatsächlich.
Danke für den Hinweis. Wie bei jeder Technologie, kann auch hier Unvorhersehbares passieren. Trotzdem kann man sich normalerweise auf Technologie verlassen, vor allem, wenn sie schon länger in der Anwendung ist. Immerhin gibt es auch Tests auf Zufälligkeit.
Mich interessiert hier weniger das seltene, unvorhersehbare Ereignis, sondern das Prinzip hinter der Technologie.