Update: aktuell scheinen auch angebliche Mails von Trezor und Cointracking zu kommen.

Das Wichtigste in Kürze

• Betreff der Mail: Critical Security Alert: Microcontroller Entropy Vulnerability, angeblicher Absender BitBox, Antwortadresse no-reply@shiftcrypto.ch.
• Behauptet wird ein Werksdefekt im Mikrocontroller, der den Hardware-Zufallsgenerator deterministisch mache. Ein Link führt auf ein angebliches entropy check tool im Browser.
• Der Inhalt hält technisch nicht stand. Das Ziel ist erkennbar, die Wiederherstellungswörter abzugreifen.
• Der Header dagegen ist sauber signiert und DMARC-konform. Es handelt sich nicht um eine einfache Absenderfälschung.
• Wenn ihr eine solche Mail erhaltet: nicht klicken, nichts eingeben, Mail aufbewahren und melden.

Was in der Mail steht

Die Nachricht ist sauber gestaltet und im Layout einer offiziellen Sicherheitsmitteilung gehalten. Das Engineering-Team habe eine kritische Schwachstelle auf Hardware-Ebene entdeckt, heisst es darin. Betroffen seien Geräte mit den Firmware-Versionen 9.21.0, 9.20.1, 9.19.0, 9.18.2 und 9.17.0. Der Fehler stamme vom Hersteller des Mikrocontrollers und liege nicht in der Firmware. Als Folgen werden genannt: zu wenig Zufall bei der Erzeugung der Wiederherstellungswörter, Angreifbarkeit per Brute Force und deterministische Hardware-Ausgaben bei bestimmten Produktionschargen.

Darunter steht ein Link mit der Aufschrift Launch the entropy check tool, ergänzt um den Hinweis, bei blockierten Links die Browser-Ansicht zu nutzen. Genau das ist der Angriff. Ein solches Werkzeug prüft nichts, es sammelt ein.

Warum der Inhalt technisch nicht aufgeht

Erstens hängt der Seed einer BitBox02 nicht an einem einzelnen Zufallsgenerator. Nach dem Bedrohungsmodell von BitBox kombiniert die Firmware die Zufälligkeit des Mikrocontrollers und des Secure Chips mit einer im Werk erzeugten Zufallskomponente, mit Zufälligkeit vom angeschlossenen Computer und mit dem Geräte-Passwort. Ein defekter Hardware-Zufallsgenerator allein ergibt daraus keinen erratbaren Seed. Das ist bewusst so gebaut, weil sich Zufälligkeit von aussen nie vollständig überprüfen lässt.

Zweitens stimmen die Versionsnummern nicht. Die genannten Versionen sind längst überholt, aktuell ist die 9.26er-Reihe. Der Bootloader-Fix kam mit dem Oeschinen-Release in Firmware 9.26.3. Wer eine echte Advisory schreibt, nennt aktuelle Versionen.

Drittens passt das Timing zu gut. Nach der RNG-Schwachstelle bei Coldcard und dem Dixence-Update ist das Thema Entropie in aller Munde. Decrypt berichtete Ende August über die von BitBox selbst offengelegten Firmware-Fehler. In der Stellungnahme zur Coldcard-Lücke warnt BitBox ausdrücklich davor, dass Angreifer solche Sicherheitsmeldungen aufgreifen, um Dringlichkeit zu erzeugen. Genau das passiert hier.

Viertens, und das macht alles Weitere überflüssig: BitBox fragt niemals nach den Wiederherstellungswörtern. Diese gehören nie in einen Computer, ein Smartphone, eine Webseite, eine Browser-Erweiterung, einen Passwortmanager, einen Cloud-Dienst oder einen KI-Chatbot, sondern ausschliesslich direkt auf das Gerät.

Der brisante Teil: der Mail-Header

Frühere Wellen liessen sich leicht entlarven. Bei der Phishing-Welle von 2024 reichte ein Blick auf die Absenderadresse, und BitBox konnte damals festhalten, dass die Mail nicht von einer BitBox-Adresse stammte. Diese Mail ist anders. Die Prüfung durch unseren eigenen Mailserver ergibt folgendes Bild:

Die Mail wurde also mit einem gültigen DKIM-Schlüssel für bitbox.swiss signiert und ist DMARC-konform ausgerichtet. Eine reine Absenderfälschung sieht anders aus, die scheitert genau an dieser Stelle. Auch eine Tippfehler-Domain scheidet aus, die Signaturdomain lautet exakt bitbox.swiss.

Zwei mögliche Erklärungen

Von aussen lässt sich nicht abschliessend beurteilen, was dahintersteckt. Nach unserem Kenntnisstand bleiben im Wesentlichen zwei Möglichkeiten:

1. Ein Konto beim Versanddienstleister Brevo, in dem bitbox.swiss als authentifizierte Absenderdomain hinterlegt ist, wurde übernommen und für den Versand missbraucht.
2. Der DKIM-Selector mail bei bitbox.swiss gehört zu einem Dienst, der kompromittiert, veraltet oder falsch konfiguriert ist.

Beides wäre ein Vorfall auf Infrastrukturebene und hätte nichts mit den Geräten selbst zu tun. Die Schlüssel bleiben auf der Hardware-Wallet, eine missbrauchte Mailingliste erreicht sie nicht. Einen vergleichbaren Fall gab es 2022 mit dem Datenleck bei ActiveCampaign, damals ging es allerdings um abgeflossene Adressen und nicht um authentifizierten Versand.

