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.

Diese Aufzeichnungen sind öffentlich und können von jedermann eingesehen werden. Aus diesem Grund können, bei genauer Analyse, die UTXOs (Unspent Transaction Outputs) Muster und Verhaltensweisen aufzeigen, die möglicherweise Rückschlüsse auf die Identität oder zumindest auf die Aktivitäten eines bestimmten Benutzers zulassen. Was genau UTXOs sind, könnt Ihr den verlinkten Artikel nachlesen.

Die Dynamik und Struktur von UTXOs in einer Transaktion können Einblicke in die Bewegung von Geldmitteln im Bitcoin-Netzwerk bieten. Zum Beispiel, wenn in einer einzigen Transaktion mehrere UTXOs gebündelt werden, könnte dies als Anzeichen dafür gewertet werden, dass alle diese UTXOs wahrscheinlich einer einzigen Entität oder Person gehören. Ein weiteres bezeichnendes Merkmal ist die Praxis des "Wechselgelds". Wenn ein Benutzer Bitcoins sendet und nicht den gesamten UTXO-Betrag verwendet, wird der überschüssige Betrag oft als "Wechselgeld" zurück an eine Adresse des Senders geschickt. Dieses Verhalten kann, vor allem wenn es regelmäßig vorkommt, ein weiteres Indiz für die Zuordnung von Transaktionen zu einem bestimmten Benutzer sein.

Im Bitcoin Netzwerk gibt es aber Möglichkeiten wie wir privatsphäre-orieniert Zahlungen versenden können, ohne das eine Blockchain Analyse Aufschluss darüber geben kann, wie wir unsere BTC verwenden. Wie Transaktionen überhaupt funktionieren, könnt Ihr in diesem Artikel nachlesen.

Vorausetzungen um Bitcoin anonym zu versenden

• Die wichtigste Vorausetzung ist der Besitz bzw die Verwaltung einer eigenen Bitcoin Full Node. Nur mit einer eigenen Bitcoin Full Node seid Ihr in der Lage direkt mit dem Netzwerk interagieren zu können, und müsst Euch nicht auf Dritte verlassen, welche Eure Transaktionen ausführen.
  
• Eine Wallet welche eine Verbindung zu einer eigenen Full Node zulässt. Habt Ihr eine Wallet die das nicht kann, verwendet diese Wallet voreingestellte Bitcoin Knotenpunkte oder Nodes, die die Transaktion für Euch ins Netzwerk versenden. Die Betreiber solcher Nodes können alle Transaktionen nachvollziehen und analysieren. Natürlich heisst das jetzt nicht dass alle Nodes Eure Transatkionen überprüfen und analysieren, jedoch bin ich selber immer der Typ der alles selber machen will und arbeite nach dem Prinzip Vertrauen ist gut, Kontrolle ist besser.
• Eine Wallet die Transaktionen so durchführt dass eine Analyse nicht zulässt. Momentan ist bekannteste Beispiel die Sparrow Wallet

Wie Ihr Eure Sparrow Wallet mit Eurer eigenen Full Node verbinden könnt, erfahrt Ihr hier in diesem Beitrag.

Ihr könnt auch Sparrow ohne eigene Full Node verwenden, und einfach den Electrum Server eines guten Kollegen, welcher eine eigene Full Node betreibt, verwenden. Dieser wäre zwar mit genügend technischen Kenntnissen in der Lage Eure Transaktionen zu überprüfen, aber wir nehmen jetzt mal an dass ein guter Freund dies in der Regel nicht tun würde.

Sparrow Wallet Privacy Sendungen erstellen

Die Versendung ist eigentlich ziemlich einfach und geschieht mit einer kleineren eher unauffälligen Option bei den Transaktionseinstellungen.

Im Grunde habt Ihr 2 mögliche Arten die Transaktion zu versenden. Möglichst günstig, oder Privatsphäre-optimiert. Möglichst günstig bedeutet in der Regel, Ihr versendet die UTXOs an ein Gegenüber, dabei sind Zieladresse und Absendeadresse bekannt und es ist möglich wieviel jemand erhalten habt, und dass dabei das Wechselgeld, bzw der Rest des UTXOs an Euch zurück gegangen ist. Die Transaktion ist deshalb auch klein da sie wenige Daten enthält.

Bei der optimierten Variante ist das nicht mehr so einfach, bzw wird quasi verunmöglicht. Es wird ein Coinjoin mit uns selbt erstellt.

