News über Electrum wallet

[Lakai01]

[...]
Was braucht denn mittlerweile ein non-pruned Fullnode an Speicherplatz?

Ende 2025 waren das rund 690 GB, mittlerweile sind wir bei 730 GB lt. Blockchain.com:


Quelle

Mit 1 TB SSD wird das tatsächlich schon recht eng, wobei man natürlich auch sagen muss, dass die Festplattenspeicher mittlerweile nur mehr einen Bruchteil von vor ein paar Jahren kosten.

Interessant ist, dass ein Pruning den Speicherbedarf auf rund 8 GB senkt, das ist schon ordentlich.

[Real-Duke]

Mit 1 TB SSD wird das tatsächlich schon recht eng, wobei man natürlich auch sagen muss, dass die Festplattenspeicher mittlerweile nur mehr einen Bruchteil von vor ein paar Jahren kosten.

Mit einer 1 TB SSD hat man auf Sicht schon nicht mehr lange Freude und jetzt gerade frischen Speicher kaufen, macht auch nicht mehr ganz so viel Spaß wie vor einem halben Jahr

Durch den erhöhten Speicherbedarf für KI Zentren sind die RAM und SSD Preise förmlich explodiert und solche Projekte wie eigener Node verteuern sich schnell um einige 100 Prozent.
Also wenn möglich doch bis zum nächsten Winter warten und auf sinkende Preise hoffen.

[mole0815]

Hiermit hole ich eine wichtige Info von cygan an diese Stelle:

da ich keinen neuen faden eröffnen wollte und dieser 'alte' doch passend für diverse Electrum news ist, hole ich nun diesen aus gegebenen anlass wieder aus der versenkung!
denn es gibt mit der 4.8.3 version ein neues update, welches unbedingt bei allen user vollzogen werden sollte!
diese version behebt ein kritisches sicherheitsproblem. um welches es sich hier konkret handelt wird später heute veröffentlicht.
ein kleiner hinweis noch für alle win-nutzer: es könnte passieren, dass der windows defender eine warnung bezüglich ZXing.dll anzeigt, einfach ignorieren, es handelt sich um einen fehlalarm

den kompletten changelog findet ihr hier: https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES
und zum download gehts hier lang: https://electrum.org/#download

Passenderweise musste ich heute Vormittag Electrum (portable) neu laden und bin daher schon mit der 4.8.3 unterwegs.
Die alte Version konnte ich zum Glück nicht mehr starten und war daher dazu gezwungen.

[Etiquette.exe]

Hiermit hole ich eine wichtige Info von cygan an diese Stelle:

Passenderweise musste ich heute Vormittag Electrum (portable) neu laden und bin daher schon mit der 4.8.3 unterwegs.
Die alte Version konnte ich zum Glück nicht mehr starten und war daher dazu gezwungen.

Schönen frühen Morgen allerseits,

ich stöbere hier häufig quer durch die Themen und dieses ist mir die letzten Tage entgangen, werde mich selbst, sobald ich Zugang habe, um das Update kümmern. Vielen Dank dafür. Falls es jemand weiß, kann eine mögliche bösartige Transaktion auch an einem Passwortschutz vorbei in Auftrag gegeben werden? Wie genau funktioniert das?

Diese ganze Hackerei und OPSEC wird wohl der neue Lebensauftrag für jeden und jede, die mit digitalen Vermögenswerten zu tun hat. Da wird doch der Hund in der Pfanne verrückt...

Erfolgreiches Bergfest wünsche ich,
Chris

[mole0815]

Falls es jemand weiß, kann eine mögliche bösartige Transaktion auch an einem Passwortschutz vorbei in Auftrag gegeben werden? Wie genau funktioniert das?

Du meinst diesen Punkt: https://github.com/spesmilo/electrum/security/advisories/GHSA-6jp4-8v48-cc5v
aus den aktuellen Release-Notes?

https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES

* security fixes and disclosures:
   - (sev-high) Malicious server can replace a just-broadcast tx and try to trick user into RBF-ing it
     - see https://github.com/spesmilo/electrum/security/advisories/GHSA-6jp4-8v48-cc5v

Oder auf welches Thema der neuesten Version zielt deine Frage ab?
Hätte keinen anderen Punkt gefunden der zu deiner Frage passen würde aber vielleicht habe ich ihn auch nur übersehen.

[Cricktor]

Ich denke, er meint das, was du aus den "Release Notes" zitiert hast.

@Etiquette.exe
Ein bösartiger Electrum-Server kann hier nicht von sich aus eine bösartige Transaktion initiieren, so funktioniert der Angriff nicht. Da wird auch kein Passwortschutz der Electrum-Wallet umgangen.

Weil eine Electrum-Wallet dem verbundenen Electrum-Server per Design vertraut, wurde in dem Angriffszenario folgendes ausgenutzt:

• Ein Anwender veröffentlicht mit seiner Electrum-Wallet eine (natürlich signierte) Transaktion Tx₁ und der bösartige Server schluckt die einfach und reicht sie nicht ans Netzwerk weiter.
  
• Dafür aktualisiert der bösartige Server anstelle die Transaktionshistorie der Wallet mit einer widersprechenden (aber ungültigen, weil nicht korrekt signierten) Transaktion Tx₂, in der der Angreifer die Transaktions-Outputs/Ziele auf seine eigenen Adressen manipuliert hat. Der angreifende Server kann die Tx₂ nicht signieren, weil er die privaten Schlüssel der auszugebenden Coins nicht hat, logo.
  
• Tx₂ hat ungültige Signaturen, aber das wird von der Wallet (vor v4.8.3) nicht überprüft, eigentlich normales Design einer leichten SPV-Wallet.
  
• Die Wallet wird die Tx₂ als unbestätigte Transaktion anzeigen -- Tx₁ wird garnicht mehr angezeigt.
  
• Wenn jetzt der User manuell per RBF die Gebühr erhöht, damit es mit der Transaktion vorankommt, signiert die Wallet die Tx₂ mit der aufgestockten Gebühr und bezahlt damit, meist unwissentlich, den Angreifer, wenn die Transaktionsziele nicht sorgfältig kontrolliert wurden oder werden.
  
  Übersetzt und minimal ergänzt aus der Zusammenfassung von https://github.com/spesmilo/electrum/security/advisories/GHSA-6jp4-8v48-cc5v
  
  Details aus den Anmerkungen habe ich nicht übersetzt, sondern nur den wesentlichen Angriffsweg versucht, verständlich rüberzubringen.

[Etiquette.exe]

Guten Morgen,

erstmal vielen Dank euch beiden für die Antworten. Man merkt schon flott, wofür so ein Forum gut sein kann. Dieses konkrete Problem ist mir noch nicht untergekommen, aber wie Cricktor das beschreibt, ich glaube, es hätte mich erwischen können im Zweifelsfall.

Was ich ursprünglich meinte, war, ob eine schädliche Transaktion ohne Aufhebung des Passwortschutzes in Auftrag gegegeben werden könnte. Das hatte mich verwundert. Bei manchen Wallets ist die Aufhebung des Passwortschutzes nur beim Start erforderlich, aber nicht mehr beim Signieren/Senden einer Transaktion. In dem Fall wäre es doch dann ein infiltriertes eigenes System, auf das ein Hacker offenbar Zugriff erlangt hat, während ich bspw. die Wallet grad geöffnet habe.

Was Cricktor nun erklärt hat, war mir neu und ich muss sagen, dass das wirklich von der Gefahr her extrem hohes Potenzial hatte, Leute in die Falle zu locken. Ich habe RBF schon etliche Male genutzt und ganz offen gesagt, ich hatte auch schon einmal komische Reaktionen der Wallet mit denen ich mich nicht auskannte und habe mir nichts bei gedacht. Das war jetzt nicht dieser Exploit, aber einfach eine merkwürdige Fehlermeldung oder Kollision oder bspw. auch CPFP Konstellationen, die ich dann entsprechend aufgelöst habe, aber auch erst nachdem ich mich eingelesen hatte. Da erinnere ich mich noch, als ich das Problem das erste Mal hatte und es nicht direkt zuordnen konnte.

Auch wenn ich etwas anderes meinte, vielen Dank für diese Erklärung, denn das hat mich auf jeden Fall schlauer gemacht. Das meine ich im Ernst, diese RBF Sache hätte mir auf die Füße fallen können, weil ich gern bei Gebühren spare und mich dann doch irgendwann umentscheide. Das ist zwar momentan nicht so drückend, weil die Gebühren sehr erträglich sind, aber schon etliche Male in der Vergangenheit gehabt.

Safety first!
Chris

[Cricktor]

Was ich ursprünglich meinte, war, ob eine schädliche Transaktion ohne Aufhebung des Passwortschutzes in Auftrag gegegeben werden könnte.
...

Dieser Gesprächsfaden dreht sich ja hauptsächlich um Electrum und zum Signieren einer Transaktion wird ein gesetztes Wallet-Passwort erneut angefordert. Das kann ein böswilliger Electrum-Server nicht ohne den User auslösen.

Für mich war neu, daß falsche Signaturen von der Wallet vor dem Fix nicht überprüft wurden, insbesondere wenn ein böswilliger Electrum-Server im Grunde genommen eine abweichende Adresshistorie bzw. letzte noch unbestätigte Transaktion zurückliefert, wo sich die zurückgelieferte Transaktion von der gesendeten Transaktion unterscheidet, die die Wallet erstellt hat. Auch daß hier die zurückgelieferte Antwort des böswilligen Electrum-Servers die eigene (gesendete) und meist dann noch unbestätigte Transaktion quasi überschreibt, fühlt sich doch ziemlich unerwartet an.