Wir haben BitBox über den Befund informiert und den vollständigen Quelltext angeboten. Sobald eine Rückmeldung vorliegt, aktualisieren wir diesen Artikel.

Die Mail ist zu 100% Betrug

Klickt man auf den Link (was man auf keinen Fall ohne VPN tun sollte) landet man natürlich auf einer Webseite die nach der Wörtern und der Passphrase fragt:

Nochmals, gebt auf keinen Fall Eure Recovery Phrase ein, dass wird dazu führen dass ihr all Eure Sats verliert!

Was ihr jetzt tun solltet

• Nicht klicken. Weder den Link noch die Browser-Ansicht. Externe Inhalte blockiert lassen.
• Nichts eingeben. Kein Wallet-Backup, keine 24 Wörter, keine abgetippte Kopie, kein Foto davon. Wer danach fragt, ist ein Angreifer.
• Firmware regulär aktualisieren, aber ausschliesslich über die BitBoxApp oder über bitbox.swiss, die Adresse von Hand eingetippt.
• Falls ihr Wörter eingegeben habt: sofort eine neue Wallet auf einem sauberen Gerät erstellen und das Guthaben dorthin transferieren. Der alte Seed ist verbrannt. Der Phishing-Leitfaden von BitBox beschreibt das Vorgehen im Detail.

Einordnung

Die übliche Empfehlung, den Absender zu prüfen, greift bei dieser Mail zu kurz. Wenn SPF, DKIM und DMARC alle bestehen, hilft der Blick auf die Absenderzeile nicht mehr weiter. Dann bleibt nur der Inhalt selbst als Prüfstein, und der ist zuverlässig: Eine Aufforderung, Wiederherstellungswörter irgendwo einzugeben oder prüfen zu lassen, ist immer ein Angriff. Ohne Ausnahme, ohne Ansehen des Absenders, unabhängig davon, wie gut die Mail signiert ist.

Das ist der eigentliche Grund, warum eine Hardware-Wallet funktioniert. Sie verlagert das Vertrauen weg von E-Mails, Webseiten und Support-Kanälen hin zu einem Gerät in eurer Hand. Diese Eigenschaft ist genau so viel wert, wie ihr sie verteidigt.

The post BitBox-Phishing-Mail besteht die DKIM-Prüfung: Warnung vor dem angeblichen Entropie-Bug appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

An diesem Thema hat sich in den vergangenen zwei Jahren mehr geändert, als die meisten Anleitungen im Netz wiedergeben. Die Regel, dass eine Transaktion beim Senden ausdrücklich als ersetzbar markiert sein muss, gilt seit Bitcoin Core 28.0 nicht mehr. Und Core 31.0 hat im April 2026 an der Mechanik hinter CPFP geschraubt. Beides räumen wir hier mit ein.

Warum eine Transaktion überhaupt liegen bleibt

Miner suchen sich aus dem Mempool die Transaktionen mit der höchsten Gebühr je Byte heraus, nicht die mit der höchsten Gesamtgebühr. Massgeblich ist also der Satz in sat/vByte. Eine grosse Transaktion mit hoher Gesamtgebühr kann hinter einer kleinen mit niedriger Gesamtgebühr zurückstehen, wenn deren Satz besser ist. Wie sich Grösse und Satz berechnen, haben wir in Bitcoin Onchain Gebühren einfach berechnen ausführlich vorgerechnet; das wiederholen wir hier nicht.

Bleibt eine Transaktion unter dem Satz, den die Miner gerade bedienen, wartet sie. Und sie wartet nicht ewig: Bitcoin Core wirft unbestätigte Transaktionen nach einer eingestellten Frist wieder aus dem Mempool. Die Vorgabe steht im Quelltext bei DEFAULT_MEMPOOL_EXPIRY_HOURS{336}, also bei 336 Stunden oder rund zwei Wochen. Danach ist die Transaktion weg, als hätte es sie nie gegeben, und ihr könnt die Bitcoin normal wieder ausgeben. Die verbreitete Angabe von drei bis vier Wochen stimmt nicht.

Bitcoin Gebühr nachträglich erhöhen: RBF oder CPFP

Die beiden Verfahren lösen dasselbe Problem auf entgegengesetztem Weg, und die Wahl zwischen ihnen ist meistens keine Geschmacksfrage, sondern hängt davon ab, ob ihr Absender oder Empfänger seid.

Ein Punkt aus der Grafik verdient es, ausgesprochen zu werden, weil er in vielen Anleitungen untergeht: RBF ist der günstigere Weg. Bei der Ersetzung zahlt ihr am Ende nur die Gebühr der neuen Transaktion, die alte wird nie bestätigt und kostet deshalb auch nichts. Bei CPFP zahlt ihr beide Gebühren, und ihr belegt zusätzlich Platz in einem Block, den ihr sonst nicht gebraucht hättet. Wenn ihr die Wahl habt, nehmt RBF.

Damit ist auch eine falsche Vorstellung erledigt, die sich hartnäckig hält: Ihr bekommt die Gebühr der ersetzten Transaktion nicht „zurück". Es gibt nichts zurückzuerstatten, weil sie nie abgebucht wurde. Eine Bitcoin-Gebühr entsteht erst in dem Moment, in dem ein Miner die Transaktion in einen Block aufnimmt.