Wenn wir Bitcoin ausgeben und nicht möchten, dass andere unsere Transaktion leicht nachverfolgen können, gibt es eben diese Methode namens "Coinjoin". Denkt an einen Topf, in den mehrere Leute Geld einwerfen und dann Geld herausnehmen, ohne dass man genau sagen kann, welches Geld von wem stammt.

Ein „equal output coinjoin“ ist eine spezielle Art von Coinjoin, bei der alle Beträge, die herausgenommen werden, gleich groß sind. Das macht es noch schwieriger zu sagen, welcher Betrag wem gehört.

Wenn wir aber niemanden haben, mit dem wir einen echten Coinjoin durchführen können, können wir durch diese Methode einen „fake coinjoin“ erstellen. Das ist so, als würden wir in den Topf Geld einwerfen und dann selbst wieder Geld herausnehmen, aber es so aussehen lassen, als ob mehrere Leute beteiligt wären. Für jemanden, der zuschaut, sieht es so aus, als ob mehrere Leute Geld getauscht haben, auch wenn wir es nur selbst waren.

So macht Ihr einen Fake Coinjoin

1. Öffnet Eure Bitcoin-Wallet und geht zum "Send"-Bereich.
2. Gebt die Adresse ein, und wie viel Bitcoin Ihr senden möchtet und gebt der Transaktion einen Namen
3. Stellt die Transaktionsgebühren entsprechend ein, achtet darauf dass die Netzwerkgebühren ausreichend hoch sind
4. Wählt ganz unten die Option Privacy aus. Geht mit der Maus über den Info Button, es muss die Info Appears as a 2 Person Coinjoin zu sehen sein
5. Die Wallet wird dann eine spezielle Transaktion erstellen, die wie ein Coinjoin aussieht, aber nur von Euch stammt
6. Führt die Transaktion wie gewohnt aus

Nachdem Ihr Create Transaktion ausgewählt habt, wird die Transaktion ans das Netzwerk weitergeleitet.

Was passiert bei einem Fake Coinjoin überhaupt

Die Wallet macht alles automatisch und nimmt sich UTXOs im möglichst besten Falle um einen optimalen Fake Coinjoin zu erstellen. Wir nehmen das aber etwas genauer unter die Lupe:

Beispiele

Angenommen, wir haben Adresse A mit einem UTXO von 1 BTC und möchten 0,4 BTC an Adresse B senden.

Mit Fake CoinJoin Bitcoin versenden

1. Wir nutzen Adresse A als Input mit ihrem UTXO von 1 BTC.
2. Wir erstellen mehrere Outputs:
   • 0,2 BTC an Adresse B (das ist die gewünschte Empfängeradresse).
   • 0,2 BTC an eine andere Adresse, die wir besitzen (sagen wir Adresse C). Dies könnte als zweite "Zahlung" interpretiert werden, obwohl sie nur zu einer anderen Adresse geht, die wir in unserer Wallet ebenfalls kontrollieren.
   • Die restlichen 0,6 BTC (abzüglich der Transaktionsgebühren) werden als "Wechselgeld" an eine andere Adresse, die wir ebenfalls kontrollieren (sagen wir Adresse D), zurückgeschickt.

Für einen externen Beobachter könnte es so aussehen, als ob zwei Zahlungen von Adresse A getätigt wurden: eine an Adresse B und eine an Adresse C. Es wäre schwierig zu bestimmen, welche Zahlung der Hauptzweck der Transaktion war und welche nur zur Verwirrung diente. Das Wechselgeld geht an Adresse D zurück. Wer was erhalten hat ist also völlig unklar.

Einfache Bitcoin Transaktion ohne Coinjoin versenden

1. Wir nutzen Adresse A als Input, welcher den UTXO von 1 BTC beinhaltet.
2. Wir erstellen die Outputs:
   • 0,4 BTC werden direkt an Adresse B gesendet (dem Empfänger).
   • Die verbleibenden 0,6 BTC (abzüglich der Transaktionsgebühren) werden als "Wechselgeld" an eine neue Adresse, die wir kontrollieren (sagen wir Adresse C), zurückgeschickt.

In diesem einfachen Szenario gibt es keine Tarnung oder Mehrdeutigkeit. Wir haben im wesentlichen Geld von unserer Adresse A an den Empfänger Adresse B gesendet, und das Wechselgeld wurde an unsere Adresse C zurückgeschickt. Jeder, der die Transaktion in der Blockchain analysiert, könnte leicht den Geldfluss und den Zweck der Transaktion erkennen.