Ich denke mal, daß aus Effiziensgründen für so etwas schlicht nicht mehrere Electrum-Server "befragt" werden, weil das eigentlich nicht nötig sein sollte. In der Standardeinstellung verbindet sich Electrum ja mit mehreren Servern, benutzt aber nur einen für die Adresshistorie, die restlichen nur zur Blockchain-Fork-Erkennung. Das liegt aber daran, daß eine Electrum-Wallet dem verbundenen Electrum-Server per Design vertraut. Tja, eigentlich muss sich der Electrum-Server dieses Vertrauen erst verdienen, was nicht so einfach zu realisieren ist.

Ich persönlich habe aber ein anderes Vertrauensverhältnis zum Electrum-Server, den meine Wallet verwendet, da ich einen eigenen Electrum-Server ganz bewusst betreibe und ausschließlich verwende. Ich kann mir den Luxus erlauben, recht sicher zu sein, daß mein Electrum-Server mich nicht über den Tisch ziehen wird.

Ich kontrolliere auch recht gewissenhaft verwendete Adressen in einer Transaktion und habe es mir zur Angewohnheit gemacht, Adressen stets an mehreren Stellen zu prüfen ('ne handvoll Zeichen am Anfang, einige irgendwo in der Mitte, mind. 6-7 am Ende, um auf jeden Fall die vollständige Prüfsumme mitzunehmen). Einige identische Zeichen am Anfang und auch die komplette Prüfsumme kann ein Angreifer ja noch in relativ kurzer Zeit hingeschummelt bekommen, aber definitiv nicht auch eine handvoll Zeichen um die Mitte herum.

Electrum markiert eigene Empfangsadressen grün, eigene Wechselgeldadressen gelb hinterlegt. Das ist auch ganz nützlich.

[cygan]

es gibt wieder ein neues sicherheits update von Electrum!
die neue 4.8.4 version behebt bei den lightning-sitzungen den absturz einer verbindung zu einem kanalpartner aufgrund einer fehlerhaften eingehenden onion nachricht
auch einige bugfixes wurden mit diesem release behoben
zu dem wurde Electrum nun schon 15 jahre alt... hätte ich jetzt nicht so auf dem schirm

https://electrum.org/#download
https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES

[Etiquette.exe]

Was ich ursprünglich meinte, war, ob eine schädliche Transaktion ohne Aufhebung des Passwortschutzes in Auftrag gegegeben werden könnte.
...

...

Ich kontrolliere auch recht gewissenhaft verwendete Adressen in einer Transaktion und habe es mir zur Angewohnheit gemacht, Adressen stets an mehreren Stellen zu prüfen ('ne handvoll Zeichen am Anfang, einige irgendwo in der Mitte, mind. 6-7 am Ende, um auf jeden Fall die vollständige Prüfsumme mitzunehmen). Einige identische Zeichen am Anfang und auch die komplette Prüfsumme kann ein Angreifer ja noch in relativ kurzer Zeit hingeschummelt bekommen, aber definitiv nicht auch eine handvoll Zeichen um die Mitte herum.

Electrum markiert eigene Empfangsadressen grün, eigene Wechselgeldadressen gelb hinterlegt. Das ist auch ganz nützlich.

Das Problem mit den identischen Zeichen am Ende der Adresse wurde auch auf Github genannt.

both reported the attacker's output address in tx2 was grinded to match the last four chars of the legit address from tx1

Dieses Problem gibt es auch bei Trustwallet, dort bekomme ich manchmal irgendwelche Test Transaktionen, bei denen dann der Betrag identisch ist mit einem Betrag den ich versendet habe, aber von einem malicious Contract, und die anfänglichen Zeichen und die am Ende sind identisch mit einer von mir verwendeten Outputadresse. Hoffen die Angreifer dann, dass man vielleicht irgendwann mal copy paste macht an falscher Stelle und dann hat man den Salat?

In jedem Fall hat mir dieses komische Phänomen gelehrt, dass man die Adressen überprüfen muss. Aber wie ich schon sagte, ich glaube, bei Electrum wäre ich ins offene Messer gelaufen, weil ich es schon sehr lang nutze und eben noch nie einen Schaden erleiden musste.

Wenn man jetzt aber dieses Problem von Anfang bis Ende durchgeht, dann klingt das nach einem sehr plausiblen Fehler insgesamt und wäre es nicht fast verwunderlich, wenn andere Wallet Software davon nicht auch betroffen wäre?

[5tift]

Vielen Dank cygan für die Information zum neuen Release, da geht es ja ab in letzter Zeit.
Dann weiß ich was das Wochenende ansteht und im Nachhinein gleich meine jährliche Sicherung aller Maschinen auf´s NAS.