RBF: Was 2024 und 2025 gekippt ist

Replace by Fee heisst: Ihr gebt eine zweite Transaktion heraus, die dieselben Eingänge ausgibt wie die erste, aber eine höhere Gebühr trägt. Die Nodes werfen die alte aus dem Mempool und behalten die neue. Weil beide dieselben Eingänge verbrauchen, kann am Ende nur eine von beiden in einen Block. Doppelt ausgeben lässt sich damit also nichts.

Jahrelang galt dafür eine Bedingung, die den ganzen Mechanismus zur Glückssache machte: Die ursprüngliche Transaktion musste sich beim Senden als ersetzbar zu erkennen geben, über einen Wert im sequence-Feld unterhalb von 0xfffffffe. Wer das versäumt hatte, kam an RBF nicht heran.

Diese Bedingung ist gefallen. Bitcoin Core 28.0 hat am 02.10.2024 die Vorgabe für -mempoolfullrbf von 0 auf 1 gestellt. Ein halbes Jahr später, mit Core 29.0 vom 14.04.2025, ist der Schalter ganz verschwunden — die Release Notes schreiben dazu: „With widespread adoption of this policy, users no longer benefit from disabling it, so the option has been removed, making full replace-by-fee the standard behavior." In der Policy-Dokumentation stehen die früheren Regeln 1 und 2 folgerichtig als „(Removed)".

Für euch heisst das zweierlei. Als Absender könnt ihr praktisch jede unbestätigte Transaktion nachbessern, unabhängig davon, wie sie herausgegangen ist. Als Empfänger solltet ihr eine unbestätigte Zahlung grundsätzlich als noch nicht endgültig behandeln — auch eine, die formal nicht als ersetzbar markiert ist. Wer Waren gegen null Bestätigungen herausgibt, geht heute ein grösseres Risiko ein als 2023.

Die Regeln, die eine Ersetzung erfüllen muss

Übrig geblieben sind vier Bedingungen, und sie stehen so in der Policy-Dokumentation von Bitcoin Core:

1. Die Ersatztransaktion zahlt eine absolute Gebühr, die mindestens so hoch ist wie die Summe der Gebühren aller Transaktionen, die sie verdrängt.
2. Die zusätzliche Gebühr deckt darüber hinaus die eigene Bandbreite zum Incremental Relay Feerate der Node ab. Die Dokumentation rechnet es vor: für 500 vByte bei 0,1 sat/vByte sind das mindestens 50 Satoshi obendrauf.
3. Die verdrängten Transaktionen verteilen sich auf höchstens 100 Cluster.
4. Das Feerate-Diagramm des Mempools muss sich durch die Ersetzung strikt verbessern. Diese Regel kam mit dem Cluster-Mempool in Core 31.0 dazu und ersetzt die frühere reine Gebührenprüfung. Für gewöhnliche Zahlungen ist sie unauffällig: Laut Release Notes reicht es, dass die neue Transaktion eine höhere Gebühr und eine höhere Gebührenrate hat als die alte.

Drei Behauptungen, die ihr getrost vergessen könnt

Rund um RBF kursieren Regeln, die es nie gab. Weil sie in älteren Anleitungen stehen — auch in der ersten Fassung dieses Artikels —, hier die Richtigstellung.

• „Die Empfänger und Beträge müssen gleich bleiben." Falsch. Die Ausgänge dürfen frei geändert werden, auch die Empfängeradresse. Genau das ist der Grund, warum Wallets eine Funktion zum Stornieren einer unbestätigten Zahlung anbieten können: Sie ersetzen die Transaktion durch eine, die alles an euch selbst zurückschickt.
• „Ihr müsst die Gebühr verdreifachen, um sie zu verdoppeln." Falsch, und es vermengt absoluten Betrag und Rate. Es gilt Regel 1 plus Regel 2: mindestens die alte absolute Gebühr, plus ein kleiner Aufschlag für die Bandbreite.
• „Nicht alle Miner unterstützen RBF." Überholt. Ersetzungen werden von den Nodes im Netz weitergereicht; ein Miner sieht schlicht die teurere Variante und nimmt sie, weil sie mehr einbringt. Seit dem Wegfall des Schalters in Core 29.0 gibt es dazu auch keine sinnvolle Gegenkonfiguration mehr.

CPFP: Anhängen statt ersetzen

Child Pays for Parent braucht keine Erlaubnis vom Absender, denn es rührt die festhängende Transaktion gar nicht an. Ihr gebt stattdessen einen ihrer Ausgänge weiter aus — an euch selbst genügt — und stattet diese neue Transaktion mit einer hohen Gebühr aus. Weil das Kind nur bestätigt werden kann, wenn die Eltern mit im Block sind, bewerten Miner beide zusammen als Paket.

Deshalb funktioniert CPFP auch dann, wenn euch jemand anderes eine zu billige Zahlung geschickt hat. Ihr müsst nur über einen Ausgang verfügen können. Umgekehrt ist CPFP auch der Ausweg für Absender ohne Wechselgeld: Wer den gesamten Betrag verschickt hat, hat keinen eigenen Ausgang, an dem sich für eine Ersetzung drehen liesse.

Die Paketgebühr rechnen

Der Fehler, den hier fast alle machen: Sie setzen für das Kind den Zielsatz ein. Das reicht nicht. Der Zielsatz muss für das Paket herauskommen, und die zu billigen Eltern ziehen den Schnitt nach unten. Die Rechnung geht so:

Zielgebuehr Paket = (Groesse Eltern + Groesse Kind) * Zielsatz
Gebuehr Kind      = Zielgebuehr Paket - bereits gezahlte Gebuehr Eltern
Satz Kind         = Gebuehr Kind / Groesse Kind

Beispiel aus der Grafik:
  Eltern  140 vB, 6 sat/vB   ->   840 sat bereits gezahlt
  Kind    110 vB
  Ziel    25 sat/vB

  (140 + 110) * 25 = 6250 sat fuer das Paket
  6250 - 840       = 5410 sat muss das Kind tragen
  5410 / 110       = 49,2 sat/vB  ->  aufgerundet 50 sat/vB

Merkt euch die Faustregel dahinter: Je kleiner das Kind im Verhältnis zu den Eltern, desto brutaler muss sein Satz ausfallen. Ein 110-vByte-Kind, das 140 vByte Eltern mitschleppt, braucht den doppelten Zielsatz. Wallets mit CPFP-Funktion rechnen das selbst; wer von Hand baut, sollte grosszügig aufrunden.

Was Core 31.0 an CPFP geändert hat

Für gewöhnliche Zahlungen ändert sich nichts. Wer eine Lightning-Node betreibt, sollte den Punkt trotzdem kennen. Es gab in Bitcoin Core eine Sonderregel namens CPFP Carve-out, die einer einzelnen Transaktion erlaubte, die Paketgrenzen leicht zu überschreiten, sofern sie nur einen unbestätigten Vorgänger hatte. Sie war für Verträge zwischen zwei Parteien gedacht — also genau für Lightning-Kanäle — damit beide Seiten eine Gebühr nachschieben können, ohne dass eine die andere blockiert.

Diese Sonderregel ist mit Core 31.0 entfallen. Die Release Notes halten fest, dass Anwendungsfälle mit ähnlichem Bedarf „employ TRUC transactions and sibling eviction instead going forward". TRUC steht für Topologically Restricted Until Confirmation und ist in BIP 431 beschrieben, der weiterhin den Status Draft trägt. Praktisch betrifft das die Lightning-Implementierung, nicht euch als Nutzer — aber es ist ein guter Grund, die Node-Software aktuell zu halten, statt sie drei Versionen zurückhängen zu lassen.

Welche Wallet kann was

Die Verfahren nützen euch nur, wenn eure Wallet sie anbietet. Von Hand eine Ersatztransaktion zu bauen ist möglich, aber nichts, was wir jemandem empfehlen, der nicht ohnehin weiss, wie es geht. Die folgende Übersicht stützt sich auf die Dokumentation der Projekte selbst, Stand 23.08.2026.

Sparrow, auch mit einer BitBox02

Die Sparrow-Dokumentation nennt beide Wege. Für RBF muss die Transaktion unbestätigt sein und ausschliesslich eigene Eingänge verwenden; ersetzbar sendet Sparrow ohnehin von Haus aus. Unbestätigte Transaktionen bekommen im Reiter Transactions ein Symbol, und über den Rechtsklick führt Increase Fee zurück in den Sende-Dialog mit angepasster Gebühr. CPFP beschreibt die FAQ als das Ausgeben der Ausgänge zu einem höheren Satz.

Interessant ist das für alle mit einer BitBox02, denn die BitBoxApp selbst hat dafür keine Oberfläche. Der Hersteller sagt das offen und beschreibt in einer eigenen Anleitung den Umweg: „it doesn't have an RBF interface, it enables RBF for all transactions by default, giving you the option to use it with advanced software like Sparrow Wallet." Ihr verbindet die BitBox02 also mit Sparrow, wählt dort Increase Fee (RBF), schiebt den Regler hoch, bestätigt auf dem Gerät und sendet. Wie die Verbindung zu einer eigenen Node aussieht, steht in Sparrow Wallet mit Umbrel Bitcoin Fullnode verbinden und in Bitbox02 mit Raspiblitz Bitcoin Fullnode verbinden.

Bitcoin Core auf der Kommandozeile

Wer eine eigene Full Node betreibt, hat den direktesten Weg. Der RPC bumpfee nimmt die Transaktions-ID und baut die Ersetzung selbst:

# Gebuehr automatisch neu schaetzen lassen
bitcoin-cli bumpfee <txid>

# Oder den Satz selbst vorgeben, hier 25 sat/vByte
bitcoin-cli -named bumpfee txid=<txid> options='{"fee_rate": 25}'

Die Dokumentation beschreibt, wie Core die Mehrgebühr aufbringt: „The command will pay the additional fee by reducing change outputs or adding inputs when necessary. It may add a new change output if one does not already exist." Alle Eingänge der alten Transaktion wandern in die neue. Zwei Grenzen solltet ihr kennen: Der Befehl scheitert, wenn Wallet oder Mempool bereits eine Transaktion enthalten, die einen Ausgang der alten ausgibt — dann habt ihr faktisch schon ein CPFP gebaut. Und der angegebene Satz muss mindestens 1 sat/vByte über dem alten liegen.

Lightning-Node über Ride the Lightning