Das Konzept hierbei ist, die echte Absicht der Transaktion zu verschleiern, indem man zusätzliche Outputs erstellt und den ursprünglichen Betrag aufteilt. Dies erhöht die Ambiguität und macht es schwieriger für Dritte, zu erkennen, welcher Output die tatsächliche Zahlung ist und welcher lediglich dazu dient, den Betrag zu verwirren.

Die Sparrow Wallet sendet das Wechselgeld ebenfalls unterteilt an mehrere neue Adressen Eurer Wallet zurück und macht das ganze sogar noch komplexer.

Bitcoin Transaktionsgebühren bei Fake Coinjoin

Da mehrere Transaktionen ausgeführt werden, wird diese Transaktion auch gezwungermassen auch grösser, das beudetet sie wird teurer. Wieviel das ist, könnt Ihr hinter den Fees sehen. In meinem Falle kostet eine Privacy Transaktion 2.09USD, ohne Coinjoin wären es ca 1.10USD gewesen. Ob es Euch Wert ist, müsst Ihr natürlich selber entscheiden. Im groben kann man sagen, dass sich die Transaktionsgebühr knapp verdoppelt.

Abschluss

Die Eigenschaft dass Bitcoin Zahlungen nachvollziebar sind, ist entscheidend darüber dem Netzwerk zu vertrauen zu können. Dadurch sichert sich Bitcoin eben genau seine Glaubhaftigkeit, und es ist unmöglich irgendwo Bitcoin aus dem Nichts zu erzeugen. Es gibt zwar Privacy Coins wie Monero, jedoch kann das Netzwerk nicht versprechen, dass nicht irgendwo Moneros aus dem nichts erschaffen werden. Ein Coin Creation Bug würde im Monero Netzwerk garnicht auffallen da niemand nachvollziehen kann, woher die Coins und die Zahlungen kommen. Bei Bitcoin ist das unmöglich.

Mit Tools wie CoinJoin und Fake Transaktionen können wir das Netzwerk aber seit längerem wirklich anonym benutzen. Hat Euch der Artikel Bitcoin Privacy optimiert und anonym versenden gefallen? Schreibt es in die Kommentare!

The post Bitcoin Privacy optimiert und anonym versenden appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Mehr Information zu Sparrow findet ihr hier auf der Mainpage und den Download findet ihr hier.

Wie Ihr die Bitbox App mit Eurer Fullnode verbindet habt Ihr ja bereits in diesem Artikel erfahren. Nun geht es eben um die besagte Sparrow Wallet.

Voraussetzungen um eure Sparrow Wallet mit einer Bitcoin Umbrel Fullnode zu verbinden

Sind im Prinzip die selben, wie im Umbrel Bitbox Tutorial, nur braucht ihr für die Sparrow Wallet nicht den Torbrowser zu öffnen, da Sparrow einen eigenen Tor-Client integriert hat. Das funktioniert also auch ohne öffnen des Browsers.

Ausserdem muss eine Wallet bereits erstellt sein. Demnächst gibt es noch ein Tutorial wie das genau funktioniert.

Anleitung

Hollt euch wie im anderen Artikel erklärt, zuerst mal die Adresse eures Elektrum Servers, wie auch zuvor gilt hier: die Bitcoin Node muss synchronisert sein, und Elektrum muss fertig indexiert sein.

Öffnet dann die Sparrow App und begebt euch oben in der Arbeitsleiste auf File, danach auf Preferences und dann klickt ihr auf Server.

Erledigt die Einstellungen wie folgt: Private Electrum Server, URL ist die Adresse von eurem Elektrum Server, der Port ist 50001, der Proxy muss aktiviert sein, Zugang ist localhost auf Port 9050

Danach könnt ihr die Verbindung testen. Hat alles geklappt, bekommt die Meldung dass ihr mit eurem Elektrum Server verbunden seid. Das wars auch schon!

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. eurer Kontostand wird direkt aus der Blockchain geladen und verifziert, das bekommt kein Mensch mit. Habt ihr noch keine eigene Bitcoin Fullnode? Schaut bei uns im Shop vorbei: Deine eigene Bitcoin Fullnode.

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 Sparrow Wallet mit Umbrel Bitcoin Fullnode verbinden appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.