Über die Privatsphäre bei Lightning: Wie anonym sind Offchain-Zahlungen mit Bitcoin wirklich?
Über die Privatsphäre bei Lightning herrscht weithin Unklarheit. Die einen behaupten, das Offchain-Netzwerk mache Bitcoin-Transaktionen vollkommen anonym – während die anderen meinen, es verbessere die Privatsphäre von Bitcoin so gut wie gar nicht. Wir bringen etwas Licht ins Dunkel.
Wie privat ist Lightning? Ebenso transparent wie Bitcoin? Schafft es eine Privatsphäre, die an die Anonymität von Privacycoins wie Monero herankommt? Oder liegt die Wahrheit irgendwo dazwischen? Und wenn ja, wo genau?
Das Thema ist, wie so vieles um Lightning, kompliziert, aber wichtig. Denn Lightning soll ja die Zukunft des Bezahlens in der Bitcoin-Welt sein. Daher wäre es gut, zu wissen, wie privat das Bezahlen in dieser Zukunft ist. Anders als bei Bitcoin ist dies aber sehr viel schwieriger konkret zu sagen.
Wir haben dafür ein Paper gelesen, in dem eine Gruppe von Forschern im Herbst 2021 eine “empirische Analyse der Privatsphäre im Lightning Netzwerk” vorlegt. Soweit ich es sehe, ist es die umfassendste Untersuchung zum Thema, die so gut wie jeden bekannten Angriff darstellt und testet.
Was bei Lightning öffentlich ist und was privat ist
Um zu bewerten, wie es um die Privatsphäre bei Lightning bestellt ist, muss man sich zunächst vergegenwärtigen, was die Technologie verspricht.
Lightning ist ein Netzwerk von Payment Channels, durch das man Bitcoin-Zahlungen routen kann. Wen dies verwirrt, der sollte lernen, was Payment Channels sind und wie diese das Lightning Netzwerk bilden.
Das Design von Lightning hat den ehrenwerten Anspruch, so viele Elemente öffentlich zu machen, wie es nötig ist, damit Transaktionen ankommen, und alles andere privat zu halten.
Die folgenden Elemente sind öffentlich:
• Die Knoten des Netzwerks: Die Node-ID, gegebenenfalls ein Label, sowie die IP-Adresse. Mithilfe von Tor kann (und sollte) man die IP-Adresse verbergen.
• Payment-Channels: Die mit ihnen verbundenen Bitcoin-Adressen sowie die gesamte Kapazität des Channels in Bitcoin. Es ist möglich, private Channels zu bilden, die nicht öffentlich sichtbar sind. Allerdings routen diese keine Zahlungen und spielen keine Gebühren ein.
Bei Lightning werden zwei Elemente öffentlich verbunden, die man eigentlich strikt trennen sollte: IP-Adresse und Bitcoin-Adresse. Im schlimmsten Fall erlaubt dies einem Angreifer, die gesamte Bitcoin-Wallet samt Inhalt zu identifizieren – und den physischen Standort zu lokalisieren.
Daher sollte man schon aufgrund dieser Daten eine separate, messerscharf von anderen Coins getrennte Wallet für Lightning verwenden und den Node am besten über Tor betreiben, zwingend sogar, wenn der eigene Haushalt an einer fixen IP-Adresse hängt.
Abgesehen von diesen Informationen genießt man in Lightning eine an sich weitreichende Privatsphäre. Die folgenden Informationen sind nicht öffentlich:
• Die individuellen Guthaben eines Payment-Channels. Ein Beobachter erkennt nur die gesamte Kapazität, nicht aber die ein- und ausgehende Liquidität der beteiligten Parteien.
• Zahlungen. Anders als Bitcoin-Transaktionen werden Lightning-Transaktionen nicht an alle Knoten im Netzwerk propagiert. Sie gehen lediglich an die Knoten, die auf ihrem Weg zum Ziel liegen.
• Sender und Empfänger. Dank des Onion-Routings wissen die Knoten, die eine Zahlung weiterleiten, nicht, wer Sender und Empfänger ist. Sie wissen lediglich, wer der Vorgänger und Nachfolger auf dem Weg ist.
Dies ist das Versprechen. Würde Lightning es umsetzen, würde dies die Privatsphäre von Bitcoin enorm verbessern – trotz der transparenten Knoten und Channels. Denn Zahlungen an sich wären weitgehend anonym. Anders als auf der Bitcoin-Blockchain selbst könnte ein Beobachter nicht feststellen, wer wem was bezahlt.
Allerdings widerspricht nun eine Gruppe von Wissenschaftlern. Sie kommen in einer umfangreichen Analyse zum Schluss, dass “die Lücke zwischen potenzieller und tatsächlicher Privatsphäre signifikant” sei. Lightning schaffe es nicht, den selbstgesteckten Ansprüchen an Öffentlichkeit und Privatheit gerecht zu werden.
Das allerdings sollte man nicht einfach so stehen lassen. Die Wahrheit ist auch diesmal kompliziert.
Die Untersuchung der Forscher
In dem Paper arbeitet sich eine Gruppe von Forscher an den bekannten und möglichen Angriffen auf die Privatsphäre bei Lightning ab. Es handelt sich um die vier folgenden Angriffe:
1.) Auf private Channels.
2.) Auf die individuellen Guthaben.
3.) Auf das Onion-Routing (on-path privacy).
4.) Auf die Verborgenheit von Zahlungen für Nichtinvolvierte (off-path privacy).
Für die meisten dieser Angriffe gibt es bereits Vorarbeiten, die zum Teil theoretisch-skizzierend bleiben, zum Teil auch schon praktisch ausgearbeitet und getestet wurden. Die Wissenschaftler übernehmen und modifizieren diese und setzen sie praktisch um, entweder in einer Simulation oder im echten Lightning-Netzwerk.
Wir werden die im Paper ausgebreiteten Angriffe im Folgenden darstellen und versuchen, ein Urteil über sie zu bilden.
1. Private Channels
Ein normaler Payment-Channel ist öffentlich: Er wird an alle Peers propagiert, so dass jeder ihn einplanen kann, wenn er eine Route durch das Netzwerk sucht. Ohne diese öffentlichen Channels würde Lightning nicht funktionieren.
Allerdings gibt es auch private Channels. Diese werden nicht öffentlich gemacht. Ihre Eigentümer verdienen an ihnen kein Geld durch Gebühren, können dafür aber privat Geld überweisen.
Die Forscher behaupten nun, private Channels identifizieren zu können. Dazu nutzen sie Informationen auf der Blockchain: die öffentlich sichtbaren Onchain-Transaktionen.
Im ersten Schritt sammeln sie alle Transaktionen, die zwischen dem 12. Januar 2018 und dem 7. September 2020 einen Lightning-Channel eröffnet haben könnten. Dies war wohl der Untersuchungszeitraum. Im Prinzip handelt es sich dabei zunächst um alle SegWit-Transaktionen in diesem Zeitraum. Das sind 3,5 Millionen. Mit diesen Daten kann man offensichtlich noch nicht viel anfangen.
Daher haben die Forscher weitere Eigenschaften identifiziert, die Transaktionen ausmachen, die öffentliche Channels bilden. Etwa bestimmte Betragsspannen oder Merkmale der Outputs. Dadurch sank die Anzahl der in Frage kommenden Transaktionen auf 267.675. Das ist schon besser, aber weiterhin zu viel.
Unter normalen Umständen sind die Forscher an dieser Stelle am Ende ihrer Möglichkeiten angelangt. Dies ändert sich, wenn man den Channel schließt. Denn in diesem Moment enthüllt sich das Script, das in den Transaktionen steckt. Dadurch werden spezifischere Eigenschaften erkennbar (etwa die Sequence-Nummer oder das Multisig-Setup), was den Forscher erlaubt, 77.245 Transaktionen zu identifizieren, die potenziell einen privaten Channel bilden. Dies dürfte der Wirklichkeit schon deutlich näher kommen.
Schließlich haben die Forscher noch eine dritte Heuristik: Sie verbinden die Onchain-Adressen von Knoten, die einen öffentlichen Channel betreiben. Dies ist durch gebräuchliche Blockchain-Analyse-Techniken möglich. Auf Basis dieser Adressen finden sie potenzielle Payment-Channels, die nicht öffentlich gemacht wurden. So entdeckten sie 27.386 Transaktionen, die vermutlich einen privaten Channel gebildet haben.
Zusammenfassend:
- Ein privater Channel bleibt zunächst weitgehend privat
- Er wird aber durch Onchain-Analysen sichtbar, wenn man ihn mit demselben Node eröffnet, mit dem man öffentliche Channels unterhält
- Er wird durch Onchain-Analysen sichtbar, wenn man ihn schließt
2. Die Guthaben
Jeder öffentliche Payment-Channel gibt seine Kapazität bekannt. Dies hilft anderen Knoten, eine Route für Zahlungen zu finden. Allerdings bleibt privat, wie die Kapazität auf die beiden Parteien des Channels verteilt ist: Die individuellen Guthaben bleiben im Dunkeln. Dies macht das Routing teilweise schwieriger, schützt aber die Privatsphäre der User.
Es gibt allerdings Methoden, um diese Guthaben zu enthüllen. Dazu nutzt man etwa die Debug-Informationen als Quelle. Diese geben Knoten zurück, wenn sie dabei scheitern, eine Zahlung weiterzuleiten. Unser Forscher bauen auf diesem Angriff auf, ändern ihn aber etwas.
Es funktioniert etwa so: Der Angreifer hat zwei Knoten, A und D. Diese bilden Beginn und Ziel einer Route, die die Knoten B und C passiert. Über diese Route sendet A nun eine Payment-Hash (H) mit einem bestimmten Betrag. Diesen Betrag erhöht A sukzessive, bis die Zahlung scheitert. So erkennt er, wie hoch der Flaschenhals in dem Channel ist.
Um allerdings zu erfahren, wo der Flaschenhals liegt – bei B oder C, in deren ein- oder ausgehender Liquidität – benötigt der Angreifer die Debug-Informationen. Diese verraten die Position des Knotens, bei dem die Zahlung gescheitert ist und geben Hinweise zum Grund.
Die Forscher haben diesen Angriff im Herbst 2020 im Testnet ausprobiert. Das Setup ist extrem aufwändig: Sie mussten Channels bilden, die quasi an jeden Knoten andocken, und dann auch noch die maximale ein- oder ausgehende Liquidität haben. Vor allem der Channel von D zu C ist schwierig, da der Angreifer es schaffen muss, die Liquidität vollständig zu C zu schieben. Dies verursacht sowohl Mühe als auch Kosten.
Im Testnetz gab es 3.159 Knoten und 9.136 Channels. Die Forscher konnten sich nur mit 103 Knoten und 1017 Channels verbinden. Die Gründe hierfür waren vielfältig: Manche waren offline, anderen hatten nicht ihre IP4-Adresse publiziert, manche hatten ihre Ports geschlossen, andere lehnten den Channel ab.
Von den 1017 Channels, mit denen sich die Forscher verbunden haben, konnten sie von 568 die individuellen Guthaben bestimmen. Das sind insgesamt also weniger als 10 Prozent aller Channels.
Im Live-Netz ist der Angriff eine relativ teure Übung. Die Forscher rechnen dies vor. Sie gehen davon aus, dass sie Routen mit 4.811 Channels bilden, wofür sie selbst 2.191 Channels eröffnen müssten. Mir ist nicht ganz klar, warum so wenige, da es schon im Herbst 2020 mehr als 30.000 Channels gab.
Doch schon dies würde, zum Stand des Herbstes 2020, gut einen Bitcoin an Gebühren kosten und 110 Bitcoins in den Channels benötigen. Da sich seitdem die Anzahl der Channels und der Bitcoin-Preise etwa verdoppelt haben, haben sich die Dollarkosten seitdem mindestens vervierfacht.
Je mehr das Lightning-Netzwerk skaliert, desto teurer und aufwändiger wird ein solcher Angriff, und der Angreifer wird, gezwungenermaßen, zum Bitcoin-Holder.
Zusammenfassung:
- Ein Angreifer kann mit einer Erfolgschance zu etwa 50 Prozent erfahren, wie die individuellen Guthaben in einem Channel verteilt sind
- Dazu muss er sich aber mit den Channels verbinden. Dies wird erschwert, wenn man andere Ports verwendet oder den Node im Tor-Netzwerk betreibt
- Der Angriff kann durch eine Änderung / Abschaltung der Debug-Informationen weitgehend wirkungslos gemacht werden
- Der Angriff ist schon jetzt extrem teuer und aufwändig
- Kosten und Aufwand skalieren mit dem Lightning-Netzwerk und machen den Angriff ab einer bestimmten Größe mehr oder weniger unmöglich.
- Immun sind Private Channels, selbst wenn sie bekannt sind, sowie Channel mit einer “Übergröße”
3. Pfade
Eigentlich sollte ein Knoten, der auf der Route zwischen Sender und Empfänger einer Zahlung liegt, nur wissen, wer vor und wer nach ihm kommt. Ihm sollte unbekannt bleiben, ob seine direkten Nachbarn auf dieser Route Sender oder Empfänger sind. Das ist der Zweck des Onion-Routings.
Allerdings schlagen die Forscher eine Methode vor, dieses zu brechen. Diese ist aber bemerkenswert trivial, was das Paper unter Formeln und umständlichen Formulierungen verschleiert: Sie gehen davon aus, dass ihr Knoten, der eine Zahlung weiterleitet, das mittlere Glied eines Pfades ist, der Sender und Empfänger über eine einzige Zwischenstation führt.
Sie nennen diese Vermutung “H = 1”. Danach ermitteln sie, wie wahrscheinlich es ist, dass die Vermutung zutrifft.
Da es zwar möglich, aber sehr schwierig und aufwändig ist, dies im echten Lightning-Netzwerk auch nur einigermaßen zuverlässig herauszufinden, haben die Forscher dieses simuliert. In der Simulation kannten sie alle Channels und alle Sender und Empfänger, weshalb sie errechnen konnten, wie wahrscheinlich die Hypothese H = 1 ist.
Je nach Umständen lag die Wahrscheinlichkeit dafür zwischen 15 und 83 Prozent. Wenn eine Zahlung scheitert, aber der Knoten des Angreifers ausreichend Liquidität hat, ist klar, dass der Pfad länger ist, betonen die Forscher. Für was auch immer dies nützlich ist.
Zusammenfassung:
- je nach Umstand ist die Wahrscheinlichkeit, dass ein Angreifer richtig rät, wer Sender und Empfänger einer Zahlung ist, die ihn passiert, zwischen 15 und 84 Prozent.
- bei kurzen Wegen und gescheiterten Zahlungen steigt die Wahrscheinlichkeit.
- bei längeren Wegen – ab zwei Mittelsmännern – sinkt die Trefferquote mit der hier vorgestellten Methode offenbar auf Null.
- es scheint nicht möglich zu sein, Schätzungen zu prüfen.
4. Zahlungen
Der vierte Angriff richtet sich auf Zahlungen. Kann ein Knoten, der nicht Teil einer Route ist, überhaupt von Zahlungen erfahren?
Wenn das Design von Lightning hält, was es verspricht, sollte der Knoten dies nicht können. Doch die Forscher behaupten, einen Weg gefunden zu haben.
Dazu beginnen sie mit dem oben vorgestellten Angriff auf die Guthaben. Der Angreifer macht eine Momentaufnahme von allen Channels und den in ihnen befindlichen Guthaben zum Zeitpunkt T. Etwas später, zum Zeitpunkt t+τ, schießt er den nächsten Schnappschuss. Dann vergleicht er die beiden Aufnahmen; die Änderungen der Guthaben zeigen, welche Zahlungen geschehen sind.
Im einfachsten Fall mag das funktionieren – wenn es im Zeitfenster maximal eine Transaktion je Route gab. Wenn sich aber mehrere Zahlungen überlappen, wird es schwieriger. Dann benötigt man Heuristiken, um die Zahlungen zu trennen.
Die Wissenschaftler stellen eine solche Heuristik vor. Diese funktioniert desto besser, je kürzer die Zeitintervalle zwischen den Aufnahme sind.
Der Algorithmus “verschmilzt” Pfade. Er arbeitet, laienhaft ausgedrückt, so ähnlich, wie man die Fläche eines Kreises durch Nährungsverfahren berechnet, wenn man Pi nicht kennt: Sie kumulieren und trennen die geänderten Beträge so lange immer feiner, bis daraus ein Gefüge von Zahlungen entsteht.
Dabei aber hat der Algorithmus mehrere Schwachstellen. Er scheitert etwa, wenn Zahlungen dieselben Beträge haben oder wenn ein einzelner Channel in einem Intervall mehrere Zahlungen durchlässt. Dies aber geschehe, sagen die Forscher, relativ selten, wenn die Intervalle zwischen den Aufnahmen kurz sind. Das Problem, dass die Ermittlung der Guthaben aber “für einige (oder viele) Channels” scheitert, bestehe jedoch fort.
Um das Verfahren zu testen, haben die Forscher erneut die von ihnen aufgebaute Simulation des Netzwerkes verwendet. Sie haben Zeitintervalle zwischen den Aufnahmen von einer bis 32 Sekunden für jeweils 30 Tage ausprobiert. Dabei zeigte sich, dass sie 66 bis 74,1 Prozent aller Zahlungen mit einer Präzision von beinahe 95 Prozent erkennen können. 30 Sekunden seien einigermaßen realistisch, da es so lange dauere, den Angriff auf die Guthaben auszuführen.
Ich bin aber nicht sicher, ob sie dabei die oben genannten Hinfälligkeiten dieses Angriffs vollständig einrechnen.
Zusammenfassung:
- Ein nicht beteiligter Angreifer kann Zahlungen erkennen, indem er Schnappschüsse der Guthaben vergleicht
- Die Kenntnis der Guthaben ist teuer, aufwändig, unzuverlässig und deckt nur einen Teil des Netzwerks ab (siehe oben)
- Der Angriff verlangt, dass der Angriff auf die Guthaben dauerhaft gemacht wird: er muss neue Knoten und Channels fortlaufend integrieren.
- Ob die Ergebnisse aus der Simulation im Live-Netzwerk ebenfalls gelten, ist unsicher.
Alles in Allem
Das Paper der Forscher wirkt auf den ersten Blick beeindruckend. Sie formulieren mit vielen Heuristiken, Algorithmen und Formeln eine Reihe von Angriffen, die Elemente in Lightning enthüllen, die eigentlich privat sein sollten.
Die Aussage könnte man so verstehen: „Die Angreifer kennen deine privaten Channels. Sie wissen, wie viel Satoshi in deinen öffentlichen Channels liegt. Sie wissen, ob du der Sender oder Empfänger einer Zahlung bist, und sie kennen deine Zahlungen, selbst wenn sie keinen Node im Weg betreiben.“
Allerdings malt dies ein viel zu düsteres Bild von der Privatsphäre in Lightning. Denn tatsächlich verbindet jeder Angriff begrenzte Erkenntnisse mit einer hohen Unzuverlässigkeit und oft sehr hohen Kosten. Es mag möglich sein, Informationen aus Lightning zu extrahieren, die eigentlich verborgen bleiben sollten. Aber dies ist so unvollständig, unscharf und aufwändig, dass es fraglich ist, ob solche Angriffe tatsächlich eine ernstzunehmende Bedeutung genießen können.
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder
Christoph hat vor kurzem sein zweites Buch veröffentlicht: “Das Bitcoin-Kompendium: Netzwerk und Technologie”. Es ist eine überarbeitete Auslese seiner besten Artikel für dieses Blog. Ihr könnt das Kompendium direkt auf der Webseite Bitcoin-Buch.org bestellen – natürlich auch mit Bitcoin – oder auch per Amazon.
Tipps für Stories sind an christoph.bergmann@mailbox.org immer erwünscht. Für verschlüsselte Nachrichten nutzt bitte meinen PGP-Schlüssel — Auf Telegram! könnt ihr unsere News abonnieren.
Vielen Dank für die gute Zusammenfassung! Bei den Kosten für den Angriff kann man etwas optimieren, aber wie die Autoren bereits schreiben, riskiert man ggf. seine Coins in einem gewissen Grad.
Am einfachsten geht das, wenn man einen Channel selbst fundet und dann darüber eine Transaktion an eine Exchange (der man eben vertrauen muss) sendet und somit seine initiale Balance aufbraucht. Die Coins kann man dann wieder per Exchange an einen eigenen (anderen) Node schicken, zu dem die Exchange keinen Channel findet und wahrscheinlich selbst einen eröffnet, den man dann wieder leeren kann, um eingehende Liquidität zu bekommen. Für große Chainanalyse Anbieter würde es sich natürlich anbieten, entweder selbst große Nodes mit entsprechenden Channels zu betreiben und so noch mehr Daten zu sammeln, als ein Außenstehender oder mit den großen Nodes wie LNBig zusammenzuarbeiten und deren Daten aufzukaufen und ggf. deren Liqudität für das Probing zu nutzen. Die größte Hürde für Händler Adoption, eingehende Liqudität scheint bei diesem Angriff zumindest auch eine Hürde für den Spion zu sein. Sobald man genügend Nodes und Channels hat, kostet das Probing nichts mehr, man hat seine Coins lediglich eingefroren. Das Probing muss eigentlich auch kostenlos bleiben, denn wenn man Mal auf größere Multi-Route Zahlungen skalieren will, muss man auch etliche Routen austesten können und jeweils deren Kapazität ausprobieren können.
Mein Fazit: Lightning ist praktisch vollkommen privat gegenüber dem Kioskbetreiber oder Restaurant, die ich damit bezahle, der Merchant kann aber ein Problem bekommen, wenn ein großer Teil seiner eingehenden Zahlungen aus dubiosen Quellen stammen und er die Coins irgendwann an eine KYC/AML Börse schickt, die Chainanalyse nutzt. Leider weiß ich nicht, wie fortgeschritten das bei Chainalysis & Co. bereits ist, angekündigt wurde es bereits vor einem halben Jahr.
Hier ist auch ein interessantes Panel dazu von der Bitcoin 2022: https://www.youtube.com/watch?app=desktop&v=OwJL0J_nPDE&t=2h37m25s
Leider finde ich den Anfang schon erschreckend. „Bei Lightning werden zwei Elemente öffentlich verbunden, die man eigentlich strikt trennen sollte: IP-Adresse und Bitcoin-Adresse. “ Vermutlich würden 99% der Nutzer es auf dem Handy nutzen und da wird niemand Tor nutze . Ein Provider könnte also alle Walletadressen identifizieren oder liege ich da falsch?
Das ist leider weitgehend korrekt und könnte ggf. mit Deinen anderen Aktivitäten verbunden werden, man denke nur an die üblichen Datenkraken. Solange der Base-Layer nicht auf Privatsphäre setzt, sehe ich kaum Chancen, dass nächste Layer das ausbügeln können, denn alleine das Channel Opening gibt gewisse Daten über Dich heraus, sei es nur, wie groß Deine Wallet Balance damals war oder wie viel Du in den Channel gesteckt hast (oder Dein Channel Partner).
Dass niemand Tor auf dem Handy nutzt, halte ich übrigens für ein Gerücht, hier ein Beispiel für einen “simplen” Messenger, denn das Thema ist mit Signal & Co. weiterhin nicht wirklich vom Tisch: https://www.heise.de/ratgeber/Darknet-So-funktioniert-der-ausfallsichere-Messenger-Briar-7141420.html
Signal ist zwar relativ gut Ende-zu-Ende verschlüsselt, aber Du teilst mit dem Signal Server alle Deine Kontakte und wann Du zuletzt mit diesen kommuniziert hast, inklusive Größe der jeweiligen Nachricht. Wenn z.B. ein Whistleblower also über Signal einen mehrere GB großen Leak an seine Veröffentlichungspartner schickt, ist das ziemlich leicht auszumachen, inklusive Quell-IP und genutzter Telefonnummer (die in den meisten Staaten in irgendeiner Form registriert ist).
Ich kenne jetzt kein Android Lightning Wallet, welches Orbot unterstützt, aber im Prinzip sollte das implementierbar sein, Monerujo unterstützt auch wahlweise .onion Nodes für seinen Sync. Auf iOS ist das leider alles etwas komplizierter als auf Android, aber immerhin kann man ein VPN nutzen, sogar ein Apple eigenes, man legt das Vertrauen halt aus einer Hand in die nächste…
Insgesamt ist die alleinige Exposure von IP-Adressen für die meisten Anwendungsfälle nicht sooo relevant und eher ein Networking-Thema. Sie wird aber umso relevanter, wenn das Protokoll, welches auf ihr aufbaut zusätzlich identifizierbare (Meta)daten preisgibt.
Das klang vielleicht etwas überdramatisiert. Ein paar Relativierungen:
– auf dem Handy hat man idR keinen vollen Node und bildet entweder private Channels (etwa mit Acinq) oder benutzt den Channel eines treuhänders (etwa Bluewallet, Wallet of Satoshi etc.). Daher gibt es da nicht viel zu sehen.
– idR benutzt man auch eine “jungfräuliche Wallet” für LN, etwa indem man sich von einer Börse aus etwas auf die Wallet einzahlt. In dem Fall ist die Info nur auf das beschränkt, was man in dieser LN-Wallet hat.
– die meisten Provider geben heute flexible Internetadressen aus, die täglich wechseln und nicht auf den konkreten Ort verweisen, sondern auf den Sitz des providers. Meiner geht etwa immer nach München, obwohl ich ganz wo anders (in Bayern) wohne.
es ist also nur unter bestimmten Umständen dramatisch. Wenn man das weiß, kann man es relativ leicht vermeiden. Aber man sollte es halt wissen.
Sicherheit und Privatsphäre sind halt nicht binär. Man kann versuchen, sie jeweils zu verbessern, aber 100% wird man nie erreichen, es wird immer Edge-Cases geben und sei es die Hardware, die unter bestimmten Umständen irgendwelche Schlüssel leakt.
– Jemand, der es auf Privatsphäre anlegt, sollte vielleicht schon einen (pruned) Node auf dem Handy nutzen oder sich zumindest per Tor mit einem Remote Node verbinden.
– Das mit der jungfräulichen Wallet würde ich nicht erwarten, es gibt ja Wallets, die beides integriert haben wie z.B. die von XXX erwähnte Zeus Wallet, die auch Tor integriert hat. Bei Zap sehe ich Tor “coming soon”.
– Wechselnde IPs schön und gut, aber Du teilst diese ja immer aktuell mit allen Social Networks und sonstigen Services, die im Hintergrund laufen.
Fazit: Ich würde wohl auf Zeus setzen, danke für den Tipp, XXX! 😉
Kann zwar auch nicht die Channel Balance Attacken abwehren, aber immerhin einen großen Teil des im Paper behandelten Trackings deutlich erschweren.
Dankeschön für den sehr ausführlichen Artikel. Ein sehr spannendes Thema, dieses Lightning Netzwerk. Eine Wallet habe ich schon mal zu ausprobieren auf mein Smartphone gelegt und bestückt… Bin gespannt wann wir damit einkaufen können (-;
@Paul Janowitz
“Ich kenne jetzt kein Android Lightning Wallet, welches Orbot unterstützt…”
In Zap-Wallet oder Zeus-Wallet läuft alles integriert über Tor auch ohne Orbot. Das Ganze mit nen Raspiblitz-Node verbunden und schon läuft der Hase durch Rabbit Hole!
@Christoph Bergmann
wie wäre es mal mit nen Beitrag “wie benutze Lightning richtig” oder so ähnlich!
Ansonsten wie immer ein toller Beitrag…
Du hast den Beitrag jetzt dreimal gepostet, habe ihn nun freigegeben.
“Wie benutze ich Lightning” wäre ein interessantes Thema. Allerdings rätsle ich darüber auch schon seit Jahren :))
Danke für den Tipp, habe etwas tiefer dazu recherchiert und ein optimales mobiles Setup gefunden:
https://twitter.com/x218935/status/1537532750785298432
Ein Pixel 5 ginge von der Größe sogar noch als Wallet-only Device, dazu reicht eine günstige Prepaid Sim, sogar aus dem EU Ausland, wo Datenpakete über Monate genutzt werden können… Vielleicht probiere ich das mal aus.
@ Christoph
sorry dafür, am besten gleich die Rechtschreibung (fehlende Wörter) mit korrigieren 🙂
Dachte ich muss den post auch noch freigeben, deshalb dann die wegwerfmailadresse.