Hängt eine Kanaleröffnung fest, wird es unangenehm, weil der Kanal bis zur Bestätigung nicht nutzbar ist. RTL reicht dafür den BumpFee-Aufruf von LND durch, und der entscheidet selbst, welches Verfahren passt. Die LND-Dokumentation formuliert es so: „Depending on whether the outpoint has been registered in the sweeper (an existing input, e.g., an anchor output) or not (a new input, e.g., an unconfirmed wallet utxo), this will either be an RBF or CPFP attempt." Ihr müsst euch also nicht entscheiden, sondern nur einen Zielsatz angeben.

Der dritte Weg: Beschleuniger

Bleibt der Fall, in dem weder RBF noch CPFP geht: Ihr seid nicht der Absender und habt auch keinen Ausgang, über den ihr verfügen könnt. Dann bleibt ein Mining-Pool, der die Transaktion aus Kulanz in seinen nächsten Block nimmt. ViaBTC betreibt so einen Dienst weiterhin und nennt in seinem Hilfeartikel die Bedingungen: „ViaBTC supports 20 FREE acceleration chances per hour", dazu höchstens 0,5 KB Transaktionsgrösse und ein Mindestsatz. Wie das abläuft, steht in Bitcoin Transaktionen mit ViaBTC gratis beschleunigen.

Seid euch dabei über die Grenzen im Klaren. Ein Beschleuniger ändert nichts an der Transaktion und nichts an ihrer Gebühr — er bittet einen einzelnen Pool um Vorzugsbehandlung. Findet dieser Pool in absehbarer Zeit keinen Block, passiert nichts. Es ist die schwächste der drei Optionen und die einzige, bei der ihr auf das Wohlwollen eines Dritten angewiesen seid.

Was ihr tun könnt

• Erst nachsehen, dann handeln. Sucht die Transaktions-ID in einem Mempool-Explorer und vergleicht euren Satz mit dem, was gerade in die Blöcke geht. Liegt ihr knapp darunter, lohnt oft schon das Abwarten der nächsten ruhigen Stunde.
• Seid ihr der Absender, nehmt RBF. Es ist günstiger als CPFP und braucht seit Core 28.0 keine Vorbereitung mehr an der ursprünglichen Transaktion.
• Seid ihr der Empfänger, nehmt CPFP — und rechnet den Satz für das Paket, nicht für das Kind allein. Sonst zahlt ihr mehr und hängt trotzdem fest.
• Setzt einmalig den richtigen Satz, statt zweimal zu bieten. Jede Nachbesserung kostet erneut die volle Gebühr. Ein zu vorsichtiger Bump, der wieder nicht reicht, ist der teuerste Fehler in diesem Vorgang.
• Behandelt eingehende Zahlungen mit null Bestätigungen als offen. Seit Full-RBF Standard ist, lässt sich jede unbestätigte Transaktion ersetzen, auch eine ohne Markierung.
• Beugt vor mit UTXO-Management. Wer wenige, saubere UTXO hält, baut kleinere Transaktionen — und kleinere Transaktionen sind bei gleichem Satz schlicht billiger, auch beim Nachbessern.
• Prüft vor dem Wallet-Wechsel, ob sie es kann. Die Tabelle oben ist ein Anfang; Welche Bitcoin Wallets gibt es ordnet die Kandidaten breiter ein.

Fazit: Eine festhängende Transaktion ist ein Ärgernis, kein Verlust

Der schlimmste Fall ist, dass ihr zwei Wochen wartet und die Bitcoin danach wieder in eurer Wallet liegen. Alles darunter lässt sich mit einem der beiden Verfahren beheben, und in den meisten Wallets sind es zwei Klicks.

Bemerkenswert ist, wie deutlich sich die Lage seit 2023 gebessert hat. Damals war RBF eine Funktion, an die ihr im Nachhinein nur herankamt, wenn ihr vorher daran gedacht hattet — und dieses Vorher-Daran-Denken übernahmen längst nicht alle Wallets. Heute ist die Ersetzbarkeit der Normalzustand des Netzes, und die Frage lautet nur noch, ob eure Wallet eine Schaltfläche dafür hat. Dass Bitcoin Core dafür eine jahrelang umstrittene Option kommentarlos gestrichen hat, statt sie zur Wahl zu stellen, war die richtige Entscheidung: Eine Regel, die sich mit ein paar Zeilen Konfiguration umgehen liess, hat nie Sicherheit gestiftet, sondern nur den Anschein davon.

Wer daraus etwas mitnehmen will, dann dies: Verlasst euch nicht auf null Bestätigungen, weder als Empfänger noch beim Kaffeeholen mit dem Handy. Und wenn ihr sendet, schaut einmal kurz auf den Mempool, bevor ihr auf Senden drückt. Das erspart euch diesen ganzen Artikel.

Quellen und weiterführende Links

• Bitcoin Core: doc/policy/mempool-replacements.md — die geltenden Ersetzungsregeln
• Bitcoin Core 28.0 Release Notes — Vorgabe für -mempoolfullrbf von 0 auf 1
• Bitcoin Core 29.0 Release Notes — Option entfernt, Full-RBF ist Standard
• Bitcoin Core 31.0 Release Notes — Feerate-Diagramm und Wegfall des CPFP Carve-out
• Bitcoin Core: mempool_options.h — DEFAULT_MEMPOOL_EXPIRY_HOURS{336}
• Bitcoin Core RPC-Referenz: bumpfee
• BIP 431: Topology Restrictions for Pinning — TRUC-Transaktionen
• Bitcoin Optech: CPFP carve out
• Sparrow Wallet FAQ — Increase Fee und CPFP
• Electrum FAQ — Increase Fee, Child pays for parent, Cancel
• BitBox Support: RBF mit Sparrow und BitBox02
• LND API: BumpFee
• ViaBTC: BTC Transaction Accelerator

The post Bitcoin Gebühr nachträglich erhöhen mit RBF und CPFP appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorteile die Bitbox02 mit deiner eigenen Umbrel Bitcoin Full zu verbinden

• Privatsphäre: Wenn ihr eure BitBox02 mit einer öffentlichen Node (z.B. der Standard-Einstellung vieler Wallets) verwendet, könnten die Betreiber dieser Node theoretisch sehen, welche Adressen ihr abfragt und daraus Rückschlüsse auf euren Kontostand und eure Transaktionen ziehen. Mit einer eigenen Full Node bleiben diese Informationen privat.
• Sicherheit: Eine eigene Full Node überprüft jede Transaktion und jeden Block gegen die Konsensregeln von Bitcoin. Das bedeutet, ihr müsst euch nicht auf Dritte verlassen, um sicherzustellen, dass eure Transaktionen legitim sind.
• Souveränität: Mit einer eigenen Full Node habt ihr die vollständige Kontrolle über eure Transaktionen. Ihr seid nicht von Drittanbietern abhängig, die den Dienst einschränken, ändern oder beenden könnten.
• Verbesserte Netzwerkgesundheit: Das Betreiben einer eigenen Full Node stärkt das dezentrale Netzwerk von Bitcoin. Je mehr unabhängige Knoten existieren, desto widerstandsfähiger wird das Netzwerk gegenüber Angriffen oder Versuchen der Zensur.
• Geringere Gebühren: Wenn ihr eine Full Node betreibt, könnt ihr besser einschätzen, welche Transaktionsgebühr für eure Transaktion angemessen ist, da Ihr das gesamte Netzwerk überblickt. So könntet Ihr eventuell Gebühren sparen.
• Aktualität: Ihr erhaltet Updates über das Bitcoin-Netzwerk in Echtzeit, ohne euch auf Dritte verlassen zu müssen.
• Unterstützung des Netzwerks: Indem ihr eine eigene Full Node betreibt, tragt Ihr dazu bei, das Bitcoin-Netzwerk sicher und dezentralisiert zu halten.

Wenn ihr euch für den Betrieb einer eigenen Full Node entscheidet, solltet Ihr jedoch auch den zusätzlichen Aufwand und die potenziellen Kosten für Hardware, Strom und Bandbreite berücksichtigen. Es ist auch wichtig sicherzustellen, dass eure Node korrekt konfiguriert ist, um eure Privatsphäre und Sicherheit zu maximieren.

Wir richten den Zugang über das LAN Netzwerk, aber auch über das Tor Netzwerk ein um von einem möglichst hohem Mass an Privatsphäre zu profitieren. Das den LAN Zugang nutzt ihr zuhause, und den Tor Zugang wenn ihr unterwegs seid und euch nicht in eurem LAn befindet, in der die Full Node operiert.

Vorausetzungen um eure Bitbox02 mit einer Raspiblitz Bitcoin Fullnode zu verbinden

Eine voll funktionsfähige und fertig synchronisierte Raspiblitz Bitcoin Full Node. Um die Bitbox App zu verbinden, muss auch auch ElectrumRS installiert sein, und der Electrum Server muss vollständig synchronisiert sein. Nach der Installation von Electrum kann es gut und gerne nochmals einen Tag gehen, bis der Server vollständig synchronisiert, und bereit für Verbindungen ist. Falls Ihr noch keinen Electrum Server auf eurer Fullnode habt, installiert euch Electrum (ElectRS) aus dem App Store.

Wählt im CLI Menu vom Raspiblitz Electrum Rust aus, und klickt anschliessend auf OK:

Die Installation kann einige Minuten dauern. Habt geduld, und wartet, bis ihr wieder auf der Befehlszeile seid. Alternativ kann Electrum Rust auch über das Web-UI installiert werden. Der Aufbau des Indexes kann auf einem Raspberry Pi 4 bis zu 2 Tage dauern, auf einem Raspberry 5 ca. 1 Tag.

Tor Konfiguration

Ihr habt verschiedene Möglichkeiten euch über das Tornetzwerk mit der Bitbox App zu verbinden:

Mit dem Browser als Tor Proxy

Um euch mit dem Tor Netzwerk zu verbinden, müsst ihr Zugang zu Tor haben, das geht am einfachsten mit dem Tor Browser, sobald dieser verbunden ist, habt über den Port 9150 verbindung zum Tor Netzwerk. Startet ihr die Bitbox App, muss der Tor Browser mit dem Internet verbunden sein. Installiert euch also zuerst den Tor Browser hier.

Danach könnt ihr in der Bitboxapp unter Einstellungen --> erweiterte Einstellungen --> Tor Proxy aktivieren die Verbindung zu einem Tor Proxy erlauben:

Gebt hier 127.0.0.1:9150 ein falls ihr den TorBrowser als Proxy verwendet. 127.0.0.1 ist die lokale Adresse des Geräts bzw. bedeutet, dass sich die App mit einem Dienst auf dem selben Gerät verbindet.

Für Linux Desktop User

Wer ein Linux Betriebssystem fährt, kann sich auch den Tor Proxy selber installieren. Dann muss der Browser nicht laufen damit die Verbindung besteht. Installiert Tor mit:

sudo apt install tor

und checkt den Dienst mit

sudo systemctl status tor

Wenn der Dienst auf active steht, könnt ihr eure Bitbox App so konfigurieren, dass es den TorProxy verwendet. Dieser hört auf Port 9050! Also in diesem Fall 127.0.0.1:9050 in der Bitbox App verwenden!

Für das Smartphone

Für Das Smartphone benötigt ihr die App Orbot, die euch den TorProxy zur Verfügung stellt.

Beim Smartphone mit Orbot verwendet ihr 127.0.0.1:9050

Für eine Verbindung über das eigene LAN Netzwerk, muss die Proxy Einstellung der Bitbox App deaktiviert sein!

Anleitung für die Verbindung

Im eigenen Netzwerk zuhause

Ruft ihr den Kontostand zuhause ab, empfiehlt es sich, direkt ohne Umwege über Tor mit der Node zu kommunizieren. Die Bitbox App auf dem Desktop sollte bestmöglichst auf diese weise konfiguriert werden. Die Anfragen für den Kontostand verlassen somit euer Haus nicht.

Tor Proxy Settings in der Bitbox App sind auf aus. Danach wählt ihr eine eigene Node hinzufügen aus. Gebt hier die lokale IP Adresse der Raspiblitz Node ein gefolgt vom Port 50002:

Klickt danach auf Remote-Zertifikate herunterladen, und falls das auftaucht gleich noch auf Überprüfen und wenn die Verbindung erfolgreich war, danach auf Hinzufügen.

Unterwegs für das Smartphone oder den Laptop über Tor

Loggt euch in das Webinterface eurer Raspiblitz Node ein. Geht auf euren Electrum Server. Sollte hier noch nichts angezeigt werde, ist ElectRs noch nicht fertig mit indexieren! Dann heisst es, noch etwas warten!

Startet den Tor Browser und öffnet als nächstes die Bitbox App. Geht unten links auf die Einstellungen und klickt hier auf Tor Proxy aktivieren. Gebt die Adresse 127.0.0.1 ein und den Port 9150. Für das Smartphone und Orbot nehmt ihr den Port 9050!
Bestätigt und verlasst das Fenster. Geht als nächstes auf das Feld Eigene Fullnode verbinden

Fügt nun den Adresse vom Electrum Server hier bei host:port ein. Fügt am Ende den Port 50002 hinzu! Lasst :s am Schluss der Adresse weg!

Klickt danach auf Remote-Zertifikat herunterladen, und danach auf Überprüfen. Habt ihr alles korrekt eingegeben, kommt die Meldung, dass die Verbindung erfolgreich hergestellt worden ist. Falls nicht, stellt sicher dass der Tor Browser wirklich an ist, und mit dem Tor Netzwerk verbunden ist.

Abschluss

Ihr könnt nun die beiden Shiftcrypto Server entfernen. Die benötigen wir nicht mehr. Sollte etwas nicht klappen, können die Standardeinstellungen jederzeit mit der Option In Werkszustand zurücksetzen wieder hergestellt werden.

Fazit

Nun seid ihr vollständig mit eurer eigenen Fullnode verbunden, und keiner, ausser euch, hat die vollständige Kontrolle und Einsicht über eure Transaktionen, Kontostände und etc. Habt ihr noch keine eigene Bitcoin Fullnode oder keine Bitbox02? Schaut bei uns im Shop vorbei:  Bitcoin Fullnodes & Bitbox02

Ich hoffe euch mit dem Tutorial den Umgang mit Bitcoin und und eurer Node etwas erleichtert zu haben. Falls ihr Fragen habt, schreibt sie in die Kommentare!

The post Bitbox02 mit Raspiblitz Bitcoin Fullnode verbinden appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorteile die Bitbox02 mit deiner eigenen Umbrel Bitcoin Full zu verbinden

• Privatsphäre: Wenn ihr eure BitBox02 mit einer öffentlichen Node (z.B. der Standard-Einstellung vieler Wallets) verwendet, könnten die Betreiber dieser Node theoretisch sehen, welche Adressen ihr abfragt und daraus Rückschlüsse auf euren Kontostand und eure Transaktionen ziehen. Mit einer eigenen Full Node bleiben diese Informationen privat.
• Sicherheit: Eine eigene Full Node überprüft jede Transaktion und jeden Block gegen die Konsensregeln von Bitcoin. Das bedeutet, ihr müsst euch nicht auf Dritte verlassen, um sicherzustellen, dass eure Transaktionen legitim sind.
• Souveränität: Mit einer eigenen Full Node habt ihr die vollständige Kontrolle über eure Transaktionen. Ihr seid nicht von Drittanbietern abhängig, die den Dienst einschränken, ändern oder beenden könnten.
• Verbesserte Netzwerkgesundheit: Das Betreiben einer eigenen Full Node stärkt das dezentrale Netzwerk von Bitcoin. Je mehr unabhängige Knoten existieren, desto widerstandsfähiger wird das Netzwerk gegenüber Angriffen oder Versuchen der Zensur.
• Geringere Gebühren: Wenn ihr eine Full Node betreibt, könnt ihr besser einschätzen, welche Transaktionsgebühr für eure Transaktion angemessen ist, da Ihr das gesamte Netzwerk überblickt. So könntet Ihr eventuell Gebühren sparen.
• Aktualität: Ihr erhaltet Updates über das Bitcoin-Netzwerk in Echtzeit, ohne euch auf Dritte verlassen zu müssen.
• Unterstützung des Netzwerks: Indem ihr eine eigene Full Node betreibt, tragt Ihr dazu bei, das Bitcoin-Netzwerk sicher und dezentralisiert zu halten.

Wenn ihr euch für den Betrieb einer eigenen Full Node entscheidet, solltet Ihr jedoch auch den zusätzlichen Aufwand und die potenziellen Kosten für Hardware, Strom und Bandbreite berücksichtigen. Es ist auch wichtig sicherzustellen, dass eure Node korrekt konfiguriert ist, um eure Privatsphäre und Sicherheit zu maximieren.

Wir richten den Zugang über das LAN Netzwerk, aber auch über das Tor Netzwerk ein um von einem möglichst hohem Mass an Privatsphäre zu profitieren. Das den LAN Zugang nutzt ihr zuhause, und den Tor Zugang wenn ihr unterwegs seid und euch nicht in eurem LAn befindet, in der die Full Node operiert.

Vorausetzungen um eure Bitbox02 mit einer Umbrel Bitcoin Fullnode zu verbinden

Eine voll funktionisfähige und fertig synchroniserte Umbrel Bitcoin Full Node. Um die Bitbox App zu verbinden, muss auch die Electrum App installiert sein, und der Electrum Server muss synchronisiert sein. Nach der Installation von Electrum kann es gut und gerne nochmals einen Tag gehen, bis der Server vollständig synchronisert, und bereit für Verbindungen ist. Falls Ihr noch keinen Electrum Server auf rurer Fullnode habt, installiert Euch Electrum (ElectRS) aus dem App Store.

Tor Konfiguration

Um euch mit dem Tor Netzwerk zu verbinden, müsst ihr Zugang zu Tor haben, das geht am einfachsten mit dem Tor Browser, sobald dieser verbunden ist, habt über den Port 9150 verbindung zum Tor Netzwerk. Startet Ihr die Bitbox App, muss der Tor Browser mit dem Internet verbunden sein. Installiert euch also zuerst den Tor Browser hier.

Danach könnt ihr in der Bitboxapp unter Einstellunge --> erweiterte Einstellungen die Verbindung zu einem Torproxy erlauben:

Gebt hier 127.0.0.1:9150 ein falls ihr den TorBrowser als Proxy verwendet.

Für Das Smartphone benötigt ihr die App Orbot, die euch den TorProxy zur Verfügung stellt.

Beim Smartphone mit Orbot verwendet ihr 127.0.0.1:9050

Für eine Verbindung über das eigene LAN Netzwerk, muss die Proxy Einstellung der Bitbox App deaktiviert sein!

Anleitung für die Verbindung

Im eigenen Netzwerk zuhause

Ruft ihr den Kontostand zuhause ab, empfiehlt es sich, direkt ohne Umwege über Tor mit der Node zu kommunizieren. Die Bitbox App auf dem Desktop sollte bestmöglichst so konfiguriert werden. Die Anfragen für den Kontostand verlassen somit euer Haus nicht.

TorProxy Settings in der Bitbox App sind auf aus. Danach wählt ihr eine eigene Node hinzufügen aus. Gebt hier die lokale IP Adresse der Umbrelnode ein gefolgt vom Port 50001:

Klickt danach auf Überprüfen, und wenn die Verbindung erfolgreich war, danach auf Hinzufügen.

Unterwegs für das Smartphone oder den Laptop über Tor

Loggt euch in das Webinterface eurer Umbrel Node ein. Geht auf euren Electrum Server. Klickt auf Tor und haltet euch die Adresse bereit.

Startet den Tor Browser und öffnet als nächstes die Bitbox App. Geht unten links auf die Einstellungen und klickt hier auf Tor Proxy aktivieren. Gebt die Adresse 127.0.0.1 ein und den Port 9150. Für das Smartphone und Orbot nehmt ihr den Port 9050!
Bestätigt und verlasst das Fenster. Geht als nächstes auf das Feld Eigene Fullnode verbinden

Fügt nun den Adresse vom Electrum Server hier bei host:port ein. Fügt am Ende den Port 50001 hinzu!

Klickt danach auf Überprüfen. Habt Ihr alles korrekt eingegeben, kommt die Meldung dass die Verbindung erfolgreich hergestellt worden ist. Falls nicht, stellt sicher dass der Torbrowser wirklich an ist, und mit dem Tor Netzwerk verbunden ist.

Abschluss

Ihr könnt nun die beiden Shiftcrypto Server entfernen. Die benötigen wir nicht mehr. Sollte etwas nicht klappen, können die Standardeinstellungen jederzeit mit der Option In Werkszustand zurücksetzen wieder hergestellt werden.

Fazit

Nun seid Ihr vollständig mit Eurer eigenen Fullnode verbunden, und keiner, ausser Euch, hat die vollständige Kontrolle über Eure Transaktionen, Kontostände und etc. Habt Ihr noch keine eigene Bitcoin Fullnode oder keine Bitbox02? Schaut bei uns im Shop vorbei: Deine eigene Bitcoin Fullnode & Bitbox02

Ich hoffe Euch mit dem Tutorial den Umgang mit Bitcoin und Co etwas erleichtert zu haben. Falls Ihr Fragen habt, schreibt sie in die Kommentare!

The post Bitbox02 mit Umbrel Bitcoin Fullnode verbinden appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.