Fünf Anpassungen der BLAKE2b Difficulty in elf Tagen

Die Betreiber der Informationsseite blake2bminer.com führen jede Anpassung mit Block, Zeitpunkt und Faktor auf. Sie betreiben dafür eine eigene mitvalidierende Node, und sie legen offen, dass ihnen BLAKE2b-Hardware gehört — das ist mehr Transparenz, als die meisten Fachmedien zum selben Thema aufbringen.

Der Wechsel selbst geschah am 30. August um 06:14 UTC bei Block 961.640. Bemerkenswert ist, wie er abgesichert wurde: Die Aktivierung verlangte laut der Statusseite der Kette eine Zeitungsschlagzeile im Coinbase-Eintrag des Blocks, "8-30 NYPost Deride And Conquer". Das ist dieselbe Geste wie im Genesis-Block von 2009 — nur dass sie hier technisch verhindern soll, dass jemand vorzeitig losrechnet.

Warum die erste Anpassung nach unten ging

Die erste Anpassung am 1. September senkte die Schwierigkeit um 41,3 Prozent. Das wirkt widersinnig, weil die Kette zu diesem Zeitpunkt längst wieder im Minutentakt Blöcke ausspuckte. Die Erklärung steckt im Messfenster: Eine Anpassung betrachtet die vergangenen 2.016 Blöcke, und in diesem Fenster lagen die drei Wochen Stillstand vom August, in denen die Abspaltung mit geerbter Difficulty ganze acht Blöcke zustande brachte. Gemessen wurde also überwiegend Stillstand. Wie dieser Mechanismus grundsätzlich arbeitet, steht in unserem Grundlagenbeitrag Was ist die Mining Difficulty.

Ab der zweiten Anpassung kehrte sich das um. Zwischen dem 1. und dem 2. September entstanden 2.016 Blöcke in rund siebzehn Stunden — vorgesehen sind dafür zwei Wochen. Die Difficulty hätte sich etwa verzwanzigfachen müssen. Sie durfte es nicht.

Der Anschlag bei Faktor vier steht seit 2009 im Code

Bitcoin begrenzt jede Anpassung auf den Faktor vier nach oben und ein Viertel nach unten. Die Stelle dazu steht unverändert in src/pow.cpp, unter dem Kommentar "Limit adjustment step":

if (nActualTimespan < params.nPowTargetTimespan/4)
    nActualTimespan = params.nPowTargetTimespan/4;
if (nActualTimespan > params.nPowTargetTimespan*4)
    nActualTimespan = params.nPowTargetTimespan*4;

Diese Bremse ist kein Versehen, sondern Absicht: Sie soll verhindern, dass ein kurzer Ausreisser bei den Zeitstempeln die Kette in eine Richtung katapultiert, aus der sie nicht mehr herauskommt. Die BLAKE2b-Kette hat vorgeführt, was passiert, wenn eine Kette weit unterhalb ihrer tatsächlichen Rechenleistung startet: Sie braucht vier volle Anpassungen, um den Rückstand aufzuholen, und jede davon dauert so lange, wie 2.016 Blöcke eben dauern.

Erst die fünfte Anpassung am 12. September fiel mit dem Faktor 2,99 unter den Anschlag. Das ist die eigentliche Meldung dieser Woche, und sie klingt unspektakulärer als sie ist: Die Difficulty hat die Hashrate eingeholt. Ab jetzt misst die Kette, was tatsächlich an ihr rechnet, statt hinterherzulaufen.

191-mal schwerer, aber nur rund zehnmal mehr Rechenleistung

An dieser Stelle ist eine Unterscheidung wichtig, die in mehreren Berichten untergeht. Die Difficulty ist um das 191-Fache gestiegen, die Rechenleistung nicht. Die Miner-Seite beziffert die Hashrate der Kette kurz nach der Aktivierung auf rund 3 PH/s und Mitte September auf etwa 31 PH/s — ein Faktor von ungefähr zehn. Der Rest des Anstiegs ist schlicht Aufholjagd: Die Kette startete mit einer Difficulty, die viel zu niedrig war, und die vier Anpassungen am Anschlag haben diesen Abstand abgetragen.

Wer aus der Difficulty-Kurve also einen Ansturm von Minern herausliest, liest eine Korrektur. Verzehnfacht hat sich die Rechenleistung trotzdem, und das ist für eine drei Wochen alte Kette beachtlich.

31 PH/s gegen 910 EH/s

Beachtlich heisst nicht sicher. Der Dienst CoinWarz schätzt die Hashrate des SHA-256d-Netzwerks am 14. September auf 910 EH/s. Das sind 910.000 PH/s. Die BLAKE2b-Kette bringt es auf etwa ein Dreissigtausendstel davon.

Diese Zahl ist deshalb entscheidend, weil sie den Preis eines Angriffs bestimmt. Wer die Mehrheit der Rechenleistung auf einer Kette stellt, kann Transaktionen zurückdrehen. Auf der Hauptkette kostet das den Aufbau einer Industrie; auf der BLAKE2b-Kette kostet es eine Bestellung gebrauchter Siacoin-ASICs, denn die Hardware ist nicht exotisch, sondern seit Jahren im Handel. Genau das ist der Punkt, an dem Proof of Work seine Schutzwirkung aus der Höhe der aufgewendeten Arbeit zieht und nicht aus dem Algorithmus.

Auch im direkten Vergleich bleibt der Abstand gewaltig: Die Hauptkette stand am 14. September bei einer Difficulty von 127,45 Billionen, die Abspaltung bei 3,4 Milliarden. Die beiden Zahlen sind nicht unmittelbar vergleichbar, weil dahinter verschiedene Algorithmen stecken. Vergleichbar ist, was sie kosten — und das führt zurück auf die 910 EH/s.

Die finale Fassung ist da, der Pull Request bleibt ein Entwurf

Zwei offene Punkte aus unserem Beitrag vom 31. August lassen sich jetzt beantworten. Erstens: Bitcoin Knots 29.4.1 ist erschienen, allerdings am 2. September statt wie angekündigt am 1. Die Release Notes nennen den Algorithmuswechsel nüchtern "BLAKE2b proof-of-work algorithm (mitigates ongoing attack)" und führen daneben die befristete Blockgrenze von 800 kWU sowie mehrere behobene CVEs auf. Zweitens: Der von Luke Dashjr in Aussicht gestellte Rücksetzer auf Block 961.639 wurde nicht gebraucht. Die Kette läuft seit der Aktivierung durch.

Was sich dagegen nicht bewegt hat, ist Pull Request 359, der den Wechsel technisch trägt. Er steht weiterhin auf Draft, letzte Aktivität am 15. August, und die drei gemeldeten Prüfbefunde sind unverändert offen. Die Kette produziert also seit gut zwei Wochen Blöcke nach Regeln, deren Vorschlag formal noch nicht einmal zur Prüfung freigegeben ist. Wer das für eine Formalie hält, möge sich vor Augen führen, dass es bei einem Konsensbruch keine zweite Runde gibt.

Ein Pool, eine Börse — und eine Warnung vor dieser Börse

Für alle, die auf der Hauptkette minen, ändert das alles nichts: Der Bitaxe zeigt weiter auf den Pool eurer Wahl, bei uns auf stratum+tcp://blitzpool.yourdevice.ch:3333, und die Übersicht dazu steht in der kleinen Bitcoin Solo Mining Bibel. Auf der Abspaltung hat sich die Lage dagegen sortiert. Neben den Kleinstpools der ersten Tage gibt es inzwischen reguläre Angebote: B2Pool betreibt einen TIDES-Pool mit einem Prozent Gebühr und einer Mindestauszahlung von 10.000 Satoshi, dazu einen Solo-Zweig. Das Fachmedium Cryptolexicon beschreibt mit AlphaPool einen weiteren Anbieter mit PPLNS, 2,5 Prozent Gebühr und vier Relays in den USA, Europa und Singapur, der mit Antminer A3 und Goldshell SC ohne eigene Firmware arbeitet.

Auf der Handelsseite ist das Bild dünner. Am 2. September berichtete Bitcoin.com News von einer einzigen Börse, die BTCB2 listet, bei einem Tagesumsatz von rund 94.100 US-Dollar und einer Handelsspanne von 80 bis 176 Dollar an einem einzigen Vormittag. Bemerkenswert ist weniger der Kurs als die Begleitmusik: Eine Informationsseite aus dem Umfeld der Kette rät im selben Bericht ausdrücklich zur Vorsicht gegenüber genau dieser Börse. Kursangaben aus einem solchen Markt sagen nichts über einen Wert, und wir führen sie hier nur an, weil unsere Feststellung vom 31. August, es gebe für die Coins schlicht keinen Preis, damit überholt ist.

Die Seed-Masche ist zurück

Mit dem Handel kommt die Betrugswelle. Cryptolexicon weist darauf hin, dass im Umfeld der Kette die Behauptung kursiert, für den Erhalt von BTCB2 sei der Import der privaten Schlüssel oder der Seed-Phrase nötig. Das ist falsch. Es ist dieselbe Masche wie bei jeder Abspaltung seit 2017, und sie funktioniert, weil sie technisch halb plausibel klingt.

Der Sachverhalt dahinter: Beide Ketten teilen ihre Geschichte, dieselben Schlüssel gelten auf beiden. Genau deshalb öffnet eine Seed-Phrase, die ihr irgendwo eingebt, nicht nur die Fork-Coins, sondern auch eure echten Bitcoin. Wer eine Seed besitzt, auf der noch Guthaben liegt, bringt sie nirgendwo ein — nicht bei einem Pool, nicht bei einer Börse, nicht in einer Wallet, die Fork-Coins verspricht. Wer alte Bestände tatsächlich bewegen will, räumt zuerst alle echten Bitcoin auf eine neue, frisch erzeugte Wallet und fasst die alten Schlüssel erst danach an.

Für den Umgang mit den zugehörigen Phishing-Mails gilt unverändert, was wir zum BitBox-Phishing mit gültiger DKIM-Signatur geschrieben haben: Eine technisch korrekte Absenderprüfung sagt nichts darüber, ob der Inhalt stimmt.

Was die deutschsprachige Berichterstattung am 2. September schrieb

Am 2. September, also am Tag der zweiten Difficulty-Anpassung, meldete das Fachportal IT Boltwise, der Hardfork sei am 1. September gestartet und "nach Stunden zusammengebrochen", er habe kaum Rechenleistung angezogen. Beides lässt sich an der Kette nachzählen: Der Start war der 30. August, und statt eines Zusammenbruchs hat die Kette an genau jenem 2. September ihre zweite Anpassung am oberen Anschlag genommen.

Das ist kein Detail für Erbsenzähler. Wer eine Kette für tot erklärt, die produziert, unterschätzt sie zwangsläufig auch dort, wo Vorsicht angebracht wäre — etwa bei der Frage, wer auf ihr bezahlt wird und mit welchen Coins. Umgekehrt gilt dasselbe: Eine Kette, die Blöcke ausspuckt, ist deswegen nicht sicher. Beide Fehler entstehen aus derselben Bequemlichkeit, nämlich die Zahlen nicht nachzusehen, obwohl sie öffentlich sind.

Was das für euch heisst

Für den Bestand in eurer Wallet ändert sich nichts. Die Hauptkette läuft unverändert weiter, eure Schlüssel gelten dort wie vorher, und es gibt keinen Schritt, den ihr wegen dieser Abspaltung unternehmen müsstet.

• Nichts tun ist eine vollständige Antwort. Wer die Fork-Coins nicht will, muss dafür nichts einrichten, nichts importieren und nichts abholen.
• Die Seed bleibt, wo sie ist. Kein Werkzeug, kein Pool und keine Börse braucht sie, um euch etwas gutzuschreiben. Wer danach fragt, will das Guthaben auf der Hauptkette.
• Beim Mining zählt die Hardware, nicht der Name. SHA-256-Geräte können auf der BLAKE2b-Kette nicht rechnen. Wer dort minen will, braucht BLAKE2b-Hardware, und wer dafür Geld ausgibt, kauft sich in eine Kette mit einem Dreissigtausendstel der Absicherung ein.
• Beim Empfang von Zahlungen lohnt der Blick auf die Kette. Wer Bitcoin annimmt, sollte wissen, welche Node seine Zahlungseingänge bestätigt. Die Projektseite fordert Börsen ausdrücklich auf zu sagen, welche Kette sie gutschreiben — solange das nicht überall geschieht, ist die Frage berechtigt.

Fazit: Die Difficulty hat aufgeholt, die Sicherheit nicht

Die Kette hat den Test bestanden, der Ende August offen war. Sie produziert Blöcke, sie hat fünf Anpassungen durchlaufen, ihre Rechenleistung hat sich verzehnfacht, die finale Software ist erschienen, und der befürchtete Rücksetzer blieb aus. Das ist mehr, als ihr die meisten zugetraut haben, uns eingeschlossen.

Nur misst die Difficulty nicht, ob eine Kette Bestand hat, sondern nur, wie schwer der nächste Block zu finden ist. 31 PH/s gegen 910 EH/s, ein Pull Request im Entwurfsstadium, eine Börse mit Warnhinweis: Das ist der Stand nach elf Tagen Aufholjagd. Unsere Einschätzung vom 2. Juli bleibt deshalb unverändert. Eine Kette, deren gesamte Absicherung sich in zwei Wochen nachkaufen lässt, hat kein Difficulty-Problem gelöst, sondern nur ihr Blockproduktionsproblem — und das war nie das teure von beiden.

Die nächste Anpassung fällt bei Block 973.728 an. Wenn die Rechenleistung bleibt, dauert das diesmal die vorgesehenen zwei Wochen. Dann steht zum ersten Mal eine Zahl da, die nichts mehr aufholt, sondern etwas aussagt.

Quellen und weiterführende Links

• blake2bminer.com, Difficulty — alle fünf Anpassungen mit Block, Zeitpunkt und Faktor
• blake2bminer.com, Status — Aktivierung, Coinbase-Schlagzeile, Anschlag bei Faktor vier
• blake2bminer.com, Hashrate — Verlauf von rund 3 auf etwa 31 PH/s, Hardwarezahlen
• bitcoinknots/bitcoin, Release 29.4.1 und die zugehörigen Release Notes
• bitcoinknots/bitcoin, Pull Request 359 — Status Draft, letzte Aktivität 15.08.2026
• bitcoin/bitcoin, src/pow.cpp — die Begrenzung jeder Anpassung auf Faktor vier
• bitcoin-blake2b.org, FAQ — Datenlimits bis 1. September 2027, SIGHASH_UNIFIED, Hardware, Aufforderung an Börsen
• CoinWarz, Bitcoin Hashrate — Schätzung von 910 EH/s am 14.09.2026
• B2Pool — TIDES- und Solo-Mining auf der BLAKE2b-Kette
• Bitcoin.com News, 02.09.2026 — Listung, Umsatz und Warnhinweise
• Cryptolexicon — AlphaPool und die Seed-Falschbehauptung
• IT Boltwise, 02.09.2026 — der Bericht vom Zusammenbruch, gegen den sich die Zahlen halten lassen

The post BLAKE2b Difficulty: viermal am Anschlag, dann gebremst appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

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.

Der BLAKE2b-Hard-Fork kam zwei Tage früher als angekündigt

Den Anfang machte eine öffentliche Warnung. Am 29. August, 11:54 Uhr, schrieb Luke Dashjr: "PSA: Potential Bitcoin PoW change Sunday. SHA2 miners should stop mining Saturday." Bitcoin Knots 29.4.1rc4 werde am Tag darauf erscheinen und den letzten SHA-2-Block festschreiben; die Mitteilung wurde in mehreren Foren weitergereicht, weil sie ursprünglich auf X stand. Bemerkenswert ist die Wortwahl: Dashjr nannte den Vorgang eine mainnet rehearsal, also eine Generalprobe im Echtbetrieb. Wer schon einmal eine Generalprobe erlebt hat, bei der anschliessend niemand mehr zurückkonnte, weiss, wie viel Trost in dem Wort steckt.

Der Wechsel selbst erfolgte dann am 30. August um 06:14 UTC bei Block 961.640. Der letzte mit SHA-256d gefundene Block der Abspaltung trägt die Nummer 961.639 und stammt vom 28. August, 17:14 UTC — das lässt sich an einem öffentlichen Explorer nachsehen, der eine Bitcoin-Knots-Node ohne den neuen Algorithmus betreibt und deshalb bis heute genau dort stehen bleibt.

Acht Blöcke in drei Wochen: warum die Kette den Wechsel brauchte

Der Grund für die Eile steckt in der Difficulty. Als sich die Kette am 8. August bei Block 961.632 abspaltete, erbte sie den Schwierigkeitsgrad des Hauptnetzes von rund 127,5 Billionen — aber nur einen Bruchteil der Rechenleistung. Wie diese Anpassung funktioniert und warum sie nur alle 2.016 Blöcke greift, steht in unserem Grundlagenbeitrag Was ist die Mining Difficulty.

Die Zahlen des Explorers zeigen, was das praktisch bedeutet. Zwischen den Blöcken 961.633 und 961.639 lagen Abstände von 13.759 bis 475.772 Sekunden, also von knapp vier Stunden bis zu fünfeinhalb Tagen. Acht Blöcke in drei Wochen. Bis zur nächsten Anpassung bei Höhe 963.648 fehlten zum Zeitpunkt des Wechsels noch 2.009 Blöcke. Selbst mit der gesamten Hashrate des Bitcoin-Netzwerks wären das knapp vierzehn Tage gewesen — mit dem, was die Abspaltung tatsächlich hatte, Jahrzehnte.

Ein Proof-of-Work-Wechsel löst dieses Problem in einem Zug, weil er die Difficulty neu setzen darf. Genau das ist passiert.

Vom Stillstand in den Minutentakt

Die Wirkung war sofort sichtbar. Die Betreiber von blake2bminer.com, einer Informationsseite für Miner der neuen Kette, dokumentieren für den 30. August, 18:55 UTC, den Stand Block 961.877. Das sind 237 Blöcke in gut zwölf Stunden, also im Schnitt einer alle drei Minuten. Aus acht Blöcken in drei Wochen wurden 237 an einem halben Tag.

Das ist der Erfolg, den die Befürworter sich versprochen haben, und er ist real. Er hat nur einen Preis, den keine Difficulty-Anpassung wieder hereinholt: Die sechzehn Jahre aufgehäufte SHA-256-Arbeit, die eine Umschreibung der Bitcoin-Historie unbezahlbar macht, gelten auf der neuen Kette nicht mehr. Wer eine BLAKE2b-Kette angreifen will, muss nur mehr BLAKE2b-Leistung aufbringen als die paar Betreiber, die derzeit darauf rechnen. Der Unterschied zwischen einer Änderung, die alte Regeln verschärft, und einer, die eine neue Kette aufmacht, ist übrigens genau der zwischen Hardfork und Softfork — und diesmal ist es unmissverständlich ein Hardfork.

Was im neuen Block-Header steckt

Die technische Grundlage ist Pull Request 359 im Bitcoin-Knots-Repository, eröffnet von Dashjr am 15. August, 21 Commits. Er ersetzt nicht nur die Hashfunktion, sondern führt einen Block-Header in Version 2 ein. Die dort genannten Ziele sind:

• deutlich mehr Nonce-Raum, aufgeteilt in 128 Bit auf ASIC-Ebene, weitere 128 Bit je Maschine und 8 Bit darüber hinaus
• ein optionaler Schutz gegen Block-Withholding-Angriffe über einen XOR-Schlüssel
• vorbereitete Haken für Merged Mining, also für Seitenketten
• eine Festlegung der Transaktionszahl im Header, beschrieben als saubere Behebung von CVE-2017-12842
• Vorbereitung auf einen 64 Bit breiten Zeitstempel

Dazu kommen befristete Regeln. Die Projektseite der Kette nennt eine Obergrenze von 800.000 Gewichtseinheiten je Block — grob 300 Kilobyte — die bis zum 1. September 2027, 00:00 UTC gilt und danach automatisch entfällt. Das ist die Fortsetzung des ursprünglichen Streits mit anderen Mitteln: Es geht den Betreibern der Kette weiterhin darum, beliebige Daten aus der Kette herauszuhalten. Wer den Hintergrund dazu braucht, findet ihn bei uns unter Bitcoin Knots vs. Bitcoin Core.

Replay-Schutz gibt es nur, wenn ihr ihn anfordert

Der Punkt, der Nutzer am unmittelbarsten betrifft, steht in derselben FAQ: Die privaten Schlüssel bleiben auf beiden Ketten dieselben, und ein Replay-Schutz existiert nur als Option. Wer ihn will, muss das Signaturformat SIGHASH_UNIFIED verwenden. Ohne das kann eine Transaktion, die ihr auf einer Kette sendet, auf der anderen gültig sein.

Für den Umgang damit gilt unverändert, was der Node-Anbieter Start9 schon Mitte August zusammengetragen hat: Offene Lightning-Kanäle existieren nach einer Spaltung auf beiden Ketten, eure Node beobachtet aber nur eine davon. Und die alte Regel bleibt die wichtigste: Gebt eure Seed-Phrase niemals in ein Werkzeug ein, das euch Fork-Coins verspricht. Das war schon bei jedem früheren Fork der schnellste Weg, echte Bitcoin zu verlieren.

Mining für alle? Die Rechnung geht am ersten Tag nicht auf

In der Berichterstattung wurde BLAKE2b durchgehend als Rückkehr zum Mining mit gewöhnlicher Hardware verkauft: endlich wieder CPU und Grafikkarte statt Spezialchips. Das hält keinen Tag stand, und zwar nicht wegen einer Prognose, sondern wegen vorhandener Hardware. BLAKE2b ist der Algorithmus, mit dem seit Jahren Siacoin gemint wird, und es gibt dafür ASICs zu kaufen.

Die Miner-Seite zur neuen Kette beziffert eine RTX 3090 auf rund 5 GH/s und stellt daneben, dass eine Goldshell-SC-Box das Hundertfache schafft. CPUs bezeichnet sie als "not viable from the start". Die Projekt-FAQ selbst schreibt, ein Antminer A3 funktioniere "ab dem ersten Block". Die Kette hat also nicht die ASICs abgeschafft, sondern nur den Hersteller gewechselt — von den grossen SHA-256-Farmen zu einem Lager gebrauchter Siacoin-Geräte, das seit Jahren auf einen zweiten Frühling wartet. Das ist eine Dezentralisierung, die vor allem den Besitzern alter Hardware nützt.

Für alle, die weiterhin auf der Hauptkette minen, ändert das nichts. Der Bitaxe zeigt weiter auf den Pool eurer Wahl, bei uns auf stratum+tcp://blitzpool.yourdevice.ch:3333; die Übersicht dazu steht in der kleinen Bitcoin Solo Mining Bibel. Auf der BLAKE2b-Kette sind bislang eine Handvoll kleiner Pools aktiv, unter anderem SilentWave, PyBLOCK, Helios, PythonPool und TrueNorth — Namen, die vor drei Wochen niemand kannte.

Der Code, auf dem das läuft, ist offiziell noch ein Entwurf

Pull Request 359 trägt zum Zeitpunkt dieses Artikels weiterhin den Status Draft. In der Diskussion stehen drei von Prüfern gemeldete Befunde: Das Argument -powchangetime nimmt das dokumentierte Format time[:algo] nicht an, eine Assertion prüft 0x40 + 88 statt der offenbar richtigen 90, und die Testfunktion powhash bildet die tatsächliche Header-Konstruktion nicht ab. Die Kette läuft derweil auf einem Release-Kandidaten; die finale Fassung war für den 1. September angekündigt.

Das ist auch dann bemerkenswert, wenn ihr dem Vorhaben wohlwollend gegenübersteht. Ein Konsensbruch, der sich nicht rückgängig machen lässt, wurde hier ausgeliefert, bevor der zugehörige Vorschlag aus dem Entwurfsstadium heraus war.

Am Tag vor dem Fork verliess Luke Dashjr Ocean

Am 29. August, demselben Tag wie die Warnung an die Miner, veröffentlichten der Mining-Pool Ocean und Dashjr eine gemeinsame Mitteilung. Darin heisst es, er scheide im gegenseitigen Einvernehmen aus und lege die Ämter als Chairman, Chief Technology Officer und Verwaltungsrat nieder; das Unternehmen habe sämtliche Anteile zurückgekauft. Als Grund nennt die Mitteilung "the parties' different visions for the future of Bitcoin mining following the recent protocol developments". Dashjr startet demnach ein neues Vorhaben namens CONVOY.

Wer hier wen verlassen hat, sagt die Mitteilung nicht, und wir schreiben es deshalb auch nicht. Was sie sagt, reicht: Der Pool, der am 8. August den ersten signalisierenden Block gefunden hat, geht den Weg zur neuen Kette nicht mit — und der Rückkauf sämtlicher Anteile ist keine Formulierung für einen freundlichen Abschied.

Was in der Fachpresse steht und in den Quellen nicht

Zwei Angaben kursieren, die sich in den Primärquellen nicht wiederfinden. Erstens wird BLAKE2b mehrfach als quantenresistent beschrieben. In der Liste der Vorteile im Pull Request steht dieses Wort nicht, und die Projektseite begründet den Wechsel ebenfalls anders. Zweitens werden Zahlen zu hängenden Transaktionen und zur nötigen Hashrate genannt, die auf Testnetz-Beobachtungen einzelner Fachmedien zurückgehen; überprüfbar sind sie derzeit nicht. Beides ist im Auge zu behalten, keines davon taugt als Beleg.

Wie es weitergeht

Drei Termine bestimmen die nächsten Monate.

• 1. September 2026: Für diesen Tag ist die finale Fassung von Bitcoin Knots 29.4.1 angekündigt. Bis dahin läuft die Kette auf einem Release-Kandidaten, und Dashjr hatte einen Rücksetzer auf Block 961.639 in Aussicht gestellt, falls Fehler auftreten.
• Die erste Difficulty-Anpassung der neuen Kette: Sie zeigt, ob die Rechenleistung bleibt oder ob es sich um einen Startschub gehandelt hat. Bei dreiminütigen Blockabständen fällt sie in wenigen Tagen an — der eigentliche Belastungstest.
• 1. September 2027: An diesem Tag laufen die befristeten Datenlimits aus. Ob die Kette dann noch existiert, ist die interessantere Frage.

Offen bleibt zudem, ob eine Börse, ein Wallet-Anbieter oder ein Lightning-Dienst die Kette unterstützt. Bis heute hat sich keiner öffentlich dazu bekannt, und ohne das gibt es für die Coins auf der Abspaltung schlicht keinen Preis.

Fazit: Ein neuer Algorithmus ist keine wiederhergestellte Sicherheit

Der Wechsel hat getan, was er tun sollte. Die Kette produziert wieder Blöcke, die Difficulty-Falle ist aufgelöst, und das Vorhaben ist damit weiter, als es die meisten — uns eingeschlossen — Mitte August erwartet hätten. Wer daraus aber ableitet, das Projekt habe seine Probleme gelöst, verwechselt Blockproduktion mit Sicherheit.

Eine Kette ist so schwer angreifbar wie die Arbeit, die in ihr steckt. Diese Arbeit wurde am Sonntag auf null gesetzt und wird seither von einer Handvoll Betreiber mit gebrauchten Siacoin-ASICs neu aufgebaut. Der Code dazu ist ein Entwurf, der Replay-Schutz optional, der prominenteste Pool ausgestiegen und der Initiator gerade dabei, eine neue Firma zu gründen. Das mag alles noch werden. Aber es ist das Gegenteil dessen, was Proof of Work zum belastbaren Konsensmechanismus macht: aufgewendete Rechenleistung, die so teuer ist, dass ein Angriff sich nicht lohnt. Genau diesen Vorsprung hat die Kette am 30. August freiwillig aufgegeben. Unsere Einschätzung vom 2. Juli bleibt damit unverändert stehen.

Quellen und weiterführende Links

• bitcoinknots/bitcoin, Pull Request 359: Hardfork: New BLAKE2b proof-of-work algorithm
• btc-blake2b.org, FAQ der BLAKE2b-Kette — Datenlimits, SIGHASH_UNIFIED, Hardware
• btc-blake2b.org, Startseite des Projekts
• 110explorer.com — Explorer über eine Bitcoin-Knots-RDTS-Node, Blockabstände und Difficulty
• blake2bminer.com — Miner-Informationsseite mit Aktivierungszeitpunkt, Blockstand und Hardwarezahlen
• Joint Statement of OCEAN and Luke Dashjr, 29.08.2026
• Start9: Navigating the BIP-110 (RDTS) Activation — Replay- und Lightning-Risiken
• Weitergeleitete PSA von Luke Dashjr, 29.08.2026
• bip110.run — Chronik der Kettenspaltung vom 8. August

The post BLAKE2b-Hard-Fork ist aktiv: was jetzt wirklich läuft 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.

Was am 8. August wirklich passiert ist

Der letzte gemeinsame Block beider Ketten war 961.631. Bei Höhe 961.632 begann das Fenster, in dem BIP-110 von jedem Block eine Signalisierung auf Bit 4 verlangt. Blöcke ohne dieses Signal gelten für eine BIP-110-Node ab da als ungültig.

Die Hauptkette lieferte ihren Block 961.632 am 8. August um 19:35:55 UTC, gefunden von AntPool, mit 5.612 Transaktionen und einer Netzwerk-Difficulty von rund 127,5 Billionen. Das lässt sich in jedem Explorer nachsehen, etwa bei mempool.space. Dieser Block signalisierte nicht — die BIP-110-Nodes verwarfen ihn und blieben stehen, bis ein eigener Miner einen eigenen Block 961.632 fand. Ab diesem Moment gab es zwei Ketten.

Wie knapp die Sache war, sagt die Zahl, die BIP-Editor Mark Erhardt am 9. August auf der Entwickler-Mailingliste nannte: BIP-110 kam auf „just shy of 2.5% of blocks signaling readiness". Nötig gewesen wären 55 Prozent, also 1.109 von 2.016 Blöcken. Was ein Soft Fork und was ein Hard Fork ist und warum der Unterschied hier zählt, steht in Unterschied zwischen Hardfork und Softfork in der Blockchain.

Ein Detail, das in der Berichterstattung untergeht: 961.632 ist durch 2.016 teilbar — 2.016 mal 477 ergibt exakt diese Höhe. Die Abspaltung fiel also punktgenau auf eine Difficulty-Anpassung. Das war kein Zufall, sondern gewollt, und es hat für die Abspaltung die denkbar schlechteste Folge.

Die Difficulty-Falle: 2.016 Blöcke bis zur Anpassung

Eine abgespaltene Kette erbt die Schwierigkeit der Kette, von der sie sich trennt — hier also die vollen 127,5 Billionen, aufgestellt für ein Netz mit hunderten Exahash. Angepasst wird erst nach 2.016 eigenen Blöcken. Weil der Split exakt auf der Anpassungsgrenze lag, muss die BIP-110-Kette diese 2.016 Blöcke vollständig durchziehen, bevor ihre Difficulty auch nur ein einziges Mal fällt. Wer wissen will, wie diese Mechanik funktioniert: Was ist die Mining Difficulty.

Nach Angaben von Bitcoin.com stand die Abspaltung am 15. August bei Block 961.635, also vier Blöcken in sieben Tagen, gefunden vom Pool Roughnecks. Diese Zahl liess sich nicht gegen einen neutralen Explorer prüfen und ist als Medienangabe zu lesen. Rechnet sie trotzdem einmal durch: Bei vier Blöcken pro Woche braucht die Kette für 2.016 Blöcke rund 3.500 Tage — knapp zehn Jahre bis zur ersten Anpassung. Die kursierenden Schätzungen reichen von 350 Tagen bis 25 Jahren, je nach unterstellter Hashrate; die beobachtete Blockrate liegt am pessimistischen Ende.

Das ist kein Anlaufproblem, das sich mit Geduld löst, sondern ein Zustand, in dem eine Kette technisch existiert und wirtschaftlich nicht stattfindet — mit Folgen für jeden, der noch auf ihr sendet.

Ocean schickte 18 Stunden Hashrate auf die tote Kette

Der Mining-Pool Ocean räumte ein, dass ein Konfigurationsfehler Miner rund 18 Stunden lang auf der BIP-110-Kette arbeiten liess, obwohl diese den Endpunkt für die andere Kette gewählt hatten. Der Pool kündigte auf X rund 0,3 BTC Entschädigung an, auszuzahlen binnen 72 Stunden.

Als Lehrstück ist der Vorfall mehr wert als die Summe, denn er zeigt, wer bei einer Kettenspaltung tatsächlich entscheidet: nicht der Miner, sondern derjenige, der die Arbeitsaufträge verteilt — dasselbe Machtgefälle, das wir in Stratum V2 und die Coinbase-Hoheit beschrieben haben.

Der Plan: Proof of Work wechseln und die Miner feuern

Statt das Ergebnis anzunehmen, kündigten die Befürworter einen Ausweg an. Luke Dashjr, langjähriger Bitcoin-Entwickler und Mitautor auf der BIP-110-Seite, schrieb bereits am 5. August auf X: „If BIP110 doesn't pan out, the only option is a PoW change."

Ein Wechsel des Proof-of-Work-Algorithmus macht jeden vorhandenen Bitcoin-ASIC auf dieser Kette wertlos. Die Geräte rechnen SHA-256d in Hardware und können nichts anderes. Das ist kein Nebeneffekt, das ist der Zweck: Wer die Miner nicht überzeugen kann, schliesst sie aus.

„Bpedo": Wer hier wen angegriffen haben soll

Bemerkenswert ist, wie die Vorgänge seither beschrieben werden. Noch am Abend des 8. August schrieb Dashjr auf seinem X-Konto: „. @AntPoolofficial appears to be attacking Bitcoin. Hold tight everyone." Gemeint war der Pool, der wenige Stunden zuvor den regulären Block 961.632 gefunden hatte.

Am 12. August legte er unter der Überschrift „Facts" nach. Vier Punkte, sinngemäss: Am Samstag hätten „bad actors" einen strittigen Hard Fork versucht, „with the purpose of forcing users to distribute CSAM"; daraus sei eine neue „scamcoin with an airdrop" entstanden, die er „Bpedo" nennt. Die ehemaligen Bitcoin-Pools würden das Netzwerk angreifen, „to try to deceive the world into thinking Bpedo is 'the real Bitcoin'". Wer keine eigene Node betreibe, falle darauf herein; ein Upgrade auf „the latest release of Bitcoin Knots" bringe einen zurück „on the Bitcoin network". Und: „Community-led mitigations are in progress to overcome the ongoing attack" — erwartet zum 1. September.

Nüchtern betrachtet steht hier die Realität auf dem Kopf. Die Kette mit 97,5 Prozent der Hashrate hat keine Regel geändert — sie läuft unverändert weiter. Geändert hätte die Regeln der Vorschlag, der die nötige Zustimmung nicht bekam. Wer nichts tut, forkt nicht. Auch der CSAM-Vorwurf trägt die Last nicht, die ihm aufgeladen wird: Dahinter steht die seit Jahren bekannte Tatsache, dass sich beliebige Daten in Transaktionen einbetten lassen — ein Problem, das mit dem gescheiterten Fork weder entstanden noch verschwunden ist, und das kein Miner „erzwingt".

Die Zuspitzung hat einen praktischen Zweck: Wenn die Mehrheitskette ein Betrug ist, ist der Wechsel des Proof of Work keine Abspaltung mehr, sondern Notwehr.

BLAKE2b, ausgewürfelt auf Testnet4

Wie der neue Algorithmus bestimmt wurde, kündigte Dashjr am 11. August auf X im Detail an. Ab 14:00 UTC werde die Testnet4-Kette beobachtet. Dann: „The very next block found, look at the block hash. The last character will choose the new algorithm." Aus einer zuvor zusammengestellten, nach Eignung gewichteten Kandidatenliste sollte also das letzte Zeichen eines Testnetz-Blockhashes auswählen — ein Hexadezimalzeichen, sechzehn Möglichkeiten. Um Manipulation auszuschliessen, veröffentlichte er vorab den SHA256-Hash der Zuordnungstabelle: „You can prove I didn't rig it".

Einen Tag später stand das Ergebnis fest: BLAKE2b, mit einem geplanten Hard Fork zum 1. September 2026. Begründet wird die Wahl damit, dass BLAKE2b auf gewöhnlichen CPUs und GPUs laufe und die ASIC-Dominanz breche.

Die Vorab-Festlegung per Hash ist sauber gemacht, das sei ausdrücklich gesagt: Sie beweist, dass die Tabelle nachträglich nicht verändert wurde. Über die Frage, die zählt, beweist sie nichts. Denn welcher Hash-Algorithmus die Sicherheit eines Netzwerks im Milliardenbereich trägt, gehört in eine mehrjährige Prüfung mit Kryptografen, Referenzimplementierungen, Testnetzen und veröffentlichten Angriffsmodellen — nicht in ein Verfahren, dessen Ergebnis am letzten Zeichen eines Testnetz-Blockhashes hängt. Grosse Sorgfalt lag darauf, dass die Ziehung fair ist, und keine erkennbare darauf, ob überhaupt gezogen werden sollte. Manipulationssicher ausgewürfelt bleibt ausgewürfelt.

Wer Proof of Work tauscht, hat aufgehört, Bitcoin zu sein

Das eigentliche Problem liegt tiefer als die Frage, ob BLAKE2b ein guter Algorithmus ist. Bitcoins Sicherheit besteht nicht aus Regeln in einem Dokument, sondern aus über sechzehn Jahren aufgehäufter Rechenarbeit in SHA-256d. Diese Arbeit ist der Grund, warum sich die Kette nicht umschreiben lässt.

Ein Algorithmuswechsel setzt genau diesen Zähler auf null. Ab dem ersten BLAKE2b-Block sichert eine Kette, die eine sechzehnjährige Transaktionshistorie mit sich trägt, sich selbst mit der Rechenleistung eines Hobbynetzwerks. Wer sie umschreiben will, braucht dann keine Milliarden an Hardware mehr, sondern eine Handvoll Server. Die Befürworter wollen Bitcoin vor einem Angriff schützen und bauen dabei genau die Bedingung her, gegen die Proof of Work überhaupt schützt.

Der Streit um die BIP-Editoren

Parallel läuft ein zweiter Konflikt. Jon Atack beantragte am 9. August auf der Entwickler-Mailingliste, den Status von BIP-110 von „Deployed" auf „Closed" zu setzen, weil das Netzwerk den Fork abgelehnt habe. Widerspruch kam unter anderem von Greg Tonoski, der auf rund 18.000 Nodes verwies, die BIP-110 akzeptieren, und fragte, ob deren Guthaben damit zur Beschlagnahmung freigegeben sei. Sjors Provoost hielt dagegen, dass ein geschlossener BIP-Status niemandem etwas wegnimmt.

Am selben Tag beantragte Mark Erhardt in Pull Request 2248 die Abberufung von Luke Dashjr als BIP-Editor. Die Begründung nennt Interessenkonflikte bei einem Vorschlag, an dem er selbst beteiligt war, weniger als ein Prozent der Editor-Kommentare seit April 2024 und die vorzeitige Vergabe einer BIP-Nummer auf X, bevor der Vorschlag auf der Mailingliste diskutiert war. Die zugehörige Debatte steht in der Mailingliste.

Vollzogen wurde die Abberufung schnell. Bryan Bishop hielt am 10. August auf der Mailingliste fest: „The individual known as Luke Dashjr is no longer an authorized user in the BIP content repository." Damit ist der Schreibzugriff weg — die Rolle also faktisch beendet, keine 26 Stunden nach dem Antrag.

Formal hinkt die Dokumentation nach: Pull Request 2248 war am 17. August unverändert offen, und BIP 3, das die Zuständigen auflistet, führte ihn weiterhin auf. Wer die Lage prüfen will, schaut in beide Dokumente statt auf Schlagzeilen — die einen melden die Entfernung als abgeschlossen, die anderen zeigen sie noch nicht.

Was ihr tun könnt

Das Signalisierungsfenster ist vorbei, der angekündigte Hard Fork zum 1. September ist es nicht. Für die kommenden zwei Wochen gilt deshalb dasselbe wie im August:

• Prüft, welche Software eure Node fährt. Bitcoin Core und Bitcoin Knots vor der RDTS-Erweiterung sind konsensidentisch und folgen derselben Kette; die Unterschiede liegen in der Weiterleitungspolitik. Was das konkret heisst, steht in Bitcoin Knots vs. Bitcoin Core.
• Betreibt ihr Lightning-Kanäle, behaltet den 1. September im Auge. Ein offener Kanal über eine Kettenspaltung hinweg ist eine doppelte Haftung, weil der Gegenpart widerrufene Zustände auf der Kette veröffentlichen kann, die ihr nicht überwacht.
• Wenn ihr mint, klärt vorher, welche Kette euer Pool bedient und ob ihr das selbst umstellen könnt. Der Ocean-Vorfall zeigt, dass die Voreinstellung im Zweifel gegen euch läuft. Wer die Kettenwahl nicht abgeben will, betreibt Solo-Mining — etwa über blitzpool.yourdevice.ch oder einen anderen Solo-Pool, bei dem ihr die Node hinter dem Pool kennt.
• Verlasst euch bei einer Spaltung nicht auf eine Börse: Ob ihr auf einer, beiden oder keiner Kette gutgeschrieben werdet, entscheidet der Verwahrer nachträglich. Eigene Verwahrung und eine eigene Full Node sind der Unterschied zwischen Mitreden und Abwarten.

Wenn eure Node auf der Abspaltung hängt

Wer eine Knots-Version mit den RDTS-Regeln fährt, sieht die Hauptkette gar nicht: Die Node hat deren Block 961.632 als ungültig markiert und bleibt auf 961.631 stehen. Wer in diesem Zustand eine Transaktion gesendet hat, wartet womöglich unbegrenzt auf die Bestätigung — auf einer Kette, auf der alle paar Tage ein Block gefunden wird. Der Weg zurück, exemplarisch für eine Linux-Node:

# 1. Node stoppen
bitcoin-cli stop

# 2. Wallet-Verzeichnis sichern, bevor irgendetwas angefasst wird
cp -a ~/.bitcoin/wallets ~/wallets-backup-$(date +%F)

# 3. Binary austauschen: Bitcoin Core installieren oder eine
#    Knots-Version ohne die RDTS-Regeln. Danach Node starten.

# 4. Stand pruefen
bitcoin-cli getblockchaininfo | grep -e '"blocks"' -e bestblockhash

# 5. Haengt die Node weiter auf 961.631, den als ungueltig
#    markierten Hauptketten-Block wieder zulassen:
bitcoin-cli reconsiderblock \
  00000000000000000000d1e01392faa65ceeaed307f0a3159144b84146ff24ba

# 6. Bleibt sie stehen, den Blockindex neu aufbauen:
bitcoind -reindex-chainstate

Danach gleicht ihr Höhe und bestblockhash mit einem öffentlichen Explorer ab. Stimmen beide überein, seid ihr wieder auf der Kette, auf der der Rest des Netzes rechnet. Transaktionen, die auf der Abspaltung unbestätigt liegen geblieben sind, müsst ihr auf der Hauptkette neu senden.

Gebt eure Seed-Phrase nirgends ein, um Fork-Coins zu holen

Bei jeder Kettenspaltung tauchen Angebote auf, die versprechen, die Coins auf der neuen Kette „freizuschalten": eine Seite, eine App, ein Formular für eure Wiederherstellungsphrase. Tut das unter keinen Umständen, auch nicht, wenn das Angebot aus dem Umfeld des Forks selbst kommt.

Eure Seed-Phrase ist nicht der Schlüssel zu den Fork-Coins. Sie ist der Schlüssel zu allen euren Coins, auf jeder Kette, die aus demselben Ursprung hervorgegangen ist. Wer sie bekommt, räumt euer Guthaben auf der Hauptkette ab — und das ist echtes Geld, während Coins auf einer Kette mit vier Blöcken pro Woche und ohne Börsenanbindung praktisch nichts wert sind. Das Geschäft lautet also: alles riskieren für nichts.

Fazit: BIP-110 ist an der Arithmetik gescheitert, nicht an einer Verschwörung

BIP-110 hatte einen Mechanismus, der bei 55 Prozent Zustimmung greift, und bekam knapp 2,5. Danach braucht es keine Verschwörung mehr, nur eine Division. Die Kette, die daraus entstand, schafft vier Blöcke pro Woche und bräuchte in diesem Tempo ein Jahrzehnt bis zur ersten Difficulty-Anpassung. Das ist keine Unterdrückung durch eine Übermacht, sondern das vorhersehbare Ergebnis eines Plans, der die Hashrate für eine Formsache hielt.

Die Antwort darauf — einen ausgelosten Algorithmus einzuführen und die Mehrheit des Netzes zu Angreifern zu erklären — beendet die Diskussion, statt sie zu gewinnen. Eine Kette mit neuem Proof of Work ist kein gerettetes Bitcoin. Sie ist ein neues Projekt mit einer alten Transaktionshistorie und ohne die Arbeit, die diese Historie bisher geschützt hat. Es steht jedem frei, so etwas zu starten. Nur sollte es dann seinen eigenen Namen tragen.

Für alle anderen hat der August eine beruhigende Nachricht geliefert: Bitcoins Konsensregeln lassen sich nicht per Ankündigung ändern, auch nicht von langjährigen Entwicklern mit lauter Stimme. Das ist genau die Eigenschaft, wegen der sich das Ganze lohnt.

Quellen und weiterführende Links

• BIP-110: Reduced Data Temporary Softfork — Text des Vorschlags mit Aktivierungsparametern
• bitcoindev: BIP 110 – update status to closed — Debatte ab 9. August 2026
• bitcoindev: Motion to remove Luke Dashjr from BIP Editors
• bitcoin/bips Pull Request 2248: process – Remove Luke from BIP Editors
• BIP 3 — Liste der amtierenden BIP-Editoren
• mempool.space: Block 961.632 — Zeitstempel, Miner, Difficulty und Blockhash der Hauptkette
• Luke Dashjr am 5. August 2026 zum möglichen PoW-Wechsel
• Luke Dashjr am 11. August 2026 zum Auswahlverfahren über Testnet4
• Das X-Konto von Luke Dashjr — Fundstelle der Beiträge vom 8. und 12. August 2026 („attacking Bitcoin", „Facts"/„Bpedo")
• Ocean zur Entschädigung nach dem Konfigurationsfehler
• Start9: Navigating the BIP-110 (RDTS) Activation — Hinweise für Node- und Lightning-Betreiber
• bip110.run — Statusanzeige zu Signalisierung und Kettenspitzen
• Bitcoin.com: BIP-110 Breakaway Chain Faces a Long Fight to Survive — Fundstelle für Blockstand und Pool der Abspaltung

The post BIP-110 gescheitert: jetzt soll BLAKE2b es richten appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die gute Nachricht: Die meisten ASIC Miner laufen nicht optimal ab Werk. Hersteller setzen konservative Standardeinstellungen, um zu garantieren, dass alle Chips - selbst die schwächsten aus der Produktion - stabil laufen. Das bedeutet aber auch: Euer spezifischer Chip könnte deutlich mehr leisten, effizienter arbeiten oder mit weniger Spannung auskommen. Jeder Chip ist anders, und genau hier liegt euer Potenzial!

Was euch in diesem Guide erwartet:

Lernt die Geheimnisse des Core Voltage & Frequency Tuning kennen - die beiden wichtigsten Parameter, die über Performance, Effizienz und Stabilität eurer Mining-Hardware entscheiden. Ob ihr nun:

• Probleme beheben wollt: Niedrige Hashrates, instabile Chips oder Hardware-Errors beseitigen
• Effizienz steigern möchtet: Bis zu 20-30% weniger Stromverbrauch bei minimalem Hashrate-Verlust (Undervolting)
• Maximum Performance anstrebt: Sicher übertakten für 5-15% mehr Hashrate (Overclocking)

Dieser umfassende Guide deckt alle drei Szenarien ab - von der Diagnose über die Optimierung bis hin zum sicheren Pushen eurer Hardware-Grenzen. Mit konkreten Beispielen, Schritt-für-Schritt-Anleitungen und technischem Hintergrundwissen ausgestattet, werdet ihr nach diesem Artikel genau wissen, wie ihr das Maximum aus euren Mining-Geräten herausholt!

Anfänger-Hinweis: Falls ihr neu in der Mining Welt seid, empfehlen wir euch, zunächst die Bitcoin Mining Bibel zu lesen, damit ihr die Grundlagen des Minings kennen lernt.

Quick Explain: Spannung & Frequenz

Core Voltage

Stellt euch dies als die Stromversorgung des Mining-Chips' Gehirn (dem Core) vor. Gemessen in Millivolt (mV), bestimmt es, wie viel elektrische Energie dem Chip für seine Berechnungen zur Verfügung steht.

Zu niedrige Spannung führt zu Instabilität ungültigen Shares ("Invalid Shares" oder "Summit-Fehler") und somit zu schlechterer Leistung; zu hohe Spannung erhöht die Wärmeerzeugung dramatisch und riskiert Beschädigungen.

Technischer Hintergrund: Der Chip führt im Grunde Berechnungen durch, bei denen Transistoren zwischen An- und Ausgängen schalten. Eine niedrigere Spannung führt dazu, dass diese Übergänge nicht schnell genug erfolgen oder fehlschlagen, besonders bei höheren Frequenzen. Die Spannung bestimmt auch den Schwellenwert, den die Transistoren erreichen müssen – unter diesem Punkt funktioniert der Chip nicht mehr zuverlässig.

Taktfrequenz

Gemessen in Megahertz (MHz), ist dies die Geschwindigkeit, mit der der Chip seine Hash-Berechnungen durchführt.

Höhere Frequenz = mehr Berechnungen pro Sekunde = potentiell höhere Hashrate, aber es benötigt auch mehr Stromzufuhr und erzeugt wesentlich mehr Wärme.

Technischer Kontext: Die Frequenz bestimmt, wie viele Male pro Sekunde die internen Logik-Gatter schalten. Bei SHA-256 (Bitcoin Mining) müssen Millionen von logischen Operationen pro Hash durchgeführt werden. Die Frequenz multipliziert sich direkt in der Hashrate-Berechnung.

Die tiefe Verbindung: Voltage × Taktfrequenz

Diese zwei Einstellungen sind nicht unabhängig.

Frequenz erhöhen erfordert Spannung: Wenn ihr die Frequenz erhöht, schalten die Transistoren schneller. Dies erfordert jedoch, dass die Spannung hoch genug ist, um diese schnelleren Übergänge zuverlässig zu treiben. Eine zu niedrige Spannung bei hoher Frequenz führt zu "Timing Violations" – der Chip kann seine Operationen nicht in der geforderten Zeit abschließen.

Spannung erhöhen kostet Energie & Wärme: Eine höhere Spannung bedeutet, dass mehr Strom durch die Transistoren fließt. Dies folgt dem Ohmschen Gesetz: P = V² × I / R. Da die Verlustleistung mit dem Quadrat der Spannung zunimmt (oder mit V × I), steigt die Wärmeerzeugung superlinear – eine kleine Spannungserhöhung kann zu einer großen Temperaturerhöhung führen.

Effizienzkurve (J/TH): Energieeffizienz wird in Joules per Terahash (J/TH) gemessen. Der optimale Punkt für die meisten ASIC-Chips liegt typischerweise im mittleren Spannungsbereich (nicht zu niedrig, nicht zu hoch) und bei einer Frequenz, die nicht zu weit über dem Factory Default liegt. Das "sweetspot" variiert stark je nach Chip und Batch.

Gibt es eine universelle "beste" Einstellung

Die kurze Antwort: Nein.

Die Werkseinstellungen (z.B. 1150mV / 550MHz für einen ASIC Chip wie den BM1370) sind lediglich sichere Startpunkte, die auf Durchschnittswerten über tausende von Chips basieren.

Warum Variationen existieren:

1. Silizium-Loterie (Silicon Binning): Auch Chips aus demselben Produktionslos zeigen geringfügige physikalische Variationen. Der Halbleiterprozess ist nicht perfekt – Dotierungskonzentrationen, Transistorgeometrie und andere Parameter weichen leicht ab. Das bedeutet, dass jeder Chip ein leicht unterschiedliches Optimal-Fenster für Spannung/Frequenz hat.
2. Thermal Interface & Wärmeableitung: Die Qualität der Wärmepaste, die Aufpressdruck und die Anbindung des Heatsinks variieren zwischen Chips. Ein Chip mit besserer thermischer Anbindung kann höhere Frequenzen bei gleicher Temperatur tolerieren.
3. Power Delivery: Die Qualität der Stromversorgung und die Stabilität eurer PSU beeinflussen, welche Spannungen zuverlässig geliefert werden können.
4. Umgebungstemperatur & Kühlung: Ein Miner in einer kalten Umgebung mit ausgezeichnetem Airflow wird anders OC-grenzen haben als einer in einem warmen Serverraum.

Wann ist dieser Leitfaden relevant

Dieser Guide ist für 3 Szenarien sinnvoll:

1. Performance-Optimierung (Overclocking – OC)

Sicher zusätzliche Performance heraus holen – natürlich mit Vorsicht!

2. Undervolting und Effizienz Tuning

Möchtet ihr die maximale Effizienz aus eurem Miner herausholen, dann seid ihr in diesen Abschnitt genau richtig. Wir senken die ASIC Spannung so ab, damit der Stromverbrauch sinkt, und die Effizienz des Geräts steigt. Das gute daran, es ist praktisch nicht gefährlich.

3. Troubleshooting Underperforming Chips

Wenn euer Miner-Dashboard konsistent niedrige Hash-Submissions ("Invalid Shares", "HW Errors") zeigt, oder die Gesamthashrate konsistent unter Erwartungen liegt – dies deutet oft auf unzureichende Core Voltage für die aktuelle Frequenz hin.

Häufige Fehler:

• Low Hashrate: Der Chip hasht, sendet aber weniger als erwartete Shares
• Invalid Shares: Der Chip produziert ungültige Hashes (falsche Berechnungen)
• Hardware Errors (HW): Der Chip schlägt bei der Verarbeitung fehl

Vorbereitungen

Macht euch mit dem User Interface von AxeOS oder der NerdQ Geräte vertraut. Beide Geräte bieten eine saubere und übersichtliche Oberfläche an, um die Performance der Geräte bestens zu überwachen.

AxeOS:

NerdQ OS:

In den Dashboards habt ihr den Überblick zur Hashrate, dem Stromverbrauch, die Input Voltage des Netztteils, die ASIC Spannung in Volt, die ASIC Temperatur, die VRM/VR Temperatur, die Lüfterdrehzahl und die Lüfterdrehzahl in Prozent. Diese Angaben helfen euch, den aktuellen Stand des Gerätes einzuschätzen.

OC Modus freischalten

In AxeOS müsst ihr Einstellungen/Settings des Gerätes, und dort den OC Modus freischalten. Dazu muss am Ende des Browserlinks ein

?oc=

angehängt werden. Aus

http://192.168.5.30/#/settings

wird

http://192.168.5.30/#/settings?oc=

Danach zeigt sich ein gelber Banner mit einem Warnhinweis:

Auf den NerdQ Geräten könnt ihr das über einen einfach Button tun:

Danach könnt ihr die Frequenzen und die Spannungen freier auswählen und feiner abstimmen

Lüftersteuerung kennen lernen

Bitaxen und NerdQ Geräte verfügen über eine automatische Lüftersteuerung, welche nach einem Temperatur Target arbeitet. Heisst also, die Lüfter Geschwindigkeit passt sich automatisch an die ASIC Temperatur an. Erhöht ihr Frequenz und Spannung, steigt nicht unbedingt die Chip Temperatur, sondern die Lüfterdrehzahl erhöht sich, bis das Maximum von 100% erreicht ist.

Aus Sicherheitsgründen sollte ein Lüfter nicht bei 100% im automatischen Modus laufen, da hier keinerlei Reserven mehr bestehen, vor allem, wenn es im Raum wärmer werden sollte. Ein gutes Temperatur Target liegt bei 60°c. Optimalerweise dreht der Lüfter dabei bei ca 50% seiner maximalen Drehzahl

Die Einstellungen dazu findet ihr in den Settings von NerdQ oder AxeOS:

Bei Geräten mit besseren Kühlern kann man das Temperatur Target auch etwas absenken, sollte sich der Kühler zu fest langweilen, und der Lüfter mit sehr niedriger Drehzahl arbeiten. Generel kann man sagen, dass sich kühlere Chips besser übertakten lassen.

Temperatur Grenzen der Bitaxen und NerdQ Geräten

Wichtig zu wissen: die ASIC Chips sollten wenn möglich 70° nicht überschreiten. Aus Sicherheitsgründen fahren die meissten Home Miner bei über 70° herunter. Danach schaltet sich der Überhitzungsschutz ein. Dieser wird euch deutlich in den Einstellungen der Miner angezeigt. Deaktiviert den Überhitzungsschutz, und stellt die Standardwerte der Chips wieder ein (BM1370 = 525mhz bei 1.15v)

Teil 1: Der vorsichtige Weg zum Overclocking

⚠️ WARNUNG: Overclocking birgt Risiken

Bevor ihr weiterlest, müsst ihr diese Risiken verstehen und akzeptieren:

1. Fortgeschrittenes Wissen erforderlich

• Ihr benötigt ein solides Verständnis von Elektronik, eurer spezifischen Hardware und Kühlungsgrenzen
• Ein naives "einfach mehr Frequenz" Experiment wird mit hoher Wahrscheinlichkeit zu Problem und Instabilitäten führen

2. Hardware-Schadensrisiko

• Bleibende Schäden möglich: Falsche Einstellungen können euren ASIC-Chips oder Hashboards permanent beschädigen
• Point of No Return: Einige Schäden (z.B. gebrannte Transistoren) können nicht repariert werden
• Kettenschaden-Effekt: Ein überhitzter Chip kann umliegende Komponenten beschädigen

3. Wärme & Effizienz Herausforderungen

• Overclocking kann die Wärmeerzeugung dramatisch erhöhen – potentiell um 50% oder mehr
• Power Consumption erhöht sich (gemessen in Watts): Dies ist nicht linear. Eine 10% Frequenzerhöhung + Spannungserhöhung könnte zu 20–30% mehr Stromverbrauch führen
• Effizienz sinkt (gemessen in J/TH – Joules pro Terahash): Wenn ihr 40% mehr Strom für 15% mehr Hashrate braucht, wurde eure Effizienz durch OC unverhältnismässig verschlechtert
• Lebensdauer der Hardware kann drastisch sinken (halbe Lebensdauer ist nicht selten bei aggressivem OC)

4. Kühlung ist existentiell

• Ihr solltet eine ausreichende Kühlung haben, bevor ihr OC versucht:
  • Niedrige Umgebungstemperaturen (idealerweise < 25°C)
  • optimierter Airflow, guter Lüfter
  • Hochwertige Heatsinks oder sogar Flüssigkeitskühlung für extreme OC
• Überhitzung ist der schnellste Weg zum Versagen. Ein überheizter Chip wird zum "Brick".

5. Garantieverlust

Overclocking führt zum Garantieverlust eures Gerätes. Wenn er durchbrennt, wars das. Es gibt sicherlich keinen Ersatz vom Verkäufer!

Wenn ihr die Risiken akzeptiert: Die methodische OC-Prozedur

Voraussetzungen

Bevor ihr ein einziges MHz erhöht, überprüft diese Bedingungen:

1. Baseline Stabilität

• Euer Miner läuft 100% stabil mit den aktuellen Einstellungen
• Keine unerklärten Fehler oder spontanen Reboots über Stunden hinweg
• Alle Chips senden konsistent gültige Shares und die erwartete Hashrate wird auch tatsächlich erreicht

2. Temperatur im grünen Bereich

• ASIC Core Temp liegt stabil bei ~60°C oder eurem eingestelltem Target
• VRM (Voltage Regulator) liegt unter ~70°C
• Der Lüfter dreht bei 50% seiner maximalen Drehzahl im automatischen Modus
• Diese "Sicherheitsmargen" geben euch Platz für die Wärmesteigerung durch OC

3. Stromversorgung mit Headroom

• Euer Netzteil hat 30% Kopfraum über dem aktuellen Stromverbrauch
  • Beispiel: Wenn euer Miner aktuell 75W zieht, sollte euer Netzteil mind. 110W haben
  • Grund: Netzteile die am Limit arbeiten PSUs werden instabil, liefern niedrigere Spannung, können ausfallen
• Überprüft die PSU-Kabelqualität (keine beschädigten, frayed oder überheizten Kabel)

Eine Bitaxe mit aussreichender Kühlung und genügend Spielraum:

Die Temperatur liegt bei 60°, der Lüfter ist erst bei 42%

Overclocking Schritt für Schritt durchführen

Schritt 1: Kleine Frequenzerhöhung

Erhöht die Frequenz für der Chips um +10 MHz (z.B. von 550 auf 560MHz).

Warum +10 MHz?

• Groß genug, um messbar zu sein (nicht in dem Rauschen der Mess-Variabilität)
• Klein genug, um bei Instabilität schnell zu erkennen
• Standard in der Mining-Community

Schritt 2: Speichern & Neustart

In neueren Version von AxeOS und NerdQ OS muss das Gerät nicht neugestartet werden.

Schritt 3: Kritisches Monitoring (15–30+ Minuten)

Das ist der wichtigste Schritt. Geht ins Dashboard und beobachtet intensiv:

3a) Stabilität & Submissions

• Sind alle Shares gültig? Keine neuen "Invalid Shares" oder "HW Errors"?
• Ist die beobachtete Hashrate nahe der erwarteten Hashrate für die neue Frequenz?
  • Die Firmware des Miners oder der Pool sollte euch die erwartete Rate für 560MHz anzeigen
  • Wenn eure beobachtete Hashrate sinkt oder unter der Erwartung liegt, ist das ein Zeichen, dass zu wenig Spannung am Chip anliegt
• Konsistenz: Ist die Hashrate stabil oder "flattert" sie?

3b) Temperatur-Überwachung

• Temperatur-Steigerung: Wieviel ist die Drehzahl des Lüfters, oder die Temperatur des ASICS und der VRMs durch die +10MHz Frequenzerhöhung gestiegen?

3c) Hardware Errors & Log-Überwachung

• Tauchen neue Fehler auf? Spezifisch:
  • nonce_range_err – kann auf Timing Violations hindeuten
  • device_hw_errors – Chip-Fehler
  • shares_stale – seltener, aber kann auf "zu lange Berechnung" hinweisen

Wo beobachten:

• Miner Web-Interface (Live Hashrate, Temperature, Error Counter)
• Pool Dashboard: Ist die Accepted vs. Rejected Rate stabil?

Das Dashboard zeigt eine stabile Temperatur, der Lüfter ist nicht ausgereizt, die VRMs bleiben schön kühl.

Schritt 4: Stabil? Wiederholt die Frequenzerhöhung

Falls alles ok ist nach 30 Minuten Monitoring:

1. Erhöht die Frequenz um weitere +10 MHz (z.B. 560 → 570MHz)
2. Speichert oder Startet neu bei älteren Versionen
3. Geht zurück zu Schritt 3 – monitort erneut

Typisches OC-Szenario:

550MHz (Baseline, stabil) 
→ 560MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 570MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 580MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 590MHz (+10) - stabil, +1°C, 0 Fehler, Temperatur OK ✓
→ 600MHz (+10) - stabil, +2°C, 0 Fehler, Temperatur OK ✓
→ a) 610MHz (+10) - instabil (Fehler oder Hashrate sinkt), Temperatur OK, x
→ b) 610MHz (+10) - stabil, Temperatur zu hoch, x

a) ihr müsst die ASIC Spannung um 10mv erhöhen und nochmals testen
b) ihr müsst für eine bessere Kühlung sorgen

Schritt 5: Instabilität erkennen und beheben

Wenn ihr nach 30 Minuten bei der neuen Frequenz Fehler oder niedriger Hashrate seht:

Diagnose:

• Die aktuelle Frequenz ist an der Grenze der Stabilität der Spannung
• ihr benötigt mehr Spannung, um diese Frequenz stabil zu halten
• ihr benötigt eine bessere Kühlung

Maßnahme: Core Voltage erhöhen

1. Erhöhe die Core Voltage um +10mV (z.B. 1150 → 1160mV) für die instabilen Chips
2. Speichern & Neustart
3. Monitort erneut (mindestens 30 Minuten)
4. Sehr wichtig: Monitor die Temperatur intensiv!
   • Eine Spannungserhöhung erzeugt disproportional mehr Wärme
   • Beispiel: +10mV könnte +3–4°C an Temperatur hinzufügen

Szenario-Beispiel:

Versuch: 610MHz @ 1150mV
→ Nach 10min: 50 Invalid Shares, Hashrate sinkt

Lösung: 610MHz @ 1160mV (Spannung +10mv)
→ Nach 30min: 0 Fehler, aber Temp ist von 60°C auf 65°C gestiegen ✓
→ Akzeptabel! Speichern.

Nächster Versuch: 620MHz @ 1160mV
→ Nach 15min: Neue Fehler, 645 Invalid Shares
→ Wieder Spannung erhöhen? Vielleicht nicht. Temp ist bereits bei 65°C.
→ Lieber bei 610MHz @ 1160mV stoppen.

In meinem Falle ist aufgrund der besseren Kühlung das Gerät immer noch bei 60°, aber der Lüfter dreht schon deutlich schneller bei 54%

Schritt 6: Überhitzung erkannt? (Stop!)

Wenn während eines Versuches die Temperaturen in den gefährlichen Bereich schießen:

Sichere Schwellenwerte (harte Limiten):

• ASIC Core Temp > 70°C: Gefährliche Zone. Der Chip kann sich automatisch abschalten.
• VRM Temp > 85°C: Kritisch. Mehr Airflow ist notwendig

Wenn ihr dies seht: sofort stoppen!

Maßnahme: Rollback

1. Revertiert die letzte Frequenz- oder Spannungserhöhung, die diese Temperaturen ausgelöst hat
   • Wenn die Temp bei 620MHz zu hoch wurde, gehe zurück auf 610MHz
   • Oder wenn die Temp bei 1170mV stieg, geht zurück auf 1160mV
2. Speichert & Startet erneut, verifiziert, dass Temps zurück zu sicheren Werten gehen
3. Danach: Um weiter zu gehen, benötigt ihr Kühlungs-Upgrades:
   • Bessere/stärkere Ventilatoren
   • Niedrigere Umgebungstemperatur
   • Flüssigkeitskühlung (für extreme OC)
   • Bessere Airflow-Umgebung

Warnung: Das Ignorieren von Temperaturwarnungen ist der sicherste Weg zu permanenten Hardware-Schäden oder Bränden. Respektiert die Grenzen.

Schritt 7: Die OC-Grenze finden

Wiederholt diese Zyklen (Freq erhöhen → Monitoren → Falls instabil, Spannung erhöhen → Monitoren temps):

Ihr stoppt, wenn eine der folgenden Bedingungen erfüllt ist:

1. Ihr hast dein Ziel-Performance-Level erreicht
   • Z.B. wolltet ihr 20% mehr Hashrate, und ihr habt sie erreicht bei akzeptablen Temps & Spannungen ✓
2. Instabilität lässt sich nicht mit mehr Spannung beheben
   • Z.B. bei 700MHz @ 1200mV ist immer noch instabil bei 700MHz @ 1250mV
   • Das bedeutet: Die Hardware kann diese Frequenz physikalisch nicht stabil halten (selbst mit höherer Spannung)
   • Das ist die Hardware-Grenze
3. Thermische Grenzen erreicht
   • ASIC Temps sind konsistent > 70°C
   • VRM Temps nähern sich 85°C
   • Weitere Erhöhungen würden zu Shutdowns oder Schäden führen

Die "ideale" OC-Zone:

• Frequenz-Gewinn: +10–15% über Baseline (z.B. 550 → 610MHz) ist "konservativ"
• Spannungs-Erhöhung: +20–30mV über Baseline ist "moderat"
• Temperatur-Erhöhung: +15°C über Baseline wird noch akzeptiert
• Alles darüber: Aggressives OC mit hohem Risiko

Die perfekte OC-Einstellung finden: Ein vollständiges Beispiel

Angenommen, eure Baseline ist:

Frequency: 550MHz
Core Voltage: 1150mV
Temp: 60°C
Hashrate: 1070 GH/s (100%)
Power Draw: 18
Efficiency: 16.0 J/TH
Standard Kühlblock und Lüfter

OC-Versuch Gerät Nummer 1 mit Standard Kühler, schlechter ASIC Chip:

Fazit: Optimales OC-Fenster liegt bei 590 MHz @ 1160 mV

Warum Schritt 3 statt Schritt 5?

Während Schritt 5 (630 MHz @ 1170 mV) die höchste Hashrate von 1300 GH/s erreicht, ist dies nicht das beste Gesamtpaket:

• Stabilität: Schritt 3 ist vollständig stabil (0 Fehler), Schritt 5 ist nur Borderline
• Temperatur: 63°C vs. 68°C – noch im grünen Bereich
• Effizienz: 17.0 J/TH ist deutlich besser als 19.0 J/TH bei Schritt 5
• Hashrate-Gewinn: +6,4% gegenüber Schritt 1 (1100 → 1170 GH/s)
• Stromeffizienz: +2W mehr Verbrauch, aber stabiles System

Schritt 5 als risikobereite Alternative:

• +18,2% Hashrate (1300 GH/s)
• Aber: Borderline-Status, höhere Temps, schlechtere Effizienz
• Nur für aggressive Mining-Szenarien ohne Langzeitstabilität gefordert

OC Versuch Gerät Nummer 2 mit The Bitchin' Sink Kühler und dem Gelid Black Magic und zusätzlichen Effizienz Tuning

Fazit: OC-Versuch Gerät Nummer 2 – Optimales Fenster bei 640 MHz @ 1130 mV

Dieser Versuch zeigt deutlich bessere Ergebnisse als der erste. Mit dem The Bitcoins Sink Kühler und dem Gelid Black Magic Lüfter erreichen wir maximale Performance bei minimaler Spannung.

Optimaler Betriebspunkt: Schritt 8 / Schritt 10 (identisch)

• Hashrate: 1.31 TH/s (+22,4% vs. Baseline)
• Spannung: 1130 mV (deutlich niedriger als Schritt 6!)
• Temperatur: 60°C (sehr kühl)
• Stromverbrauch: 19.5W (sehr effizient)
• Effizienz: 18.5 J/TH
• Status: ✓ OK (vollständig stabil)

Warum besser als Schritt 6? Beide erreichen 1.31 TH/s, aber:

• Schritt 6: 1150mV, 23W, 20.0 J/TH
• Schritt 8/10: 1130mV, 19.5W, 18.5 J/TH

Mit 20mV weniger Spannung spart ihr 3.5W Stromverbrauch und verbessert die Effizienz um 7,5%. Das ist die perfekte Kurve für Langzeitbetrieb.

Grenzbereich erkannt: Schritt 9 (1120mV) zeigt Instabilität – 1130mV ist die sichere Untergrenze.

Fazit: Der bessere Kühler ermöglicht deutlich aggressiveres Tuning mit gleichzeitig besserer Effizienz. Das ist ein sehr sauberes Ergebnis.

Die Realität der OC-Risiken

1. Die Risiken sind real:
   • Potentielle Belohnung (höhere Hashrate) kommt mit erheblichen Risiken
   • Permanente Hardware-Schäden möglich
   • Brandgefahr durch Überhitzung
   • Herstellergarantie oft ungültig nach OC
2. Effizienz ist King:
   • Höhere Frequenz und Spannung erhöhen den Stromverbrauch drastisch
   • Berechnet: Kostet mich der Extra-Strom mehr als die Extra-Bitcoin-Hashrate wert ist?
   • Beispiel: +30% Strom für +10% Hashrate = schlechtes Geschäft
3. Stromqualität ist entscheidend:
   • In Regionen mit instabilen Stromnetzen (Brownouts, Spitzen, Solar/Wind-Fluktuationen) NICHT ÜBERTAKTEN
   • Instabile Stromversorgung während OC ist ein Sicherheitsrisiko
   • Investiere in hochwertige Stromversorgungen (Modularität, Überlastschutz, bessere Netzteile)
4. Umgebungsfaktoren:
   • In heißem Klima (>30°C Umgebungstemperatur): Sehr konservativ mit OC
   • In kaltem Klima (<15°C): Mehr Spielraum für OC
   • Raumluftqualität (Staub, Verschmutzung) wirkt sich auf Kühlung aus

Best Practices für sichere OC

✅ DO:

• Startet mit sehr kleinen Inkrementierungen (+5 MHz / +5mV wenn ihr sehr vorsichtig sein möchtet)
• Monitort obsessiv – mehrere Stunden lang, nicht nur 30 Minuten
• Setzt neue Einstellungen nicht über die Nacht, sondern eher am Tag wenn ihr das Gerät überwachen könnt
• Dokumentiert alles (Einstellungen, Temperatures, Fehlerate, Hashrate) für zukünftige Referenz
• Prioritäre Stabilität > Performance
• Haltet Backups eurer aktuellen stabilen Konfiguration

❌ DON'T:

• Vertraut nicht auf "Online-OC-Rechner" – das beste OC für euren Miner müsst ihr empirisch finden
• Erhöht nicht Freq UND Volt gleichzeitig – ihr wisst nicht, was was verursacht hat
• Ignoriert Temperaturwarnungen
• Verzweiflet nicht bei Fehlern – sie sind normal bei der OC-Grenze

Teil 2: Undervolting - Effizienz steigern und Lautstärke reduzieren

Was ist Undervolting

Während Overclocking die Hashrate maximiert, reduziert Undervolting die Spannung, um den Stromverbrauch zu senken. Das Beste: Undervolting ist sicher - es kann die Hardware nicht beschädigen. Treten Fehler auf oder sinkt die Hashrate zu stark, könnt ihr problemlos zur vorherigen Einstellung zurückkehren.

Warum Undervolting?

• Deutlich geringerer Stromverbrauch (10-20%)
• Niedrigere Temperaturen (5-15°C)
• Leiser Betrieb (niedrigere Lüftergeschwindigkeit)
• Längere Hardware-Lebensdauer als Bonus

Der Physik-Trick: Die Leistungsaufnahme steigt quadratisch mit der Spannung: P ≈ V² × f

• -10% Voltage = ca. -19% Stromverbrauch
• -15% Voltage = ca. -28% Stromverbrauch

Beispiel: BitAxe Undervolting

Ausgangssituation:

• Frequenz: 550 MHz
• Voltage: 1.15V (1150mV)
• Verbrauch: 18.7W
• Temperatur: 60°C
• Lüfter: 42%

Ziel:

• Verbrauch reduzieren
• Temperaturen senken
• Lüfter leiser bekommen

Der Undervolting-Prozess (Schritt für Schritt)

Schritt 1: Baseline dokumentieren

Notiert die aktuellen Werte:

• Voltage: 1150mV
• Frequency: 550 MHz
• Hashrate: z.B. 1070 GH/s (je nach Chip)
• Stromverbrauch: 18.7W
• Temperatur: 64-68°C
• Lüfter: 100%

Schritt 2: Erste Voltage-Reduktion

Konservativer Start: -25mV

• Neue Einstellung: 1100mV (1.10V)
• Frequenz bleibt bei 550 MHz
• Speichern und Neustart

Alternative - Aggressiver: -50 bis -75mV

• Bei BitAxe mit schlechter Kühlung oft möglich
• Neue Einstellung: 1100mV oder 1075mV

Schritt 3: Monitoring (30-60 Minuten)

Was prüfen:

• ✅ Läuft der Chip stabil? (keine Abstürze)
• ✅ Hashrate im erwarteten Bereich? (±2-3% ist okay)
• ✅ Temperatur gesunken? (sollte 3-8°C niedriger sein)
• ✅ Lüfter langsamer/leiser? (sollte automatisch runterregeln bei niedrigerer Temp)

Erfolgs-Indikatoren:

• Chip läuft ohne Fehler
• Hashrate nur minimal reduziert (0-5%)
• Temperatur deutlich niedriger (60°C oder weniger)
• Lüfter läuft bei 70-85% statt 100%
• Stromverbrauch: 14-16W statt 18W

Warnsignale:

• Häufige Hardware-Errors
• Hashrate bricht um >10% ein
• Chip wird instabil oder resettet

Schritt 4: Weiter optimieren (optional)

Wenn Schritt 2 erfolgreich war, könnt ihr weitermachen:

Nächster Schritt: weitere -10mv reduzieren

• Beispiel: Von 1100mV auf 1090mV
• Wieder 30Min testen

Typische BitAxe Sweet Spots:

• Konservativ: 1100mV (-50mV): ~16W, 62°C, Lüfter 85%
• Balanced: 1100-1050mV (-50 bis -100mV): ~14-15W, 58-60°C, Lüfter 70-80%
• Aggressiv: 1050-1030mV (-150 bis -170mV): ~12-13W, 55°C, Lüfter 60-70%
  • Achtung: Kann zu instabil sein, Hashrate-Verlust 5-10%

Schritt 5: Finales Testing

Nach 24 Stunden Laufzeit:

• Ist der Betrieb stabil geblieben?
• Keine ungewöhnlichen Fehler?
• Temperaturen konstant?

Falls instabil: Voltage um +10-20mV erhöhen

Die Bitaxe mit den neuen Settings:

Frequency + Voltage Co-Tuning

Für maximale Effizienz könnt ihr beides anpassen:

Beispiel:

• Voltage: 1025mV (-125mV)
• Frequency: 525 MHz (-25 MHz)

Ergebnis:

• Verbrauch: ~14W (-33%)
• Temperatur: ~52-55°C
• Lüfter: 30% (sehr leise!)
• Hashrate: ~1070 GH/s (-11%)

Wann sinnvoll:

• Lautstärke ist Hauptproblem
• Kühlung ist limitierend
• Hobby-Mining, Hashrate zweitrangig

Troubleshooting

Problem: Chip wird instabil → Voltage um +20mV erhöhen

Problem: Hashrate bricht stark ein (>10%) → Zu aggressives Undervolting, +10-20mV zurück

Problem: Temperatur sinkt kaum → Wärmeleitpaste prüfen, Kühler reinigen, mehr Voltage-Reduktion

Problem: Lüfter läuft weiter bei 100% → Lüfter-Steuerung prüfen

Wichtige Hinweise

✅ Sicher:

• Undervolting beschädigt Hardware nicht
• Jederzeit rückgängig machbar
• Keine langfristigen Risiken

✅ Vorteile:

• Deutlich leiser (Hauptziel bei BitAxe!)
• Weniger Stromkosten
• Kühlerer Betrieb
• Längere Lebensdauer

⚠️ Beachten:

• Jeder Chip ist anders (Silizium-Lotterie)
• Testet in kleinen Schritten
• 24h-Test für finale Settings
• Bei Instabilität einfach zurück zur vorherigen Einstellung

Teil 3: Beheben von niedriger Hashrate & Instabilität (Tuning Up)

Diagnose: Wo liegt das Problem

Wenn euer Miner Dashboard konsistent niedrige Hash-Submissions ("Invalid Shares", "Summit-Fehler") von spezifischen Chips oder dem gesamten Gerät zeigt, oder die Hashrate deutlich unter den Spezifikationen liegt:

Mögliche Ursachen:

1. Unzureichende Spannung für die aktuelle Frequenz (häufigste Ursache)
2. Schlechte thermische Anbindung (Chip überhitzt lokal)
3. Fehlerhafte Chip/Hashboard
4. Instabile Stromversorgung
5. Firmware-Bug oder falsche Pool-Konfiguration

Ziel dieses Teils

Finde die minimale stabile Spannung, die alle Fehler eliminiert und die erwartete Hashrate bei der aktuellen Frequenz wiederherstellt. Dies optimiert die Energieeffizienz (J/TH) und redzuiert die Fehlerrate.

Der sichere Tuning-Prozess

Schritt 1: Diagnose & Identifikation

Nutzt eurer Miner-Management-Interface (AxeOS, Braiins OS+, StockOS, etc.) um zu überprüfen:

• Expected Hashrate: Stimmt die Tatsächliche Hashrate mit der Exptected Hashrate überein?
• Submission Rate: Wie viele gültige Shares sendet jeder Chip?

Schritt 2: Baseline dokumentieren

Notiert die aktuellen Einstellungen für alle Chips oder Problem-Chips:

• Core Voltage: z.B. 1150mV
• Frequency: z.B. 550MHz
• Aktuelle Hashrate: Notiere die beobachtete Rate
• Fehler-Rate: z.B. 10% Invalid Shares
• Niedrigere Hashrate als die Exptected Hashrate

Schritt 3: Kleine Spannungserhöhung

Erhöht die Core Voltage für die problematischen Chips um +5mV (z.B. von 1150mV auf 1155mV).

Schritt 4: Speichern & Neustart

• Speichert die neuen Einstellungen im Miner-OS
• Führt einen vollständigen Neustart durch
  • Dies stellt sicher, dass alle Komponenten mit den neuen Parametern initialisiert werden
  • Verhindert Fehler durch Cache oder teilweise geladene Konfigurationen

Schritt 5: Intensives Monitoring (15-30+ Minuten)

Beobachtet folgende Metriken sehr genau:

5a) Submission Rate & Hashrate

• Haben die Fehlerquoten ("Invalid Shares", "HW Errors") abgenommen?
• Ist die beobachtete Hashrate jetzt näher an der erwarteten Hashrate für diese Frequenz?
• Beispiel: Bei 625MHz solltet ihr die gleiche Hashrate sehen wie zuvor, nur ohne Fehler

5b) Temperatur

• Sind die ASIC-Core-Temperaturen angestiegen? (Ja, aber wie viel?)
• Erwartungswert: +1–3°C pro +10mV Spannungserhöhung ist typisch
• Überwachung kritischer Schwellenwerte:
  • ASIC Temp nicht über 70
  • VRMs (Voltage Regulators) < 95°C

5c) Hardware Errors

• Erscheinen neue oder verschiedene Fehlertexte im Log?
• nonce_range_err: Könnte auf Stromprobleme hindeuten

Wo man nach Logs sucht:

• AxeOS: Web-Interface > Logs > Download Full Log oder im Dashboard
• NerdQ OS: Miner > Log Viewer im Web-Interface

Schritt 6: Iterieren (falls nötig)

Wenn die Fehlerquoten nach 30 Minuten Monitoring immer noch hoch sind:

1. Wiederhole Schritt 3: Erhöhe die Spannung um weitere +10mV (z.B. 1160 → 1170mV)
2. Führe Schritte 4 & 5 erneut durch
3. Wichtig: Gehe schrittweise vor! Nicht in 50mV-Sprüngen erhöhen.

Typische Progression bei Problemen:

1150mV → 50% Fehler → 1160mV → 20% Fehler → 1170mV → 5% Fehler → 1180mV → 0% Fehler ✓

Schritt 7: Diagnose eines Defekts

Wenn ihr nach mehreren Inkrementierungen (z.B. bis 1200–1200mV) immer noch keine Verbesserung siehst, liegt das Problem wahrscheinlich nicht an der Spannung oder der Chip ist wirklich kein Silikon Lottery Win:

Mögliche Probleme:

1. Defekter Chip/Board: Das Hashboard könnte physikalisch beschädigt sein
2. Schlechte Wärmeableitung: Wärmepaste ist trocken oder wurde falsch aufgetragen
3. Schlechte Stromversorgung zu diesem Board: Beschädigtes Stromleitungskabel oder Stecker
4. Firmware-Bug: Seltener, aber möglich
5. ASIC Binning: sehr schlechte ASIC Qualität

Diagnose-Schritte:

• Extrahiert die vollständigen Logs und teilt sie mit der Community
• Wenn thermisch: Überprüft die Wärmepaste-Konsistenz und Aufpressdruck
• Im Extremfall: Wechsel das Board oder den Chip aus, oder sendet das Gerät zurück wo ihr es gekauft habt

Fazit

Nutzt dieses Wissen weise. Beginnt klein, überwacht obsessiv, priorisiert Stabilität und Kühlung, und respektiert immer die Grenzen der Hardware. Glücklich (und sicheres) Mining! ⛏️

Bei der praktischen Umsetzung zeigt sich häufig: Ein OC lässt sich in den meisten Fällen rückgängig machen und die Hardware wird wieder normal, solange keine Überhitzung stattgefunden hat. Wenn die Hardware nicht physikalisch beschädigt wurde, könnt ihr zu den Werkseinstellungen zurückkehren – allerdings sind thermische oder elektrische Schäden oft permanent.

Ein wichtiger Punkt: Unterschiedliche Chip-Generationen (BM1368, BM1370, etc.) sollten praktisch nicht mit denselben Einstellungen getuned werden. Während es theoretisch möglich ist, haben unterschiedliche Generationen unterschiedliche Optimalpunkte. Nutzt separate Einstellungen pro Generation, wenn möglich.

Im Shop verkaufen wir Geräte, welche in der PowerSave Edition auf maximale Effizienz, und in der Special beziehungsweise Black Edition auf Leistungsfähigkeit bei angepasster Chipspannung und Chipfrequenz optimiert worden sind, ohne dass ihr die Garantie verliert. Schaut mal vorbei!

The post Tuning & Overclocking Guide für Bitaxe und NerdQ Miner appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Hier gibt es an der Wallet auch Kritikpunkte – insbesondere hinsichtlich der Verwahrung der privaten Schlüssel, der Zentralisierung und der hohen Gebühren für den Empfang von Zahlungen. In diesem Bericht gehen wir detailliert auf die Funktionsweise, Sicherheit, Gebührenstruktur und Alternativen ein, um eine umfassende Einschätzung der Wallet of Satoshi zu geben.

Was ist die Wallet of Satoshi

Die Wallet of Satoshi ist eine mobile App, die für iOS und Android verfügbar ist. Sie ermöglicht es, Bitcoin über das Lightning Network zu senden und zu empfangen, ohne sich um technische Details wie Kanäle, Liquidität oder Routing kümmern zu müssen. Die Wallet ist custodial, was bedeutet, dass der Anbieter die privaten Schlüssel für den Nutzer verwaltet.

Hauptmerkmale der Wallet of Satoshi

• Extrem einfache Bedienung: Perfekt für Anfänger, da kein technisches Wissen erforderlich ist.
• Lightning- und On-Chain-Zahlungen: Unterstützt sowohl das Lightning Network als auch klassische Bitcoin-Transaktionen.
• Sofortige Nutzung ohne Backup: Kein Seed-Wiederherstellungssatz oder komplizierte Einrichtung notwendig.
• Bezahlen per QR-Code und LNURL: Einfacher Empfang und Versand von Zahlungen.
• Fiat-Kaufmöglichkeit: Nutzer können Bitcoin direkt per Kreditkarte oder Banküberweisung erwerben.
• Gute Integration mit Lightning-fähigen Diensten: Unterstützt Lightning-Zahlungen für Spenden, Trinkgelder oder E-Commerce.
• Zentralisierte Verwahrung der Coins: Die Wallet ist custodial – Nutzer haben keinen Zugriff auf ihre privaten Schlüssel.
• Sehr sehr hohe Onchaingebühren - Achtung, das versenden von Onchain Sats ist mit der WalletofSatoshi sehr teuer, die Grundgebühr beträgt 1%, dazu kommt beim versenden noch ein Fixbetrag dazu.

Custodial vs. Non-Custodial – Was bedeutet das

Ein wesentlicher Aspekt der Wallet of Satoshi ist, dass es sich um eine custodial Wallet handelt. Das bedeutet, dass der Anbieter die privaten Schlüssel verwahrt und nicht der Nutzer selbst.

Vorteile von Custodial Wallets

• Kein Risiko, den Seed zu verlieren: Da der Anbieter die Schlüssel speichert, kann ein Nutzer seine Wallet nicht durch den Verlust einer Seed-Phrase verlieren.
• Einfachste Nutzung: Die Wallet funktioniert direkt nach der Installation, ohne dass der Nutzer Kanäle verwalten oder eine Back-up-Strategie entwickeln muss.
• Kein technisches Wissen erforderlich: Im Gegensatz zu Non-Custodial Wallets muss sich der Nutzer nicht um das Routing oder die Verwaltung von Liquidität kümmern.

Nachteile und Risiken von Custodial Wallets

• Kein Zugriff auf Private Keys: „Not your keys, not your coins“ – wer die privaten Schlüssel nicht selbst besitzt, hat keine vollständige Kontrolle über seine Bitcoin.
• Zensur-Risiko: Der Anbieter kann Transaktionen blockieren oder Konten sperren.
• Regulatorische Abhängigkeit: Da WoS eine zentrale Plattform ist, könnte sie durch regulatorische Vorgaben gezwungen werden, KYC-Daten zu verlangen oder Nutzern aus bestimmten Ländern den Zugang zu verweigern.
• Anfällig für Hacks oder Geschäftsaufgabe: Sollte der Betreiber gehackt werden oder insolvent gehen, könnten alle Coins der Nutzer verloren sein.

Alternative: Non-Custodial Lightning Wallets

Für Nutzer, die volle Kontrolle über ihre Coins behalten möchten, gibt es Non-Custodial Alternativen, wie z. B.:

• Phoenix Wallet – Perfekte Mischung aus Benutzerfreundlichkeit und Selbstverwaltung.
• Zeus Wallet – Für Node-Betreiber mit Fokus auf maximale Kontrolle.
• Breez Wallet – Guter Kompromiss zwischen Einfachheit und Dezentralität.

Gebühren und Kosten

Ein positiver Aspekt der Wallet of Satoshi ist, dass sie keine eigenen Gebühren für das Senden oder Empfangen von Lightning-Zahlungen erhebt. Es fallen lediglich die üblichen Routing-Gebühren des Lightning-Netzwerks an, die jedoch von den beteiligten Nodes und nicht von Wallet of Satoshi selbst erhoben werden.

Gebührenstruktur

💡 Zusammenfassung: Für Lightning-Transaktionen ist Wallet of Satoshi gebührenfrei, allerdings können bei On-Chain-Transaktionen und Fiat-Käufen Gebühren durch externe Anbieter entstehen.

Benutzerfreundlichkeit & Features

Die Wallet of Satoshi bietet eine der intuitivsten und einfachsten Benutzeroberflächen, die es im Bitcoin-Space gibt.

Positives

• Einfache Installation & sofortige Nutzung ohne Anemeldung
• Übersichtliches Design, verständlich für Einsteiger
• Gute Integration von Lightning & QR-Code-Zahlungen
• Kein Backup oder technisches Setup notwendig
• Email Adresse reicht, um euren Account wiederherzustellen

Negatives

• Kein Zugriff auf eigene Private Keys
• Nur eingeschränkte Funktionen für fortgeschrittene Nutzer
• Keine Möglichkeit, Lightning-Kanäle selbst zu verwalten
• Sehr hohe Onchain Gebühren!!

Anwendung der Wallet of Satoshi

Die Anwendung der Wallet of Satoshi ist komplett simple. Ihr braucht euch nicht einmal irgendwo anmelden. Es muss kein Push Dienst wie bei Phoenix laufen, die Wallet funktioniert also auf Phones ohne G-Play und ihr bekommt eine zufällig generierte Lightning Adresse zugewiesen.

Empfangen von Sats Onchain und Offchain

Lightning Sats empfangen

Das Empfangen geht relativ einfach. Ihr geht links unten auf den Button Empfangen, wählt dann Betrag / Notiz aus, und erstellt hier eine Rechnung/Invoice über einen Betrag den ihr festlegt. Ausserdem könnt ihr dem Empfänger eine Rechnungsnotiz hinterlassen, damit er weiss, wofür die Invoice ist. Diese Invoice sendet ihr dann einfach an den Empfänger. Dieser scannt die Invoice mit seiner App, und begleicht somit die Rechnung. Ihr erhaltet die Sats direkt auf eure Wallet.

Eigene Lightning Adresse

Unter der Option erhaltet ihr auch eine automatisch generierte Lightning Adresse. Anstatt eine Invoice zu kreieren, könnt ihr diese Adresse auch an euren Partner schicken. Mit einer LNURL kompatiblen Wallet, kann euer Gegenüber dann einfach Sats an diese Adresse schicken. Hier muss vorher kein Betrag festgelegt werden!

Onchain Sats empfangen

Wollt ihr Onchain Sats empfangen, dann klickt ihr einfach auf das Bitcoin Symbol, und ihr erhaltet eine BTC Adresse, die ihr eurem Partner schicken könnt.

Achtung, vom Betrag den ihr erhaltet, werden euch 1% Gebühren abgezogen!

Versenden von Sats Onchain und Offchain

Das Versenden von Sats ist quasi noch einfacher. Ihr geht wieder auf den Main Screen, und wählt einfach unten Senden. Nun könnt ihr mit dem QR Scanner einen QR Code abscannen. Ausserdem habt ihr mit den Buttons unten die Möglichkeit die Adresse manuell einzugeben, aus der Zwischenablagen einzufügen, oder aus einem Screenshot zu entnehmen.

Die App erkennt automatisch ob es sich um eine Onchain Adresse, oder eine Lightning Invoice handelt.

Onchain Sats zu erhalten kostet bei der WalletofSatoshi relativ viel, euch werden 1% plus ein fixer Betrag in Sats abgezogen. Achtet also auf die Gebühren! Das kann bei grösseren Beträgen schnell sehr teuer werden!

Handelt es sich um eine Lightning Invoice, so wird euch der zu bezahlende Betrag anzeigt, und auch eine Beschreibung, für was ihr da bezahlt. Mit senden gebt ihr die Invoice frei, und der Betrag wird dem Empfänger praktisch sofort zugestellt.

Einstellungen und weitere Optionen der Wallet of Satoshi

Ihr habt die Möglichkeit, direkt über die WalletofSatoshi Bitcoin zu kaufen, oder zu Verkaufen. Das geht direkt über die Einstellungen. Allerdings sei hier gesagt, dass der Anbieteter MoonPay KYC verlangt, ihr euch also einen Account anlegen müsst, und eure Personaldaten hinterlegen müsst. Anti-KYC Nutzer werden hier also keine Freude haben.

Desweiteren könnt ihr in den Einstellungen die Sprache ändern, die Standardwährung festlegen, und auch Hädnler finden die BTC akzeptierten über die Opensource Map BTCMap. Unter Kontakte könnt ihr User hinzufügen, die eine Lightning Adresse besitzen.

In den erweiterten Einstellungen gibt es weniger interessantes zu sehen:

Ihr könnt den Betrag in BTC oder Sats anzeigen lassen, und auch festlegen dass euer PIN oder euer Fingerabdruck gefordert wird, wenn ihr Rechnungen bezahlt.

LNURL-Auth Login

Die Wallet hat auch die Möglichkeit, dass ihr euch über euren WalletofSatoshi Account auf Seiten mit LNURL-Auth Login einloggen könnt. Dazu geht ihr einfach auf den Senden Button, und scannt den LNURL-Auth QR Code ab, und ihr seid auf der jeweiligen Seite eingeloggt.

Ist die Wallet of Satoshi sicher

Die Sicherheit einer Wallet hängt davon ab, ob der Nutzer oder der Anbieter die Kontrolle über die Coins hat, Schlüssel wir also etwas auf, ob die Wallet sicher ist, oder nicht:

🔒 Technisch sicher: Die Wallet nutzt eine verschlüsselte Infrastruktur und Lightning-Zahlungen sind kryptografisch abgesichert.
❌ Nicht sicher aus Sicht der Verwahrung: Da es eine custodial Wallet ist, verliert der Nutzer seine Coins, falls der Anbieter gehackt wird oder den Dienst einstellt.
⚠ Kein Open-Source-Code: Im Gegensatz zu vielen anderen Bitcoin-Wallets ist WoS nicht Open Source, sodass der Code nicht unabhängig überprüft werden kann.

Wie lade ich Sats auf meine Wallet

Wie bereits erwähnt, verfügt die App über die Moon Integration die es euch erlaubt, Sats zu über die App zu kaufen und direkt auf die Wallet zu laden. Moon erfordert aber Full-KYC und hat dazu noch relativ hohe Gebühren von 2-3%. Wem das KYC nicht stört, kann deutlich günstiger an Börsen wie Binancen, Kraken, Bitpanda und Co für 0.01% kaufen, oder man nimmt Boltz als komplett KYC freie Option, oder Pocketbitcoin.com als Light-KYC Variante. Dazu haben wir einen eigenen Beitrag geschrieben. Schaut dazu am besten mal hier vorbei!

Sollte man Wallet of Satoshi nutzen

Das hängt von euren eigenen Präferenzen, und eurem Risiko-Management ab, hier dazu einige Gedanken:

Für wen ist Wallet of Satoshi geeignet

✅ Ideal für Einsteiger, die Lightning ausprobieren wollen.
✅ Geeignet für spontane Zahlungen, Trinkgelder und kleinere Beträge.
✅ Praktisch für temporäre Nutzung, aber keine langfristige Lösung, vor allem nicht für höhere Beträge.

Wer sollte Wallet of Satoshi meiden

❌ Nutzer, die ihre Coins selbst verwalten wollen („Not your keys, not your coins“).
❌ Personen, die eine langfristige und sichere Bitcoin-Lösung suchen.
❌ Nutzer die nur OpenSource Software verwenden wollen.

Empfohlene Alternativen

• Phoenix Wallet (Non-Custodial, einfach, geringe Gebühren)
• Zeus Wallet (Für erfahrene Nutzer mit eigener Lightning Node oder Non-Custodial mit einer embedded LND Node in der App)
• Breez Wallet (Guter Mittelweg zwischen Einfachheit & Kontrolle)
• Bitbanana: sehr gute Wallet um die eigene Node zu verwalten.

Zusammenfassung

Die Wallet of Satoshi ist eine gute Anfänger-Wallet, aber langfristig nicht empfehlenswert. Wer sich mit Bitcoin beschäftigt, sollte Non-Custodial Alternativen nutzen, um volle Kontrolle über seine Coins zu behalten. Ausserdem ist die Wallet nicht Opensource.

The post Lightning ohne Full Node mit der Wallet of Satoshi 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.

In diesem Beitrag stellen wir euch die verschiedenen LNURL-Funktionen genauer vor. Unser Ziel ist es, euch die vielseitigen Einsatzmöglichkeiten zu zeigen und euch zu inspirieren, wie ihr LNURL in eurem Alltag oder sogar in euren eigenen Projekten nutzen könnt.

Was kann LNURL?

Mit LNURL stehen euch praktische Funktionen zur Verfügung, die das Lightning-Erlebnis bereichern, darunter:

• LNURL-withdraw: Zahlungen empfangen, indem ihr Geld von einem Dienst abhebt.
• LNURL-auth: Einfaches Anmelden und Einloggen bei externen Diensten.
• LNURL-pay: Bezahlungen durchführen, ohne dass eine Rechnung erstellt werden muss.
• Lightning-Adresse: Zahlungen so einfach senden wie das Schreiben einer E-Mail.
• LNURL-Channel: Sich mit einem eingehenden Lightning-Channel verbinden.

Warum LNURL nutzen?

LNURL macht den Austausch zwischen Zahlern und Zahlungsempfängern unkomplizierter und intuitiver. Die Bedienung ist so einfach, dass man nur einen QR-Code scannen muss – vorausgesetzt, die eigene Wallet unterstützt LNURL.

Wie funktioniert LNURL?

Ein Dienstanbieter erstellt eine speziell formatierte Anfrage (bech32-codiert), die über einen QR-Code an den Nutzer übermittelt wird. Dieser QR-Code enthält alle notwendigen Informationen, damit eure Lightning-Wallet direkt mit dem Dienst kommunizieren kann. Einmal gescannt, wird die gewünschte Funktion ausgeführt – schnell, sicher und ohne technisches Fachwissen.

LNURL Withdraw

Um eine Lightning-Zahlung zu erhalten, erstellt der Zahlungsempfänger eine Rechnung (Invoice) mit Betrag und Verwendungszweck, die an den Zahler übermittelt wird. Mit LNURL kann dieser Prozess nutzerfreundlicher gestaltet werden, indem der Zahlungspflichtige selbst die Zahlungsanforderung initiiert.

Anwendungsfälle für LNURL Withdraw

• Abheben von Guthaben aus einer Wallet, z. B. zur Übertragung auf eine andere Wallet.
• Auszahlung von verdientem Guthaben, z. B. durch Aktivitäten oder Affiliate-Programme.
• Nutzung auf Börsen oder Gaming-Seiten.

Ihr scannt einen QR-Code mit einer LNURL-kompatiblen Wallet, und der Betrag wird direkt gutgeschrieben.

Beispiel: Pocketbitcoin.com

Pocket bietet LNURL Withdraw an, um gekaufte Sats über Lightning direkt auf eure Wallet zu übertragen. Einfach den QR-Code mit der Receive-Funktion scannen, und die Sats werden euch auf eure Lightning Wallet oder Node gutgeschrieben.

LNURL-Auth

Mit Hilfe von LNURL-Auth lassen sich Autorisierungen, Registrierungen oder Anmeldungen bei externen Diensten und Webseiten vornehmen. Der Vorteil für den Anwender ist es, dass keine persönlichen Informationen preisgegeben werden müssen. Bei satoshiskleinanzeigen.space kann man sich beispielsweise mit LNURL-Auth anmelden:

Man bekommt einen QR-Code angezeigt, den man mit einer Lightning wallet scannen kann, welche LNURL-Auth unterstützte wie zum Beispiel Breez und Phoenix oder Bitbanana und Zeus LN welche mit der eigenen Node verbunden sind.

Nachdem ihr den QR Code gescannt habt, seid ihr angemeldet und bekommt einen eindeutige User-ID angezeigt. Ihr müsst keinerlei persönliche Daten und email-Adressen hinterlegen.

Wenn man sich erneut auf seinem Account anmelden will, dann verwendet man die gleiche Lightning Wallet erneut und ist wieder eingeloggt als der selbe Benutzer. Als User identifiziert man sich ausschliesslich über seinen Public Key und sonst nichts. Kein Passwort, keine EMail-Adresse, kein Username oder etwas ähnliches.

Es findet auch keine Weiterleitung der Informationen zu anderen Webseiten statt. Ihr könnt bei jeder anderen Webseite, die LNURL-Auth verwendet, mit der gleichen Lightning Wallet ein Account aufmachen und euch darüber immer wieder einloggen.

LNURL Pay

Für eine Lightning-Zahlung erstellt der Empfänger eine individuelle Lightning Invoice, die dem Zahler alle nötigen Informationen zur Zahlung und Zuordnung bereitstellt. Da jede Zahlung einzigartig ist, können keine statischen QR-Codes verwendet werden.

Mit LNURL-Pay wird der Ablauf vereinfacht: Der Zahler initiiert die Zahlung, indem er den Empfänger auffordert, eine Rechnung zu erstellen. Der Zahler kann Betrag und Kommentar hinzufügen, bevor die Zahlung abgeschlossen wird.

Beispielanwendung: Die Donation Button vom BTCPay Server der euch einen QR Code generiert, der automatisch eine Invoice erstellt, in der höhe des von euch angegeben Betrags, oder ein Strassenkünstler stellt einen statischen QR-Code auf. Spender können den Code scannen, den Betrag in ihrer Lightning-Wallet festlegen und direkt spenden.

Lightning Adresse

Mit LNURL-Pay lassen sich Lightning-Zahlungen bequem an eine sogenannte Lightning-Adresse senden, die wie eine E-Mail-Adresse aussieht. Eine Lightning-Adresse (z. B. mario@btcpay.yourdevice.ch) wird in Lightning-Wallets, die LNURL-Pay unterstützen, wie eine Zahlungsadresse eingegeben. Die Wallet generiert automatisch eine Lightning Invoice, die an den Empfänger geschickt und von diesem verarbeitet wird.

So funktioniert's:

1. Gebt die Lightning-Adresse in eurer Wallet ein, wo sonst LNURLs hinterlegt werden.
2. Eure Wallet kommuniziert mit dem Server hinter der Lightning-Adresse, um eine Zahlungsanforderung zu generieren.
3. Bestätigt den Betrag und sendet die Zahlung.

Beispiel:

• Möchtet ihr es ausprobieren? Sende einen Sat an mario@btcpay.yourdevice.ch und erfahrt wie einfach es ist, Lightning Adressen zu verwenden.
• Nutzer der sats.mobi Telegram Wallet erhalten ebenfalls automatisch eine Lightning-Adresse in der Form tg-username@sats.mobi

Tipp: Viele moderne Lightning-Wallets unterstützen Lightning-Adressen, darunter Phoenix, Wallet of Satoshi, und Breez. Prüft eure Wallet auf diese Funktionalität, um Lightning-Zahlungen noch einfacher zu gestalten! Viele Wallets beherschen auch ein Kontaktbuch, mit der ihr eure Kontakte mit Lightning Adressen auch einfach ablegen könnt. Hier ein Beispiel der Bitbanana Wallet:

LNURL-Channel

LNURL-Channel dient dazu, den Prozess der Kanalöffnung durch einen anderen Node zu vereinfachen und zu automatisieren. Es ermöglicht, dass ein Node, der euch Liquidität zur Verfügung stellen möchte, eine Verbindung zu deinem Node herstellt und einen Kanal eröffnet, ohne dass du dies manuell anstoßen werden muss. Dies kommt meisst dann zur Anwendung, wenn ihr einen Kanal kauft, zum Beispiel bei einem LSP (Liquid Service Provider)

Wie funktioniert es?

1. Der Betreiber eines Nodes, der Kanäle anbietet (z. B. eben ein Service-Provider oder ein Freund), generiert einen LNURL-Channel QR-Code.
2. Ihr scannt diesen QR-Code mit eurer Lightning-Wallet, die LNURL-Channel unterstützt.
3. Eure Wallet sendet automatisch die nötigen Informationen an den anderen Node (wie zum Beispiel eure Node-ID).
4. Der andere Node eröffnet daraufhin einen Kanal zu euch und stellt euch die gewünschte Liquidität bereit.

Wann ist LNURL-Channel sinnvoll?

• Erleichterung für neue Nutzer: Neue Lightning-Nutzer können so unkompliziert einen ersten Kanal eröffnen lassen, ohne technische Details wie die Node-ID manuell einzugeben.
• Förderung von Lightning-Adoption: Anbieter, Börsen oder Services können LNURL-Channel anbieten, um Nutzern mit einem Klick Liquidität bereitzustellen.
• Automatisierung: Der Prozess spart Zeit und reduziert Fehler, da keine manuelle Interaktion mit der Node nötig ist.

Wichtiger Hinweis:
LNURL-Channel ist nicht zwingend notwendig für Nodes hinter Tor oder Firewalls, die bereits öffentlich erreichbar sind. Stattdessen zielt es darauf ab, den Prozess der Kanalöffnung für Nutzer einfacher, schneller und intuitiver zu gestalten.

Lightning Wallets mit LNURL Unterstützung

Folgende Lightning Wallets unterstützen LNURL bzw. Funktionen von LNURL

Quelle: https://coincharge.de

Wir versuchen, diese Liste aktuell zu halten. Gibt es neue Funktionen oder Lightning Wallets, die hier aufgeführt werden sollten? Teilt uns das gerne mit unter info@yourdevice.ch

Fazit

LNURL ist eine leistungsstarke Erweiterung des Lightning-Netzwerks, die den Alltag mit Lightning-Zahlungen erheblich erleichtert. Es bietet vielseitige Funktionen, um bisherige Einschränkungen zu überwinden und Nutzererlebnisse zu verbessern:

1. Nutzerfreundlichkeit: LNURL-Mechanismen wie LNURL-Pay, LNURL-Withdraw und LNURL-Channel machen Lightning-Zahlungen intuitiver und zugänglicher – selbst für technisch weniger versierte Nutzer.
2. Flexibilität: Mit LNURL lassen sich sowohl Zahlungen empfangen (LNURL-Pay) als auch Guthaben abheben (LNURL-Withdraw) oder Kanäle eröffnen (LNURL-Channel). Lightning-Adressen ermöglichen zudem einfache Zahlungen über eine E-Mail-ähnliche Adresse.
3. Automatisierung: Komplexe Abläufe, wie die Erstellung von Invoices oder Kanalverbindungen, werden automatisiert. Das reduziert Fehler und spart Zeit.
4. Vielfältige Einsatzmöglichkeiten: Von Spenden über Börsenauszahlungen bis hin zu benutzerfreundlichen Onboarding-Prozessen – LNURL eröffnet viele neue Anwendungsfelder im Lightning-Netzwerk.

LNURL ist also ein entscheidender Schritt in Richtung einer barrierefreien und massentauglichen Nutzung von Lightning. Es reduziert technische Hürden und schafft eine solide Basis für die breitere Akzeptanz und Verbreitung des Lightning-Netzwerks. Ich hoffe der Artikel "Was versteht man unter LNURL bei Lightning" hat euch gefallen und konnte etwas Licht ins dunkle bringen.

The post Was versteht man unter LNURL bei Lightning appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dies bedeutet, dass Wallets und andere Software, die auf der Full Node laufen, innerhalb von Minuten mit dem Senden und Empfangen von Transaktionen beginnen können. Die bisher übliche Wartezeit von Stunden oder Tagen, um die Blockchain ab dem Genesis-Block vollständig zu synchronisieren und zu validieren, entfällt.

Wie funktioniert AssumeUTXO

Wenn AssumeUTXO genutzt wird, startet die Node die Synchronisation vom Snapshot bis zum Chain Tip. Parallel dazu wird die alte Blockchain-Geschichte im Hintergrund heruntergeladen und verifiziert. Sobald dies abgeschlossen ist, verifiziert die Node den initial geladenen UTXO-Zustand und erreicht somit dieselbe vertrauenswürdige Sicherheit wie eine Node, die ohne AssumeUTXO synchronisiert wurde. Bis jetzt ist der einzig erlaubte UTXO Snapshot in Bitcoincore hardkodiert und akzeptiert nur Snapshots bis zu einer Höhe von Block 840000.

Schritt-für-Schritt-Anleitung: UTXO-Snapshots nutzen

1. UTXO-Snapshot-Datei herunterladen
   Ladet eine Snapshot-Datei herunter. Einen Snapshot für die maximal mögliche Höhe von Block 840.000 gibt es beispielsweise bei uns am Ende des Beitrags zu finden. Ihr könnt den Snapshot auf einen USB Stick Speichern und zum Beispiel an euren Raspiblitz hängen. Vergesst nicht, den Stick zu mounten.
2. Bitcoin Core v28 (oder neuer) herunterladen und installieren
   Ladet die neueste Version von Bitcoin Core von der offiziellen Webseite herunter und installiert sie.
   Auf dem Raspiblitz updated ihr euren Blitz einfach im Menu UPDATE --> BITCOIN --> BITCOINCORE 28.0
3. Bitcoin Core starten bitcoind -daemon (Auf dem Raspiblitz automatisch)
4. Synchronisation der Blockheader abwarten
   Dies dauert nur ein bis zwei Minuten.
5. Snapshot laden bitcoin-cli loadtxoutset /pfad/zum/utxo-snapshot-height-840000.dat Je nach Geschwindigkeit des Systems kann dieser Schritt einige Minuten bis Stunden dauern.
6. Synchronisation abschließen
   Nach Abschluss des Befehls springt die Synchronisationshöhe eurer Node zur Blockhöhe des Snapshots und fährt von dort mit der normalen Synchronisation fort.
7. Hintergrund-Synchronisation des Genesis-Blocks
   Sobald die Node den Chain Tip erreicht, startet sie im Hintergrund die Verifizierung der Blockchain ab dem Genesis-Block. Während dieser Zeit bleibt die Node jedoch vollständig nutzbar.

Häufige Fragen zu AssumeUTXO

1. Ist es wichtig, woher ich die Snapshot-Datei beziehe?
Nein. Bitcoin Core lädt nur Snapshots, deren UTXO-Hash mit einem übereinstimmt, der fest in Bitcoin Core kodiert ist.

2. Kann ich meine eigenen Snapshots erstellen?
Ja, Snapshots können mit dem Befehl dumptxoutset oder einem Hilfsskript erstellt werden. Allerdings können nur Snapshots bei festgelegten Blockhöhen geladen werden. Derzeit ist nur die Blockhöhe 840.000 unterstützt.

3. Kann ich diese Funktion für pruned Nodes verwenden?
Ja.

4. Kann ich diese Funktion mit aktivierten Indexen nutzen?
Ja, allerdings beschleunigt dies die Erstellung der Indexe nicht. Diese müssen weiterhin linear ab dem Genesis-Block erstellt werden.

Wie viel schneller ist die Synchronisation

In einem Benchmark-Test wurden zwei Synchronisationen mit Bitcoin Core v28 durchgeführt:

• Die erste Synchronisation begann klassisch ab dem Genesis-Block.
• Die zweite verwendete einen Snapshot.

Ergebnisse:

• Mit Snapshot: 10 Minuten für das Laden des Snapshots + 84 Minuten, um den Chain Tip zu erreichen.
• Ohne Snapshot: 659 Minuten für eine vollständige Synchronisation ab Genesis im Clearnet bei nicht limitierender Bandbreite

Die Geschwindigkeit ist also um ein Vielfaches höher!

Lohnt sich AssumeUTXO

Die Entscheidung hängt von mehreren Faktoren ab:

• Dringlichkeit: Wie schnell müsst ihr eure Node verwenden können?
• Hardware-Leistung: Auf leistungsstarken Systemen, die die Blockchain in weniger als einem Tag synchronisieren können, sind die zusätzlichen Schritte möglicherweise nicht erforderlich. Für langsamere Systeme wie einen Raspberry Pi ist AssumeUTXO jedoch ein großer Vorteil.

UTXO Snapshot selber erstellen

Mit diesem Script erstellt ihr selber einen UTXO Snapshot. Anmerkungen dazu:

Das Skript utxo_snapshot.sh dient dazu, einen Snapshot des UTXO-Sets (Unspent Transaction Output) zu einer bestimmten Blockhöhe in Bitcoin Core zu erstellen. Es ermöglicht entweder die Erstellung einer Datei mit dem Snapshot oder die Ausgabe des Hash-Werts des UTXO-Sets. Im Detail funktioniert es wie folgt:

Schlüsselaufgaben des Skripts

1. Parameter validieren:
   • Der Script erwartet drei Argumente:
     • generate-at-height: Die Blockhöhe, für die der UTXO-Snapshot erstellt werden soll. Muss 840000 sein!
     • snapshot-out-path: Der Ausgabepfad für die Snapshot-Datei (oder - für keine Datei, nur den Hash ausgeben). (Pfad eurer Wahl)
     • bitcoin-cli-call: Der Befehl zum Aufruf von bitcoin-cli, z. B. inklusive -datadir-Angabe.
       (Zum beispiel ./src/bitcoin-cli -datadir=/data/bitcoin)
   • Gibt eine Fehlermeldung aus, wenn die Parameter nicht korrekt sind.
2. Prüfen des Pruning-Status:
   • Liest die Blockhöhe, bis zu der die Blockchain beschnitten (pruned) ist.
   • Beendet das Skript mit einer Fehlermeldung, falls die angegebene generate-at-height unterhalb der pruned Blockhöhe liegt (da die Blockchain-Daten fehlen).
3. Existenzprüfung für den Ausgabepfad:
   • Verhindert, dass ein vorhandener Ausgabepfad überschrieben wird.
   • Überprüft, ob das Zielverzeichnis existiert.
4. Netzwerkaktivität deaktivieren (optional):
   • Fragt den Benutzer, ob die Netzwerkaktivität der Node deaktiviert werden soll. Dies dient dazu, Konflikte bei der Synchronisation zu vermeiden, während der Snapshot erstellt wird.
5. Blockchain zurücksetzen und Snapshot erstellen:
   • Invalide erklärt (rewindet) den Block unmittelbar nach der gewünschten Höhe (generate-at-height + 1), um den Zustand der Blockchain an dieser Höhe wiederherzustellen.
   • Führt entweder einen der beiden folgenden Schritte aus:
     • Gibt den Hash des UTXO-Sets aus, wenn snapshot-out-path - ist.
     • Erstellt eine UTXO-Snapshot-Datei mit dem Befehl dumptxoutset.
6. Cleanup-Prozess:
   • Stellt die Blockchain wieder auf den ursprünglichen Zustand zurück, indem der invalide Block wieder berücksichtigt wird (reconsiderblock).
   • Aktiviert die Netzwerkaktivität, falls sie deaktiviert wurde.
7. Unterbrechungsbehandlung:
   • Fängt Ctrl-C (SIGINT) ab, führt den Cleanup-Prozess aus und beendet das Skript sauber.

Der vollständige Befehl um den Script zum Beispiel wäre auf dem Raspiblitz:

./utxo_snapshot.sh 840000 utxo.dat ./src/bitcoin-cli -datadir=/mnt/hdd/bitcoin

Zukunftsperspektiven

Während AssumeUTXO derzeit vor allem von technisch versierten Node-Betreibern genutzt wird, könnte Bitcoin Core in Zukunft eine Funktion anbieten, die Snapshots automatisch beim Start lädt. Dies würde die Nutzung auch für weniger erfahrene Nutzer vereinfachen.

• Sicherheitsaspekt: Auch wenn die initiale Synchronisation durch AssumeUTXO verkürzt wird, bleibt die vertrauenswürdige Sicherheit langfristig erhalten, da die vollständige Verifizierung im Hintergrund erfolgt.
• Energieeffizienz: Gerade für Nodes mit geringem Energieverbrauch, wie auf einem Raspberry Pi oder in einer Cloud-Umgebung, kann diese Funktion nicht nur Zeit, sondern auch Ressourcen sparen.

AssumeUTXO ist ein bedeutender Schritt in Richtung einer benutzerfreundlicheren Bitcoin-Infrastruktur und zeigt, wie kontinuierliche Innovation die Barrieren für den Betrieb von Full Nodes senken kann.

Download UTXO Snapshot

https://cloud.yourdevice.ch/s/JaHSXwcBFgNN8P5

Weitere Möglichkeiten die Node zu Syncen mit älteren Bitcoincore Versionen

Vollständige Kopie der Blockchain erstellen.

Blockchain über das Clearnet syncen.

The post Fullnode schneller syncen mit UTXO Snapshots appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Solomining ist die reinste Form des Minings, bei der ihr direkt mit eurem eigenen Equipment arbeitet, und euch mit der Theorie und Praxis auseinander setzt. Ihr habt die volle Kontrolle über euren Betrieb, die Belohnungen und auch die Herausforderungen. Beim Prozess des Minings könnt ihr solides Verständnis zentraler Konzepte wie Hashrate, Block Templates, Difficulty und der Technik, die hinter der Blockchain steckt erlernen.

Diese Bibel richtet sich an Anfänger, die bisher keinen Plan haben, wie sie starten sollen, aber die Motivation mitbringen, tiefer in die Materie einzutauchen. Schritt für Schritt erkläre ich euch wichtige Begriffe, Technologien und Prozesse, damit ihr euch sicher in dieser faszinierenden Welt bewegen könnt.

Auf geht's – schnappt euch eure Mining-Hardware und lasst uns gemeinsam in die Grundlagen eintauchen! 😊

Die Mining Bibel wurde mit mondayshot geschrieben. Sehr vieles, vor allem die Pool Informationen, Difficulty Berechnungen und der Mining Ablauf stammen von Ihm. Ein Link zur Spende findet ihr unten.

Was ist Solo-Mining

Solo Mining (Lottery Mining) bedeutet, dass ihr alleine versucht, einen Bitcoin-Block zu finden und die volle Belohnung (3.125 BTC + Transaktionsgebühren) zu erhalten. Dabei könnt ihr entweder eure eigenen Node betreiben mit einem eigenen Solo-Pool wie zum Beispiel Public-Pool von Benjamin Wilson oder über einen Solo Mining Pool eines bestimmten Anbieters arbeiten, der die Infrastruktur bereitstellt.

Warum macht man Solo Mining

• Volle Belohnung: Ihr erhaltet 100 % der Blockbelohnung, ohne sie mit anderen Minern zu teilen.
• Unabhängigkeit: Ihr seid nicht auf klassische Pools angewiesen und könnt eure eigene Mining-Strategie verfolgen.
• Lotterie-Charakter: Jeder Hash ist wie ein Lottoschein, und es geht um den großen Gewinn – wenn ihr erfolgreich seid.

Solo Mining ist ideal für risikofreudige Miner, die auf einen großen Gewinn hoffen, und weniger für konstante Einnahmen gedacht. Es erfordert Geduld und eine grosse Portion Glück um einen Block zu finden, aber es macht Spass, und man lernt viel Theorie und auch Praxis zum Handwerk des Bitcoin Minings.

Wie läuft das Mining genau ab

Der Prozess vom Generieren eines Hashes bis zur Veröffentlichung eines gültigen Blocks sieht grob gesagt so aus:

Block Template

1. Der Pool verteilt mit "mining.notify" ein neues Block Template, entweder weil die Transaktionen aktualisiert wurden oder weil das Netzwerk einen neuen Block gefunden hat.

Bei der Übermittlung eines Block Template werden gemäss Stratum Protokoll die folgenden Werte übermittelt:
jobId, prevHash, coinbase part1, coinbase part2, merkle_branch, version, bits, timestamp, clear jobs

Generieren des Hashes

2. Der Miner ergänzt diese Daten um:
   👾 extraNonce2 (selbst generiert)
   👾 nonce (startet bei 0)
3. Aus diesen Daten wird der Block-Header zusammengestellt.
4. Der Block-Header wird zweimal durch die SHA256-Funktion gehasht.

Variieren der Nonce

5. Wenn der generierte Hash nicht unter dem Work-Difficulty Target liegt, erhöht der Miner die Nonce um 1 und wiederholt den Hashing-Prozess.
6. Dieser Vorgang wird Milliarden Mal pro Sekunde wiederholt.
7. Wenn alle möglichen nonce-Werte (2^32) erschöpft sind, ändert der Miner:
   👾 extraNonce2 oder
   👾 timestamp (innerhalb erlaubter Grenzen)
   und beginnt wieder bei 0 mit dem Hochzählen von den möglichen nonce-Werte (2^32 = 4'294'967'296)

Übermittlung an den Pool

8. Wenn ein Hash gefunden wird, der unter der vom Pool vorgegebenen Work-Difficulty liegt, wird der Share mit "mining.submit" an den Pool übermittelt.

Bei der Übermittlung eines Shares werden gemäss Stratum Protokoll die folgenden Werte übermittelt:
id, userId, jobId, extraNonce2, ntime, nonce, versionMask

9. Der Pool überprüft den Share.

Veröffentlichung eines gültigen Blocks

10. Wenn der gefundene Hash auch unter dem Netzwerk-Difficulty Target liegt, erkennt der Pool einen gültigen Block.
11. Der Pool stellt den vollständigen Block zusammen:
    👾 Block-Header mit den vom Miner gefundenen Werten
    👾 Coinbase-Transaktion mit Belohnung für den Miner
    👾 Transaktionen
12. Der Pool broadcastet den Block sofort an verbundene Bitcoin-Nodes.
13. Die Nodes validieren den Block und leiten ihn weiter.
14. Andere Miner beginnen, auf dem neuen Block aufzubauen.
15. Der Pool sendet einen neuen Mining-Job mit einem neuen Block Template an alle verbundenen Miner.

Was ist die "Nonce"

Eine Nonce (Number Only Used Once) ist ein 32-Bit-Wert im Blockheader, den Miner während des Mining-Prozesses kontinuierlich ändern. Sie wird verwendet, um neue Hashes zu generieren.

Funktion der Nonce

• Miner ändern die Nonce bei jedem Versuch, einen gültigen Hash zu finden, der die Difficulty-Vorgaben erfüllt.
• Jede Änderung der Nonce führt zu einem komplett neuen Hash, dank der zufälligen Natur der Hash-Funktion.

Wenn die Nonce alle möglichen Werte durchlaufen hat, ändert der Miner andere Felder im Blockheader (z. B. den Timestamp oder die Coinbase-Transaktion), um weiterhin neue Hashes zu erzeugen.

Größe der Nonce

• Die Nonce ist ein 32-Bit-Wert (4 Bytes), was bedeutet, dass es insgesamt: 2^32=4.294.967.296 mögliche Werte gibt.

Die Nonce ist somit ein zentraler Bestandteil des Proof-of-Work-Prozesses.

Was ist die Coinbase Transaktion

Die Coinbase-Transaktion ist eine spezielle Transaktion, die im Mining-Prozess erstellt wird und die Block-Belohnung (Block Reward) an den Miner auszahlt, der den Block erfolgreich gefunden hat. Sie ist immer die erste Transaktion in einem Block und hat einige besondere Eigenschaften.

Eigenschaften der Coinbase-Transaktion

1. Erzeugung der Block-Belohnung:
   • Die Coinbase-Transaktion generiert die neue Bitcoin-Belohnung, die aktuell (Stand 2024) 3.125 BTC + Transaktionsgebühren beträgt.
   • Diese Belohnung wird direkt an die Wallet-Adresse des Miners oder des Mining-Pools ausgezahlt.
2. Keine Eingänge (Inputs):
   • Im Gegensatz zu normalen Bitcoin-Transaktionen hat die Coinbase-Transaktion keine Inputs, weil die Belohnung neu generiert wird.
   • Sie enthält jedoch eine spezielle Nonce oder zusätzliche Daten im Input-Feld, die Miner ändern können, um neue Hashes zu erzeugen.
3. Speicherort für ExtraNonce:
   • Miner nutzen die Coinbase-Transaktion, um eine ExtraNonce einzufügen, wenn die reguläre Nonce im Blockheader erschöpft ist. Änderungen an der ExtraNonce führen zu einer Änderung der Merkle Root, wodurch neue Hashes erzeugt werden können.
4. Transaktionsgebühren:
   • Neben der Block-Belohnung enthält die Coinbase-Transaktion auch die Summe aller Transaktionsgebühren, die von den im Block enthaltenen Transaktionen gezahlt werden.

Wie sieht eine Coinbase-Transaktion aus

• Input:
  • Kein normaler Input. Stattdessen ein spezielles Feld, das oft vom Miner genutzt wird, um zusätzliche Daten oder eine Botschaft einzufügen.
• Output:
  • Die Auszahlung geht an die Wallet-Adresse des Miners oder des Pools.

Beispiel einer Coinbase-Transaktion

In einem Block kann die Coinbase-Transaktion so aussehen:

• Input: Spezieller Wert (z. B. Nonce, Nachrichten).
• Output: Auszahlung an die Adresse des Miners.

Die Coinbase-Transaktion ist also die erste Transaktion in jedem Block und dient dazu, die Mining-Belohnung und Transaktionsgebühren an den Miner auszuzahlen. Sie hat keine Eingänge, sondern generiert neue Bitcoins, und kann von Minern angepasst werden, um den Hashing-Prozess zu unterstützen.

Die Coinbase unter Stratum V2

Wer die Coinbase-Transaktion zusammenstellt, hängt davon ab, wer das Block-Template baut. Bei Stratum V1 (und auch bei SV2 ohne JDP) baut der Pool die Coinbase – beim Solo-Mining auf einem Public-Pool steht darin bereits eure eigene BTC-Adresse als Output, sodass die Belohnung direkt an euch geht. Mit dem Job Declaration Protocol (JDP) baut hingegen ihr selbst das Template gegen euren eigenen Node – und damit auch die Coinbase. Beim gepoolten SV2 gilt dann die einfache Regel: Der Pool erzwingt nur, dass sein eigener Auszahlungs-Output (für die Reward-Verteilung) enthalten ist; über den gesamten Rest des Blocks bestimmt ihr. Mehr dazu im Abschnitt „Stratum V2 – das modulare Mining-Protokoll".

Was sind Shares

Shares sind keine Teillösungen eines gültigen Blocks, sondern vielmehr Nachweise für die Arbeitsleistung eines Miners. Beim Mining versucht ein Miner, einen gültigen Block zu finden, der die von der Blockchain vorgegebene globale Schwierigkeit (Network Difficulty) erfüllt. Da diese Schwelle sehr hoch ist, wird innerhalb eines Mining-Pools mit einer niedrigeren Schwierigkeit gearbeitet – der sogenannten Share Difficulty.

Wie funktionieren Shares

Man kann sich das so vorstellen, als würde der Miner regelmäßig Blöcke generieren, die die Share Difficulty erfüllen, aber die Network Difficulty nicht erreichen. Diese Blöcke sind technisch gesehen ungültig für die Blockchain, da sie nicht genug Nullen im Hash aufweisen, werden aber dennoch vom Pool akzeptiert, um die Arbeitsleistung des Miners zu messen. Jeder solche "kleine Block" wird als Share gezählt.

Warum sind Shares wichtig

Shares dienen dem Mining-Pool dazu, die Beiträge der einzelnen Miner fair zu bewerten. Sobald einer der Miner zufällig einen Hash findet, der die Network Difficulty erfüllt (also einen gültigen Block), wird dieser Block an die Blockchain übermittelt. Die Belohnung, die der Pool dafür erhält, wird dann unter den beteiligten Minern aufgeteilt – basierend auf der Anzahl ihrer Shares.

Accepted Shares

Shares die vom Miner erfolgreich an den Pool übermittelt und akzeptiert wurden.

Rejected Shares

Shares die vom Miner zwar an den Pool übermittelt, jedoch nicht akzeptiert wurden, weil zB
▪ euer Share eine zu geringe Difficulty aufweist (das Thema bei NerdMiner und Diff < 1)
▪ euer Share wegen hoher Latenzen zu spät eingereicht wurde und bereits ein neues Block Template verteilt wurde
▪ euer Share veraltet ist, dass heisst das zwischenzeitlich ein neuer Block gefunden wurde und dein Share somit auf einem veralteten Block Template erstellt wurde
▪ euer Share doppelt eingereicht wurde
▪ euer Share gegen Pool-Richtlinien verstösst (zB. blockt kano.is IP-Adressen von CPU-Miner)

Der Prozess besteht im Wesentlichen darin, dass Miner kontinuierlich Hashes berechnen und dabei Shares generieren. Irgendwann trifft ein Miner zufällig auf einen Hash, der genügend Nullen hat, um einen gültigen Block zu erstellen. Dieser Block wird an die Blockchain angehangen, und alle Miner, die Shares beigesteuert haben, werden entsprechend entlohnt – abhängig vom Vergütungsmodell des Pools.

Shares und Channels unter Stratum V2

Bei Stratum V1 läuft die gesamte Kommunikation über eine einzige, textbasierte Verbindung, auf der die oben beschriebene Worker-Difficulty (vardiff) dynamisch angepasst wird. Stratum V2 strukturiert dieselbe Verbindung stattdessen in typisierte Channels, was die Share-Übermittlung effizienter und flexibler macht. Drei Channel-Typen sind dabei relevant:

• Standard Channel – für einzelne ASIC-Geräte wie eine Bitaxe. Er deckt bis zu rund 280 TH/s pro nTime-Wert ab und ist der Normalfall für Heim-Solo-Miner.
• Extended Channel – für Proxies und grössere Setups. Er erlaubt eigenes Extranonce-Rolling, sodass der Miner mehr Nonce-Raum selbst durchläuft und seltener mit dem Pool sprechen muss.
• Group Channel – bündelt mehrere Standard Channels hinter einem einzelnen Proxy, praktisch für Farmen mit vielen Geräten.

In der Praxis unterstützen die Firmwares bislang unterschiedliche Channel-Typen: BraiinsOS setzt aktuell ausschliesslich auf Standard Channels. Bei der quelloffenen Hardware sind wir sogar einen Schritt weiter – die Firmware beider Geräte stammt von uns (yourdevice): Für die Bitaxe haben wir sowohl Standard- als auch Extended-Channel-Unterstützung umgesetzt, die NerdQaxe spricht Extended Channels.

Zusammen mit dem binären Nachrichtenformat und der deutlich geringeren Latenz (Block-Wechsel statt in Hunderten Millisekunden im Bereich weniger Millisekunden) sorgt diese Struktur dafür, dass eure Shares schneller und mit weniger Overhead beim Pool ankommen als unter V1.

Difficulty

Network Difficulty (Netzwerk-Schwierigkeit)

Die Network Difficulty ist eine globale Metrik, die von der Bitcoin-Blockchain selbst festgelegt wird und den Schwierigkeitsgrad beschreibt, einen gültigen Block zu finden. Sie wird etwa alle 2016 Blöcke (etwa alle zwei Wochen) dynamisch angepasst, damit das Netzwerk im Durchschnitt alle 10 Minuten einen neuen Block generiert.

Eigenschaften der Network Difficulty:

1. Global und für alle Miner gleich:
   • Jeder Miner im Netzwerk muss sich an die aktuelle Network Difficulty halten, um einen gültigen Block zu finden.
2. Berechnung:
   • Die Difficulty ist proportional zur Zeit, die das Netzwerk benötigt hat, um die letzten 2016 Blöcke zu minen.
   • Formel:
     Neue Schwierigkeit = Alte Schwierigkeit × (Zielzeit für 2016 Blöcke / Tatsächliche Zeit für 2016 Blöcke)
3. Beeinflusst den Mining-Prozess:
   • Eine höhere Network Difficulty bedeutet, dass Miner mehr Rechenleistung benötigen, um einen Block zu finden.
   • Ziel: Die Blockzeit von 10 Minuten im Durchschnitt konstant halten, unabhängig von der Gesamt-Hashrate im Netzwerk.
4. Ausdruck in Zahlen:
   • Network Difficulty wird als eine große Zahl dargestellt, die das Verhältnis zwischen einem Ziel-Hash und dem maximal möglichen Hash beschreibt.

Worker Difficulty (Arbeiter-Schwierigkeit)

Die Worker Difficulty ist eine lokal festgelegte Schwierigkeit, die in Mining-Pools oder Solomining-Systemen verwendet wird, um zu bestimmen, wie schwer es für einen einzelnen Worker (einen Mining-Prozess oder -Gerät) ist, einen Share (einen Teilerfolg) zu finden.

Eigenschaften der Worker Difficulty

1. Individuell anpassbar:
   • Die Worker Difficulty wird von einem Mining-Pool oder der Mining-Software festgelegt, um die Leistung einzelner Mining-Geräte zu berücksichtigen.
   • Ziel: Ein gleichmäßiger Strom an Shares, unabhängig von der Rechenleistung des Miners.
2. Shares anstatt Blöcke:
   • Miner arbeiten mit einer lokal niedrigeren Schwierigkeit und reichen ihre gefundenen Shares an den Pool weiter. Der Pool aggregiert die Shares und arbeitet auf der Network Difficulty, um einen gültigen Block zu finden.
3. Warum gibt es Worker Difficulty?
   • Unterschiedliche Miner haben unterschiedliche Hashraten. Ein Gerät mit geringer Leistung würde kaum Shares generieren, wenn es direkt mit der Network Difficulty arbeiten müsste. Daher wird die Worker Difficulty so angepasst, dass jedes Gerät regelmäßig Shares liefern kann.
4. Automatische Anpassung (Stratum-Protokoll):
   • Mining-Pools passen die Worker Difficulty dynamisch an (z. B. mit „vardiff“, variable difficulty), um sicherzustellen, dass Miner ungefähr einen Share alle 5–10 Sekunden liefern.
5. Wert:
   • Worker Difficulty ist immer niedriger als die Network Difficulty, da sie für die lokale Rechenleistung optimiert ist.

Unterschiede zwischen Network und Worker Difficulty

Defintion und Festlegung der Difficulty oder Netzwerk-Schwierigkeit

Difficulty = Hash(max_target) ÷ Hash(current_target)

Mit Hash(max_target) ist die Difficulty = 1 gemeint und sie repräsentiert die grösstmögliche Zahl bzw. die geringstmögliche Schwierigkeit.
Hash(current_target) repräsentiert die notwendige Schwierigkeit eines Hashes, bedeutet je kleiner diese Zahl, desto schwieriger.
Die Difficulty oder Netzwerk-Schwierigkeit ist das Ergebnis aus der Division der beiden Werte Hash(max_target) und Hash(current_target).

Hier die Berechnung am Beispiel des Block_752868 und der damaligen Difficulty = 30.98T = 30'977'051'760'460

Hash(max_target) bzw. Difficulty = 1 ist bei Bitcoin als 0x1d00ffff definiert, als Hexadezimalwert ist das ein Hash mit 8 führenden Nullen:
= 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Da bei Bitcoin der Hash(max_target) als Gleitkommazahl gespeichert wird, wird dieser abgeschnitten:
= 00000000ffff0000000000000000000000000000000000000000000000000000

Dieser Hexadezimalwert wird in ein Dezimalwert konvertiert:
= 26959535291011309493156476344723991336010898738574164086137773096960
= 2.696E+67 = Hash(max_target)

Da wir nun Hash(max_target) = 2.696E+67 und die Difficulty 30'977'051'760'460 kennen, können wir die notwendige Schwierigkeit eines Hashes, also Hash(current_target), bestimmen:

Hash(max_target) ÷ Difficulty = Hash(current_target)
= 2.696E+67 ÷ 30'977'051'760'460 = 8.703E+53 = Hash(current_target)

Für einen gültigen Block muss der Hash des Blocks_752868 kleiner und damit schwieriger sein, als die notwendige Schwierigkeit:
Hash(block_752868) < Hash(current_target) = valid Block

Hash(block_752868)
= 000000000000000000023331c3817233e49bb141216fea1a75a3643a04410bde

Dieser Hexadezimalwert wird in ein Dezimalwert konvertiert:
= 210716037705402490166328113539479810618942705228647390
= 2.107E+53 = Hash(current_target)

2.107E+53 < 8.703E+53 = valid Block ☑️

Der Hash vom Block ist tatsächlich sehr klein und hat damit eine sehr hohe Schwierigkeit:

Hash(max_target) ÷ Hash(block_752868) = Diff(block_752'868)
2.696E+67 ÷ 2.107E+53 = 127'942'493'531'047

Diff(block_752868) = 127'942'493'531'047 = 127.94T

Warum Network und Worker Difficulty wichtig sind

• Network Difficulty:
  • Regelt das Gesamtgleichgewicht der Bitcoin-Blockchain und sorgt für Stabilität dass alle 10 Minuten ein Block gefunden wird.
• Worker Difficulty:
  • Optimiert den Mining-Prozess auf individueller Ebene, insbesondere bei Pools, um sicherzustellen, dass jeder Miner sinnvoll zur Blockfindung beiträgt.

Das Diagramm zeigt den Unterschied zwischen der Network Difficulty (global und konstant über 2016 Blöcke und wird dann angepasst) und der Worker Difficulty, die sich je nach Hashrate des Miners unterscheidet:

• Network Difficulty (gestrichelte Linie): Bleibt auf globaler Ebene konstant während 2016 Blöcke und wird nur dann angepasst, um die Blockzeit stabil zu halten.
• Worker Difficulty (High Hashrate) (durchgezogene Linie): Erhöht durch schneller für Miner mit höherer Rechenleistung.
• Worker Difficulty (Low Hashrate) (gepunktete Linie): ist geringer, da die Hashrate niedriger ist und eine kleinere Schwierigkeit besser geeignet ist. Je nachdem wieviel Hashleistung das Gerät liefert, wird aber auch hier die Worker Difficulty angepasst.

Was sind Block Templates

Ein Block Template ist eine Vorlage für einen neuen Block in der Blockchain. Es enthält alle notwendigen Daten, die ein Miner benötigt, um einen gültigen Block zu erstellen und an das Netzwerk zu senden. Block Templates werden in der Regel von einer Bitcoin-Node generiert und sind ein zentraler Bestandteil des Mining-Prozesses.

Bestandteile eines Block Templates

1. Header-Daten:
   • Version: Gibt die Softwareversion des Bitcoin-Protokolls an.
   • Previous Block Hash: Verweis auf den Hash des vorherigen Blocks in der Blockchain.
   • Merkle Root: Der Wurzelhash des Merkle-Baums, der alle Transaktionen im Block repräsentiert.
   • Timestamp: Aktuelle Zeit des Nodes.
   • Difficulty Target: Die Schwierigkeitsgrenze, die der Block erfüllen muss.
   • Nonce: Ein Wert, der während des Minings variiert, um einen gültigen Blockhash zu finden.
2. Liste von Transaktionen:
   • Enthält alle Transaktionen, die in den neuen Block aufgenommen werden sollen. Diese Transaktionen stammen aus dem Mempool (Memory Pool), in dem alle unbestätigten Transaktionen gespeichert werden.
3. Coinbase-Transaktion:
   • Die erste Transaktion im Block, die die Mining-Belohnung an die Adresse des Miners auszahlt. Dies ist der einzige Weg, neue Coins in Umlauf zu bringen.
4. Zusätzliche Felder:
   • Informationen über Gebühren, Höhe des Blocks, und manchmal sogar zusätzliche Metadaten.

Wie werden Block Templates generiert

Block Templates werden normalerweise von einem Bitcoin-Node mit Hilfe der JSON-RPC-Schnittstelle bereitgestellt. Ein Miner bzw. der Stratum Server kann die Methode getblocktemplate verwenden, um eine aktuelle Vorlage zu erhalten.

Beispiel für einen RPC-Aufruf:

bitcoin-cli getblocktemplate '{"capabilities":["coinbasetxn", "workid"]}'

Die Node gibt daraufhin ein JSON-Objekt zurück, das alle oben genannten Daten enthält.

Eine Antwort könnte in etwas so aussehen:

{
  "version": 536870912,
  "previousblockhash": "0000000000000000000bae6ebf7a123456789abcdef0000000000000abcde123",
  "transactions": [
    {
      "data": "0100000001abcdef...", 
      "txid": "123456789abcdefabcdef123456789abcdef123456789abcdef123456789abcde",
      "hash": "abcdefabcdef123456789abcdefabcdef123456789abcdefabcdef123456789abc",
      "depends": [],
      "fee": 50000,
      "sigops": 2
    }
  ],
  "coinbaseaux": {
    "flags": "062f503253482f"
  },
  "coinbasevalue": 312500000, 
  "target": "0000000000000000000f00000000000000000000000000000000000000000000",
  "mintime": 1697097600,
  "mutable": ["time", "transactions", "prevblock"],
  "noncerange": "00000000ffffffff",
  "sigoplimit": 80000,
  "sizelimit": 4000000,
  "curtime": 1697098502,
  "bits": "170c47d7",
  "height": 809349
}

In diesem Beispiel ist nur eine einzige Transaktion enthalten. Ein Template wäre natürlich viel viel grösser.

Erklärung der Felder

1. version:
   • Gibt die Blockversion an, die verwendet wird. Die Miner müssen diese in den Blockheader einfügen.
2. previousblockhash:
   • Der Hash des vorherigen Blocks, der in den neuen Block referenziert wird, um die Blockchain zu verketteten.
3. transactions:
   • Eine Liste der Transaktionen, die im Block enthalten sein sollen.
   • data: Die vollständige, serialisierte Transaktion.
   • txid: Die ID der Transaktion.
   • hash: Hash der Transaktion.
   • fee: Die Transaktionsgebühr (in Satoshis).
   • sigops: Anzahl der Signaturoperationen der Transaktion.
4. coinbaseaux:
   • Zusätzliche Daten, die in der Coinbase-Transaktion enthalten sein sollen, wie Mining-Pool-Flags.
5. coinbasevalue:
   • Die Gesamtbelohnung (Blockreward + Transaktionsgebühren), die an den Miner ausgezahlt wird (in Satoshis).
6. target:
   • Der Zielwert, unter den der Hash fallen muss, damit der Block gültig ist (abhängig von der Difficulty).
7. mintime:
   • Die frühestmögliche Zeit (UNIX-Timestamp), zu der der Block erstellt werden kann.
8. mutable:
   • Eine Liste von Feldern, die der Miner anpassen darf, z. B. time, transactions oder prevblock.
9. noncerange:
   • Der Wertebereich der Nonce, die der Miner verändern darf, um neue Hashes zu erzeugen.
10. sigoplimit:
    • Die maximale Anzahl an Signaturoperationen, die im Block erlaubt sind.
11. sizelimit:
    • Die maximale Blockgröße in Bytes (bei Bitcoin 4 MB, einschließlich SegWit-Daten).
12. curtime:
    • Die aktuelle Zeit, zu der der Blocktemplate erstellt wurde (UNIX-Timestamp).
13. bits:
    • Der kompakte Zielwert (Difficulty) für den Block in komprimierter Form.
14. height:
    • Die Höhe des Blocks in der Blockchain (1-basierte Nummerierung).

Block Templates also sind ein zentraler Bestandteil des Mining-Prozesses. Sie enthalten die Daten, die ein Miner benötigt, um einen Block zu erstellen und zu validieren. Für Solominer die ihren eigenen Mining Pool beitreiben, bieten sie maximale Kontrolle über den Inhalt des Blocks und die Auszahlung der Belohnung. Ein Blocktemplate, der eure BTC-Adresse enthält, kann nicht mehr nachträglich von Bitcoincore verändert werden, ansonsten würde der Hash des Blocks nicht mehr stimmen.

Block Template Hash Simulator

Ändert bestimmte Felder im Template ab, und schaut, wie sich der Hash verändert. Ihr könnt so lange ändern wie ihr wollt, und auch den ganzen Tag auf der Tastatur herumdrücken, und ihr werdet verstehen, wie schwierig es ist, einen Hash zu generieren, der eine bestimmte Anzahl an Nullen enthält.

Block Template Updates ckpool vs public pool

Häufig stellt sich die Frage, ob ckpool besser fürs Mining geeignet ist, weil sie alle 30 Sekunden ein neues Blocktemplate schicken, anstatt alle 60 Sekunden wie zum Beispiel Public Pool. Wenn euer Template seltener geupdated wird, könnte eine Transaktion mit viel Gebühr bereits in aktuelleren Templates sein, aber noch nicht in eurem. Extrembeispiel: Die fehlerhafte Paypal-Konsolidierung 2023 ist nicht in eurem Template, wenn eure Bitaxe kein „aktuelles“ Template hat. Damit entgehen euch in diesem Fall die zusätzlichen 19BTC an Fees.

Block Templates unter Stratum V2

Alles in diesem Abschnitt – der Pool schickt euch alle 30 bzw. 60 Sekunden ein frisches Template, und je aktueller, desto besser – beschreibt das Stratum-V1-Modell, bei dem der Pool das Block-Template baut und an euch verteilt. Mit dem Job Declaration Protocol (JDP) von Stratum V2 dreht sich genau das um: Ihr baut das Template selbst, lokal gegen euren eigenen Bitcoin-Node. Damit ist die Frage „wie oft schickt mir der Pool ein aktuelles Template?" hinfällig – ihr zieht die Transaktionen in Echtzeit direkt aus eurem eigenen Mempool und entscheidet selbst, was in den Block kommt. Der Pool prüft dann nur noch, dass sein Auszahlungs-Output enthalten ist, und übernimmt das Share-Accounting. Voraussetzung ist wie erwähnt ein Pool mit JDS-Unterstützung und ein eigener Node – die Details dazu findet ihr im Abschnitt „Stratum V2 – das modulare Mining-Protokoll" weiter unten.

Was ist, wenn ich mehrere Miner habe, arbeiten die dann alle am selben Template?

Nein, dafür gibt es eben zum Beispiel die ExtraNonce. Die ExtraNonce ist Teil des Stratum mining protocol und befindet sich im Header der Coinbase Transaktion. Die ExtraNonce besteht aus 2 Teilen:
ExtraNonce1 und ExtraNonce2:

👉 Die ExtraNonce1 wird dem Miner vom Pool zur Verfügung gestellt und dient als Identifikator
mining.subscribe("user agent/version", "extranonce1")

👉 Die ExtraNonce2 wird vom Miner während seiner Arbeit ständig geändert und mit jedem Share an den Pool übermittelt
mining.submit("username", "job id", "ExtraNonce2", "nTime", "nOnce")

Mit diesem 'unique string' oder 'Identifikator' ist sichergestellt, dass 2 Worker selbst bei identischem Block Template / Nonce / Time Stamp etc. nie den gleichen Hash produzieren.

Damit wird sichergestellt, dass sich die Hashleistung auch bei mehreren Workern addiert, und niemals 2 Miner an der selben Aufgabe rechnen.

Muss ich dem Pool vertrauen dass er mit auch wirklich die Belohnung sendet

Wenn ihr Solo-Mining auf dem dem Public-Pool Projekt betreibt, bekommt ihr vom Pool alle 60 Sekunden ein komplett individuelles Block Template, welches in der Coinbase-Transaktion eure BTC-Adresse als Output für den Block-Reward enthält.
Ihr seid daher nicht auf das Vertrauen angewiesen, dass ein möglicher Block-Reward euch weitergesendet wird, weil der Reward mit der Coinbase-Transaktion bereits auf eure BTC-Adresse generiert wird.
Auch kann eure BTC-Adresse nicht durch eine andere Adresse ersetzt werden, weil sich sonst der Hash vom Block komplett verändern würde, und bei der geringsten Veränderung sofort ungütlig wäre.

Ihr müsst das übrigens nicht einmal blind glauben: Moderne AxeOS-Firmware (Bitaxe & Co.) bringt inzwischen einen eingebauten Coinbase-Decoder mit. Damit seht ihr direkt am Gerät, wie die Coinbase-Transaktion des aktuell bearbeiteten Templates aufgebaut ist – und könnt live verifizieren, dass wirklich eure eigene BTC-Adresse als Reward-Output eingetragen ist. So lässt sich mit einem Blick prüfen, dass der Pool euch im Erfolgsfall tatsächlich auszahlt und nicht heimlich eine fremde Adresse hinterlegt hat.

Dieses Vertrauen betrifft allerdings nur die Auszahlung. Eine ganz andere Frage ist, wer eigentlich bestimmt, welche Transaktionen überhaupt in den Block kommen – und genau da setzt das nächste Kapitel an.

Stratum V2 – das modulare Mining-Protokoll

Alles bisher Beschriebene – wie euer Miner Jobs erhält, Shares einreicht und mit dem Pool spricht – läuft klassischerweise über Stratum V1: ein simples, textbasiertes JSON-RPC-Protokoll, das seit Jahren der Arbeitstier-Standard ist. V1 hat aber zwei Schwächen: Es überträgt alles im Klartext (Pool-Adresse, eure BTC-Adresse, Jobs, Shares), und der Pool bestimmt vollständig, was in den Block kommt. Genau hier setzt Stratum V2 (SV2) an.

Wichtig vorweg, damit keine falschen Erwartungen entstehen: SV2 wurde in erster Linie für gepooltes Mining im grossen Massstab entworfen, nicht speziell für Solo-Mining. Und SV2 ist kein einzelnes, monolithisches Protokoll, sondern ein modularer Baukasten aus Sub-Protokollen – ihr nutzt nur die Teile, die ihr braucht. Das ist der Schlüssel zum Verständnis: Je nachdem, welche Bausteine zum Einsatz kommen, ändert sich, wie viel ihr dem Pool noch vertrauen müsst.

Stratum V1 vs. V2 – der direkte Vergleich

Bevor wir in die Details gehen, die wichtigsten Unterschiede auf einen Blick. Wichtig dabei: Mehrere SV2-Vorteile (vor allem die Trust-Minimierung) hängen am optionalen Job Declaration Protocol (JDP) – ohne JDP bleibt es beim alten Vertrauensmodell.

Die drei Sub-Protokolle

• Mining Protocol – der direkte Nachfolger von SV1 für die Job- und Share-Abwicklung. Statt textbasiertem JSON-RPC nutzt SV2 ein kompaktes Binärformat, was die Bandbreite drastisch senkt (rund 60 % weniger auf Pool-Seite) und die Latenz beim Job-Wechsel massiv reduziert. Das ist der einzige Baustein, den ihr für SV2 zwingend braucht.
• Job Declaration Protocol (JDP) – der eigentliche Game-Changer. Hier baut der Miner sein eigenes Block-Template gegen seinen eigenen Bitcoin-Node (über einen lokalen Job Declarator Client, JDC) und wählt selbst, welche Transaktionen hineinkommen. Der Pool betreibt dazu einen Job Declarator Server (JDS), der nur noch prüft, dass sein Payout-Output enthalten ist, und das Share-Accounting macht – er diktiert aber nicht mehr den Blockinhalt.
• Template Distribution Protocol (TDP) – liefert die nötigen Block-Informationen effizient direkt aus Bitcoin Core (per IPC statt ständigem getblocktemplate-Polling). Es ersetzt die alte, schwerfällige Template-Beschaffung und ist die Grundlage, damit JDP überhaupt sauber funktioniert.

Verschlüsselung: das Ende von Hashrate-Hijacking

SV2 bringt von Haus aus Verschlüsselung mit (das Noise_NX-Framework mit Pinning des statischen Pool-Public-Keys). Das verhindert Hashrate-Hijacking durch Man-in-the-Middle-Angriffe: Bei V1 kann jemand auf dem Netzwerkpfad zwischen euch und dem Pool die Klartext-Kommunikation abfangen und einen Teil eurer Shares auf einen fremden Pool umleiten (Schätzungen sprechen von bis zu ~2 % stehlbarer Rechenleistung), ohne dass ihr es merkt. Mit SV2 ist die Verbindung authentifiziert und verschlüsselt. Übrigens: Dieser gepinnte Public Key ist genau der Authority Key, den ihr beim Einrichten eines SV2-Pools (z. B. unseres Blitzpool) in eurem Miner hinterlegt.

Was SV2 für euch als Solo-Miner konkret bedeutet

Hier lohnt sich die saubere Unterscheidung, denn „SV2 = Dezentralisierung" ist eine verkürzte Aussage:

• SV2 ohne JDP (nur Mining Protocol): Ihr gewinnt Verschlüsselung und Effizienz – aber der Pool baut weiterhin das Block-Template. Bei der Frage, welche Transaktionen in den Block kommen, vertraut ihr dem Pool also genauso wie bei V1. Ohne JDP nimmt euch SV2 dieses Vertrauen nicht ab.
• SV2 mit JDP: Erst jetzt baut ihr selbst den Block und bestimmt den Inhalt – das ist der echte Hebel gegen Mining-Zentralisierung und Transaktionszensur. Dafür müssen aber zwei Bedingungen erfüllt sein: (1) der Pool, zu dem ihr minet, betreibt einen JDS, und (2) ihr betreibt einen eigenen Bitcoin-Node.

Vom Payout-Vertrauen (siehe Abschnitt oben) ist das unabhängig: Als Solo-Miner auf einem Public-Pool wird euer Reward ohnehin schon direkt über die Coinbase auf eure Adresse generiert – das ist bereits ohne SV2 vertrauenslos. JDP adressiert die andere Dimension: wer über den Blockinhalt entscheidet.

Adoption – Stand 2026

SV2 ist auf dem Vormarsch, aber noch nicht der Standard: Aktuell laufen schätzungsweise 15–20 % der Netzwerk-Hashrate über SV2. Braiins (Braiins OS+) bietet die reifste V2-Firmware inklusive Job Negotiation, DEMAND (DMND) war 2025 der erste vollständig auf SV2 gebaute Pool, und im Mai 2026 sind sieben grosse Pools (u. a. Foundry, Antpool, F2Pool) der SV2-Working-Group beigetreten. Bei der quelloffenen Hardware tut sich gerade richtig viel: Die NerdQaxe spricht SV2 bereits, und die Bitaxe spricht seit AxeOS 2.14 (veröffentlicht am 4. Juni 2026) ebenfalls SV2 – die Firmware-Implementierungen beider Geräte stammen von uns bei yourdevice. Unser Blitzpool bietet dazu die passende SV2-Gegenstelle für Solo-Miner.

Wenn ihr tiefer einsteigen möchtet, lest unsere ausführlichen Beiträge Stratum V2 – Warum das Bitcoin-Mining ein neues Protokoll braucht und Stratum V2 und die Coinbase-Hoheit.

Solo-Pools in der Übersicht

CKpool

CKpool ist ein reiner Solo-Pool (277 Blöcke), der Code von ckpool ist frei verfügbar. Con Kolivas selbst geniesst grosses Vertrauen. Er war massgeblich an der Entwicklung von cgminer beteiligt. Die Oberfläche ist rudimentär und ohne Schnick-Schnack, dafür performant, stabil und die Konfiguration sehr einfach. Der Pool hat eine extrem hohe Uptime, der Block-Reward bzw. die Coinbase-Transaktion geht direkt an die eigene BTC-Adresse, ohne Umweg.

https://solo.ckpool.org/

Pool Fees
2% des Block-Rewards (exkl. Transaction Fees) gehen an ckpool an die BTC-Adresse bc1q28kkr5hk4gnqe3evma6runjrd2pvqyp8fpwfzu um den Pool zu betreiben und zur weiteren Pflege des ckpool-Codes beizutragen.

Settings

Pool URL:
stratum+tcp://eusolo.ckpool.org:3333
stratum+tcp://solo.ckpool.org:3333

Username
bc1qDoNotShareYourBTCAdressWithAnyBodyElse.workername

Password
x

High-Difficulty Pool (für stärkere Miner) ab Work-Diff < 1'000'000 = 1'000K = 1M

Pool URL
stratum+tcp://eusolo.ckpool.org:4334
stratum+tcp://solo.ckpool.org:4334

Seit dem Update vom Juni 2023 verteilt ckpool alle 30 Sekunden (vorher alle 60 Sekunden) ein neues Block Template mit den aktuellsten Transaktion an die Miner.

Seit November 2024 betreibt Con Kolivas eusolo.ckpool.org auf einem eigenständigen Server in der EU. Der Pool hat eine deutlich geringere Latenz als solo.ckpool.org — die beiden Pools laufen unabhängig voneinander und können daher auch als Backup-Pools eingerichtet werden.

Pool Difficulty

CKpool ist so konfiguriert, dass bei der ersten Verbindung einem Worker standardmässig die Work Diff = 10'000 zugewiesen wird.
Die Work-Diff wird so angepasst, dass im Durchschnitt 20 Shares pro Minute – also alle 3 Sekunden 1 Share – überliefert wird.
Kommen mehr als 20 Shares pro Minute wird die Work Diff vom entsprechenden Worker erhöht, kommen weniger wird die Work Diff gesenkt. Dabei ist das untere Limit, also die Minimum Work-Diff = 1.

Public Pool

Public Pool ist tolles Open-Source-Projekt mit attraktiven Statistiken.
Insbesondere für Miner mit Work-Diff < 1 bzw. Hashrate im Kilo- oder Megahash-Bereich geeignet, wie zB NerdMiner oder andere CPU-Miner.
Relativ jung und es gibt immer wieder Downtimes wegen Updates/Wartungsarbeiten.
Bisher wurde mit diesem Solo-Pool noch nie einen Block gefunden.

https://web.public-pool.io/ --> offizieller Public-Pool
https://blitzpool.yourdevice.ch/ --> Schweizer Public-Pool von yourdevice.ch betrieben.

Pool Fees
No Fees. 100% des Block-Rewards gehen an den Miner – seit Ende November 2023 auch für Miner mit mehr als 50 TH/s.

Settings

Pool URL
stratum+tcp://public-pool.io:21496
stratum+tcp://blitzpool.yourdevice.ch:3333

Username
bc1qDoNotShareYourBTCAdressWithAnyBodyElse.workername

Password
x

Pool Difficulty

Public Pool ist so konfiguriert, dass bei der ersten Verbindung einem Worker standardmässig die Work Diff = 512 zugewiesen wird.
Die Work-Diff wird so angepasst, dass im Durchschnitt 6 Shares pro Minute – also alle 10 Sekunden 1 Share – überliefert wird.
Kommen mehr als 6 Shares pro Minute wird die Work Diff vom entsprechenden Worker erhöht, kommen weniger wird die Work Diff gesenkt. Dabei ist das untere Limit, also die Minimum Work-Diff = 0.00001

KanoPool

KanoPool ist sowohl Solo-Pool (0 Blöcke) als auch PPLNS-Pool (2434 Blöcke). Kano war ebenfalls an der Entwicklung von cgminer beteiligt. Deshalb blockiert KanoPool offenbar Miner, welche gegen die GPL-Lizenzbedingungen von cgminer verstossen, zB VNISH und Awesome. Ausserdem blockiert KanoPool IP-Adressen welche Hashrate von CPU-Miner oder GPU-Miner an den Pool schicken.
Die Konfiguration ist aufwendiger und für High-Difficulty-Worker ist diese teilweise echt mühsam und erfolgt nicht wie bei ckpool einfach über einen separaten Port.
Dafür bessere API-Schnittstelle, schönere Statistiken als ckpool, eine bessere Verteilung der Proxy-Server und geringere Gebühren (=Pool Fee) im Falle eines Block-Rewards (0.5%).

Jedoch hat man mit gesperrten IP-Adresse und extrem vielen rejected Shares zu gekämpft. Ausserdem wird der Block-Reward nicht direkt auf die eigene BTC-Adresse generiert, die Coinbase-Transaktion geht zuerst an die BTC-Adresse von Kano – eine Frage des Vertrauens.

https://kano.is/

Pool Fees
0.5% des Block-Rewards gehen an kano.

Settings

Pool URL
stratum+tcp://de.kano.is:3333

Username
bc1qDoNotShareYourBTCAdressWithAnyBodyElse.workername

Password
x

KanoPool ist nach der Registration standardmässig als PPLNS-Pool eingerichtet und muss aktiv auf Solo-Pool umgestellt werden. Dafür sind folgenden Voraussetzungen bzw. Schritte notwendig:

👉 The account must have been created in the last 2 hours
👉 You must not have pointed ANY miners at the account
👉 You must have verified the account email under Account >Verify
👉 You must have set a payout address under Account >Settings

☝️ You will not be able to change the account from Solo back to PPLNS

Pool Difficulty

KanoPool ist so konfiguriert, dass bei der ersten Verbindung einem Worker standardmässig die Work Diff = 8'190 zugewiesen wird.
Die Work-Diff wird so angepasst, dass im Durchschnitt 18 Shares pro Minute – also alle 3.3 Sekunden 1 Share – überliefert wird.
Kommen mehr als 18 Shares pro Minute wird die Work Diff vom entsprechenden Worker erhöht, kommen weniger wird die Work Diff gesenkt. Dabei ist das untere Limit, also die Minimum Work-Diff = 442.

High-Difficulty für stärkere Maschinen:

👉 Aktiviert in eurem Account unter Account > Solo die Option Allow high Difficulty.
👉 Erfasse auf Nicehash/MRR in eurer Pool-Konfiguration euren Worker mit entsprechenden Einstellungen, zB:
userXY.worker_highdiff
👉 Führt einen Test mit dem Poolverifikator durch, dadurch wird der Worker auf KanoPool im Account userXY unter Workers ersichtlich.
👉 Danach ändert ihr unter Workers > Mangagement beim gewünschten worker_highdiff, die Minimum Diff von 0 auf den erforderlichen Wert.
👉 Achtung: Der Poolverifikator wird zwar weiterhin einen Fehler melden: Poolschwierigkeitsgrad zu gering (vorausgesetzt=8190, minimum=500000), aber wenn die Minimum Diff entsprechend gesetzt wurde, wird der Auftrag trotzdem starten!

OCEAN Pool

Luke Dashj (Bitcoin Core developer) reaktiviert den Pool Eligius (2011-2017) unter dem Namen OCEAN.
Das Ziel ist, einen dezentralisierten, transparenten, zensurfreien, non-custodial Mining-Pool zu etablieren.
Weiter soll die Nutzung und Weiterentwicklung vonPoolschwierigkeitsgrad zu gering Stratum V2 vorangetrieben werden, ebenso ist die Intergration von Lightning-Auszahlungen (2024) geplant.
Das Belohnungssystem von OCEAN namens TIDES (Transparent Index of Distinct Extended Shares) gibt den Minern die Möglichkeit, noch vor dem Finden eines Blocks den genauen Betrag ihrer Bezahlung zu verifizieren. Die Miner werden direkt vom Bitcoin-Netzwerk in der Coinbase-Transaktion bezahlt.

https://ocean.xyz

Pool Fees
0% für die ersten 2 Monate des Betriebs, danach werden Gebühren eingeführt.

Settings

Pool URL

1️⃣ OCEAN, default (0% fee)
Enthält nur Transaktionen und relativ kleine Daten
mine.ocean.xyz:3334

2️⃣ Core+AntisMindestbetrag = 0.01048576 BTCpam (0% fee)
Enthält Transaktionen und begrenzten "Spam"
ordis.mine.ocean.xyz:3303

3️⃣ Core (2% fee)
Enthält Transaktionen und "Spam"
core.mine.ocean.xyz:3202

Username
bc1qDoNotShareYourBTCAdressWithAnyBodyElse.workername

Password
x

Welches Protokoll spricht welcher Pool? (V1, V2, DATUM)

Zum Abschluss der Übersicht noch der vielleicht wichtigste Punkt: Welches Protokoll ein Pool tatsächlich spricht, entscheidet darüber, wie viel Kontrolle ihr über euren Block habt und wie viel ihr dem Pool vertrauen müsst.

• CKpool / eusolo.ckpool – Stratum V1. Bewährt und schlank, aber Klartext, und der Pool baut das Template.
• Public Pool – Stratum V1 (die quelloffene Referenz). Unser Blitzpool läuft auf einer modifizierten Public-Pool-Variante und bietet zusätzlich eine SV2-Anbindung für Solo-Miner an.
• KanoPool – Stratum V1.
• OCEAN – setzt nicht auf SV2, sondern auf das eigene DATUM-Protokoll. DATUM geht bei der Zensurresistenz sogar noch weiter als SV2: Der Pool ist für euer Template blind (er sieht nur Merkle-Zweige, nicht eure Transaktionsliste) und kann es daher technisch gar nicht ablehnen – und ihr broadcastet den gefundenen Block selbst von eurem eigenen Node. Zensur wird damit architektonisch unmöglich, nicht nur per Richtlinie.
• Braiins / DEMAND – volles Stratum V2 inklusive Job Declaration, primär aufs gepoolte Mining ausgelegt.

Kurz gesagt: Für Heim-Solo-Miner war V1 lange der einzige Realfall – doch das ändert sich gerade rasant: Die NerdQaxe spricht SV2 bereits, die Bitaxe spricht es seit AxeOS 2.14 (Release am 4. Juni 2026). SV2 und DATUM sind die zukunftsweisenden, dezentralisierenden Optionen, sobald auch euer Pool mitspielt.

Hashrate-Marktplatz

Nicehash ist kein Mining-Pool, sondern ein Hashpower-Marktplatz, ihr bietest also eure Hashrate auf dem Marktplatz an und werdet von Nicehash nach überlieferten Shares bezahlt (PPS = Pay per Share).
Mit und ohne KYC möglich.

https://www.nicehash.com/

Auszahlungen
PPS
Nicehash-Wallet: 0.00001 BTC (alle 4 Stunden), Payout fee 2%
BTC-Adresse: 0.001 BTC (wöchentlich), Payout fee 2% + 0.00001 BTC
BTC-Adresse: 0.100 BTC (täglich), Payout fee 2% + 0.00001 BTC
🔗 https://www.nicehash.com/support/mining-help/earnings-and-payments/can-i-get-paid-to-an-external-wallet-address

Settings (ohne KYC)

Pool URL
stratum+tcp://sha256asicboost.auto.nicehash.com:9200

Pool URL Alternative
stratum+ssl://sha256asicboost.auto.nicehash.com:443

Username
bc1qDoNotShareYourBTCAdressWithAnyBodyElse.workername

Password
x

Auszahlungsschwelle diverser Pools beim Reward Mining

Die meisten Pools haben eine vielfach höhere Auszahlungsschwelle und bei kleinen Beträgen schlagen sie eine Payout fee drauf.

Braiins
▪️Mindestbetrag = 0.0002 BTC
▪️Bei Auszahlungen ab 0.005 BTC entfällt die Payout fee von 0.0001 BTC

Lincoin
▪️Mindestbetrag = 0.001 BTC
▪️Bei Auszahlungen ab 0.001 BTC entfällt die Payout fee.

Nicehash
▪️Nicehash-Wallet (KYC): 0.00001 BTC (alle 4 Stunden), Payout fee 2%
▪️BTC-Adresse: 0.001 BTC (wöchentlich), Payout fee 2% + 0.00001 BTC
▪️BTC-Adresse: 0.100 BTC (täglich), Payout fee 2% + 0.00001 BTC

TIDES
Mindestbetrag = 0.01048576 BTC
Rewards die unter diesem Schwellenwert liegen, werden akkumuliert, bis der Schwellenwert überschritten wird, dann erfolgt die Auszahlung automatisch.

Beispiele

Wenn ihr zB. bei Nicehash kein KYC macht und somit auf eure eigene BTC-Adresse ausbezahlen wollt, müsst ihr mit einer Bitaxe mind. 44 Monate schürfen (ohne Berücksichtigung der steigenden Difficulty) bis ihr die Schwelle von 0.001 BTC erreicht🥸

Mining in der Schweiz

Für die Schweizer-Pleb-Miner, hier gibt es je nach Kanton teilweise ganz eindeutige Formulierungen:

Betrieb von Hardware-Infrastruktur:
Das aktive Betreiben von Hardware-Infrastruktur wie Mining oder Nodes wird im Grundsatz als selbständige Erwerbstätigkeit betrachtet. Daher müssen Kursgewinne und Erträge aus Kryptowährungen gewinnsteuerlich berücksichtigt werden. Im Gegenzug können Aufwände, die direkt mit dem Betrieb der Infrastruktur zusammenhängen, sowie eventuelle Kursverluste steuerlich geltend gemacht werden.

Wieso werde ich von manchen Pools geblockt obwohl ich einen Asic Miner habe

Das hat eben nichts mit ASIC oder nicht ASIC zu tun, sondern mit der sehr sehr geringen Hashrate. Ein Miner mit 1 MH/s benötigt gleich viel Ressourcen von einem Stratum-Proxy-Server wie ein Miner mit 200 TH/s. Das ist der Grund wieso CPU-Miner bereits vor Jahren von den meisten Pools geblockt wurden … Und Nicehash sowie der KanoPool möchten offensichtlich auch keine Miner mit weniger als 1 (?) TH/s …

Mining Hardware Optimieren Beispiel Anhand der Bitaxe

Das Overclocking und Undervolting von Mining-Hardware wie der Bitaxe können die Leistung und Effizienz eures Miners ein gutes Stück beeinflussen. Durch Anpassen von Taktfrequenz und Spannung könnt ihr die Hashrate steigern oder den Energieverbrauch senken. Auf einem Miner wie der Bitaxe sind die Auswirkungen hier eher begrenzt, aber auf grösserer Hardware mit vielen Hashboards und Mining Chips kann dies grössere Auswirkungen haben.

Overclocking bedeutet, die Taktfrequenz des ASIC-Chips zu erhöhen, um eine höhere Hashrate zu erzielen. Bei der Bitaxe kann dies über das Interface erfolgen, indem die Frequenz und die Kernspannung angepasst werden. Overclocking kann bis zu einem gewissen Teil auch ohne Spannungserhöhung durchgeführt werden. Dies ist effizienter, da ein Anstieg der Spannung den Vebrauch im Quadrat ansteigen lässt.

Undervolting reduziert die Betriebsspannung des Chips, was den Energieverbrauch senkt und die Effizienz steigert. Dies kann jedoch die maximale Taktfrequenz verringern. Es erfordert sorgfältiges Testen, um die optimale Balance zwischen Leistung und Effizienz zu finden. Häufig kann man aber die Taktfrequenz um ein paar MHz steigern, und dabei die Spannung um 1 bis 2 Schritte reduzieren, und bekommt bei gleicher Leistungsaufnahme mehr Hashrate.

Jede Hardware reagiert unterschiedlich auf Overclocking und Undervolting. Faktoren wie Chipqualität bzw. die Chipgüte und Kühlung spielen eine Rolle. Daher ist es wichtig, schrittweise Anpassungen vorzunehmen und die Stabilität sowie die Temperaturen zu überwachen. Für die Bitaxen sollte die Temperatur 70 °C nicht überschreiten, um eine optimale Leistung zu gewährleisten.

Für größere Mining-Geräte bietet BraiinsOS eine fortschrittliche Firmware mit Funktionen wie Autotuning, das Frequenz und Spannung für jeden Chip individuell anpasst. Dies ermöglicht eine effizientere Leistung und kann die Lebensdauer der ASICs verlängern.

Zusammenfassend können Overclocking und Undervolting die Mining-Performance verbessern, erfordern jedoch sorgfältige Anpassungen und Überwachung, um optimale Ergebnisse zu erzielen. Ausserdem lässt sich sagen, dass durch die Erhöhung der Spannung des Chips, meisst die Effizienz des Geräts stark nachlässt, deshalb sollten die Taktfrequenzen nur leicht angehoben werden, und im Idealfall die Spannung etwas abgesenkt werden.

Zum Bitaxe Tutorial gehts hier:

Erklärung zu den wichtigsten Realtime Logs

In den Logs eures Miners findet ihr viele Zahlen, wilde Wörter, und Buchstaben, damit ihr wisst um was es geht, haben wir die wichtigsten Logs für euch hier zusammengefasst:

₿ (32308602) asic_result: Nonce difficulty 282.96 of 1024.
⬇️ Die Nonce-Difficulty ist kleiner als die aktuelle Work-Difficulty, weshalb der Share nicht an den Pool übermittelt wird.

₿ (32308702) asic_result: Nonce difficulty 1329.45 of 1024.
⬆️ Die Nonce-Difficulty ist grösser als die aktuelle Work-Difficulty, weshalb der Share an den Pool übermittelt wird.

₿ (32308702) stratum_api: tx: {"id": 3414, "method": "mining.submit", "params": ["bc1q██████████████████████████████████████.bitaxeultra", "3b5cd3", "11000000", "65b7c4f1", "6ccc021a", "10c70000"]}
🆙 Der Share wird mit "mining.submit" an den Pool übermittelt.

Bei der Übermittlung eines Shares werden gemäss Stratum Protokoll die folgenden Werte übermittelt:
id, userId, jobId, extraNonce2, ntime, nonce, versionMask

₿ (32308932) stratum_task: rx: {"id":3414,"error":null,"result":true}
ℹ️ Public Pool prüft den empfangenen Share auf Gültigkeit/Richtigkeit.

₿ (32308932) stratum_task: message result accepted
🆗 Public Pool bestätigt, dass der Share vom Pool akzeptiert wurde.

₿ (32301912) stratum_task: rx: {"id":null,"method":"mining.notify","params":["3b6238","708122a776e56322a64064232e31f3a7c5b8c7070002750f0000000000000000","02000000010000000000000000000000000000000000000000000000000000000000000000ffffffff19034da20c5c7075626c69632d706f6f6c5c","ffffffff02503eea26000000001600149f82dd9e69e0008b7c5e16b2056aa679723492580000000000000000266a24aa21a9ed0b9310bb435af0c678e749e1cbd11a5eb1a75be6f3e7e31908c6131770f0a82800000000",["…"],"20000000","1704005a","65b7c52e",false]}
🆕 Public Pool verteilt mit "mining.notify" ein neues Block Template "3b6238" , entweder weil die Transaktionen aktualisiert wurden oder weil das Netzwerk einen neuen Block gefunden hat.

Bei der Übermittlung eines Block Template werden gemäss Stratum Protokoll die folgenden Werte übermittelt:
jobId, prevHash, coinbase part1, coinbase part2, merkle_branch, version, bits, timestamp, clear jobs

₿ (32302562) create_jobs_task: New Work Dequeued 3b6238
🆕 Nachdem das neue Block Template "3b6238" empfangen wurden, beginnt die Suche auf dieser neuen Grundlage.

₿ (260107) stratum_task: rx: {"params":[385],"id":null,"method":"mining.set_difficulty"}
₿ (260107) stratum_task: Set stratum difficulty: 385
↕️ Die Work-Difficulty wird für den Worker angepasst, damit die Zielvorgabe vom Pool betreffend Shares pro Minute erreicht wird.

Fazit

Die Welt des Minings ist komplex, aber zugleich faszinierend und voller Möglichkeiten. Mit dieser Mining-Bibel habt ihr die wichtigsten Grundlagen und Konzepte kennengelernt, um selbstständig ins Solomining einzusteigen. Angefangen bei der Funktionsweise der Blockchain über die Bedeutung von Hashrate, Shares und Difficulty bis hin zu den praktischen Aspekten wie Block Templates, Mining-Pools und der Anpassung eurer Hardware – dieses Wissen bildet ein solides Fundament für euren Erfolg.

Das Mining von Bitcoin ist weit mehr als nur ein technischer Prozess. Es ist ein Beitrag zu einem globalen, dezentralen Netzwerk, das Finanztransaktionen ohne zentrale Instanzen ermöglicht. Dabei könnt ihr nicht nur von finanziellen Belohnungen profitieren, sondern auch Teil einer Bewegung werden, die auf Freiheit und Unabhängigkeit setzt.

Denkt daran, dass Geduld und kontinuierliches Lernen essenziell sind. Die Technologie entwickelt sich stetig weiter, und der Wettbewerb wird immer anspruchsvoller. Doch mit der richtigen Einstellung, den richtigen Werkzeugen und der hier vermittelten Expertise seid ihr gut gerüstet, um euren Weg im Mining zu gehen.

Mögen eure Hashrate stark, eure Hardware stabil und eure Blöcke erfolgreich sein! Viel Erfolg und Spaß beim Mining! 🚀

Lust auf's Solomining? Schaut mal hier vorbei:

https://yourdevice.ch/produkt-kategorie/btc-nodes-zubehoer

The post Die kleine Bitcoin Solo Mining Bibel appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist der Unterschied zwischen BTC und LN BTC

Bitcoin (BTC) basiert auf der Haupt-Blockchain, die Transaktionen weltweit dezentral und sicher verarbeitet. Dieser Prozess stellt sicher, dass jede Transaktion transparent und unumkehrbar ist, bringt jedoch eine relativ lange Bestätigungszeit und Netzwerkgebühren mit sich, die je nach Nachfrage erheblich schwanken können. Diese Merkmale machen BTC besonders sicher, aber für alltägliche, schnelle Transaktionen weniger ideal.

Lightning-Bitcoin (LN BTC) hingegen läuft über das Lightning Network – eine „zweite Ebene“ (Layer-2) des Bitcoin-Netzwerks. Hierbei werden Zahlungen in „Payment Channels“ abgewickelt, ohne dass jede Transaktion direkt auf der Bitcoin-Blockchain aufgezeichnet wird. Das reduziert die Gebühren erheblich und macht LN BTC extrem schnell – oft in Sekundenschnelle. Erst wenn ein Kanal geschlossen wird, wird der endgültige Saldo in einer einzigen on-chain Transaktion auf der Bitcoin-Blockchain festgeschrieben.

Die Methoden für den Transfer

Schauen wir uns nun die schnellsten und besten Methoden an, wie man seine BTC in Lightning BTC umwandeln kann!

1. Phoenix Wallet – Nahtlos und unkompliziert

Eine der einfachsten Methoden, um Bitcoin in Lightning BTC zu wechseln, ist die Phoenix Wallet. Diese Wallet ist besonders nutzerfreundlich und eignet sich sowohl für Einsteiger als auch für fortgeschrittene Nutzer. Der Vorteil von Phoenix liegt darin, dass sie on-chain Bitcoin automatisch in Lightning BTC umwandelt, sobald du eine Lightning-Adresse als Ziel angibst. Dafür müsst ihr zuerst ein paar Onchain BTC auf die BTC Wallet der Phoenix Wallet laden:

Vorteile

• Automatische Konvertierung: Ihr sendet Bitcoin Onchain Guthaben an die Phoenix Wallet, und die Phoenix Wallet wird euch automatisch anbieten, einen entsprechenden Kanal zu eröffnen, um euch Lightning Guthaben zu erstellen wenn ihr eine Lightning Invoice bezahlen möchtet.
• Nutzerfreundlich: Die App ist relativ einfach zu bedienen und nimmt euch den technischen Aufwand ab Lightning Kanäle zu verwalten
• Geringe Gebühren: Die Umwandlung erfolgt zu fairen Gebühren.

Nachteile

• Nur mobile App: Phoenix ist nur als App für mobile Geräte verfügbar, was die Nutzung am Desktop einschränken kann.
• Push Voraussetzung: Funktioniert nur mit Phones auf dem Google Play installiert ist, auf GrapheneOS Phones mit Sandboxed Google Play oder auf Calyx Phones mit Micro-G

Eine Anleitung zur Phoenix Wallet findet ihr hier!

2. Pocket Bitcoin Lightning – Direkt von Fiat zu Lightning

Pocket Bitcoin bietet einen Service an, bei dem ihr Bitcoin direkt mit Fiat-Geld kaufen und an eine Lightning-Wallet senden könnt. Am besten eignen sich dabei die Phoenix, und die Breez Wallet. Der Umweg über on-chain Bitcoin entfällt hier komplett, da Pocket Bitcoin eure gekauften Bitcoin direkt als LN Bitcoin zurücksendet. Dies spart Zeit und Gebühren, da ihr den Umwandlungsprozess umgeht.

Vorteile

• Direkter Kauf in Lightning: Ihr kauft mit Fiat direkt Lightning-Bitcoin, ohne zuerst on-chain Bitcoin zu erhalten.
• Kein Umwandlungsprozess: Dieser Weg spart Zeit und Gebühren, da kein zusätzlicher Wechsel nötig ist.
• Einfacher Kaufprozess: Pocket Bitcoin bietet eine benutzerfreundliche Oberfläche, die den Kaufprozess angenehm macht.

Nachteile

• Fiat-Einschränkungen: Die Verfügbarkeit des Dienstes ist abhängig vom Land und den angebotenen Zahlungsmethoden. Ausserdem kann pro Monat seit 2025 nur bis zu 1000CHF in BTC/Lightning umgewandelt werden, danach fällt ein KYC Prozess an.

Anleitung dazu hier: https://pocketbitcoin.com/de/learn/lightning/top-up-lightning-wallet

3. Boltz – Ohne Registrierung und schnell

Boltz ist ein Non-Custodial-Exchange-Service, der es euch erlaubt, ohne Registrierung und ohne KYC (Know Your Customer) Bitcoin gegen Lightning-Bitcoin zu tauschen. Boltz bietet sogenannte "Atomic Swaps" an, bei denen ihr eure Bitcoin on-chain einzahlen und im Gegenzug Lightning-Bitcoin erhalten könnt. Ihr könnt eure LN BTC danach an eine Lightning Wallet eurer Wahl schicken, indem ihr einfach zuerst mit der Wallet eine Invoice in einer gewünschten höhe erstellt, und danach in das Invoice Fenster von Boltz kopiert. Boltz fordert euch dann auf, die umgerechnete Menge an BTC an den Dienst zu senden.

Vorteile

• Keine Registrierung: Ihr benötigt kein Benutzerkonto und könnt den Service völlig anonym nutzen.
• Schnelle Abwicklung: Die Konvertierung erfolgt schnell, sobald eure on-chain Bitcoin in einer Transaktion bestätigt wurden.
• Privatsphäre: Da keine KYC-Verifizierung erforderlich ist, bietet Boltz hohe Anonymität.

Nachteile

• Transaktionsgebühren: On-chain Transaktionen verursachen immer Netzwerkgebühren, die zusätzlich zu den Wechselgebühren anfallen.
• Servicegebühren - die Nutzung des Services beinhaltet zudem eine Service Gebühr, die in der Regel um die 0.1% beträgt.

Der Link zur Boltz Exchange: https://boltz.exchange/

4. Breez Wallet – Integrierte Dienste und einfache Konvertierung

Die Breez Wallet ist eine weitere beliebte Lightning-Wallet, die es euch erlaubt, direkt von Bitcoin zu Lightning BTC zu wechseln. Breez ermöglicht es euch, Bitcoin On-chain zu empfangen und diese in eurer Wallet zu halten, und danach sie direkt ins Lightning-Netzwerk zu übertragen. Die App eröffnet für euch selbstständig Lightning Kanäle ähnlich wie die Phoenix Wallet.

Vorteile

• Integrierte Funktionalität: Ihr könnt nahtlos zwischen Bitcoin und Lightning-BTC wechseln.
• Zahlreiche Zusatzfunktionen: Breez bietet integrierte Dienste wie Point of Sale (POS) für Händler.
• Open Source: Die App ist quelloffen, was sie transparent und sicher macht.
• Keine Push; Push ist nicht notwendig wie bei der Phoenix Wallet
• Kleinere Gebühren: Die Umwandlung zwischen on-chain und Lightning kosten Gebühren.

Nachteile

• soweit keine

Anleitung dazu hier: https://coincharge.io/en/breez-wallet/

5. Blue Wallet – Einfacher In-App-Swap

Die Blue Wallet ist besonders für ihre einfache Bedienung bekannt und erlaubt es Nutzern, Bitcoin sowohl on-chain als auch off-chain (Lightning) zu verwalten. Der In-App-Swap ermöglicht es, on-chain Bitcoin direkt in Lightning-BTC umzuwandeln. Dazu müsst ihr aber via LNDHub eine Lightning Wallet verbinden. Danach könnt ihr auf der Lightning Wallet auf Manage Funds, und wählt anschliessend Refill als Option. Es müssen ein paar BTC auf die BTC Wallet vorher überwiesen worden sein. Für die Lightning Wallet bietet sich unsere LNBits Wallet an.

Vorteile

• Einfacher Swap: Die Blue Wallet macht es sehr einfach, zwischen den beiden Netzwerken zu wechseln.
• Benutzerfreundlich: Dank der simplen Oberfläche ist die Wallet besonders einsteigerfreundlich.
• Multi-Wallet-Unterstützung: Ihr könnt mehrere Wallets erstellen und verwalten.

Nachteile

• Custodial: Die Lightning-Funktion der Blue Wallet ist custodial, d.h., ihr vertraut eure Lightning-Funds dem Betreiber der Wallet an.

Anleitung dazu hier: https://bluewallet.io/lightning/

6. Umtausch via Exchange

Habt ihr euch bei einer Exchange angemeldet, zum Beispiel Kraken, Bitfinex, Binance oder etc, könnt ihr natürlich auch dort BTC kaufen, und diese direkt über die Plattform in LN-BTC umwandeln. Dazu müsst ihr die Swap Tools verwenden, eure BTC in LN-BTC tauschen, und diese dann per Invoice an eure Wallet auszahlen lassen. Eine Anleitung wie das ungefähr aussieht, findet ihr hier ebenfalls im Phoenix Tutorial an Ende des Beitrags.

Vorteile

• relativ einfache Handhabung
• schnelle Swaps
• praktisch kostenlose Swaps möglich
• Auszahlung ebenso fast kostenlos
• hohe Liquidität

Nachteile

• Anmeldung und KYC auf der Börse notwendig
• tägliche Auszahlungslimite, danach Meldung der Transaktionen aufgrund der Travelrule

7. Robosats

Robosats bietet euch eine anonyme Möglichkeit, ohne KYC Fiat Money in LN Bitcoin umzutauschen. Es gibt eine TOR Seite von Robosats, es benötigt keinerlei Anmeldungen, auch nicht mit einer Email, und das ganze funktioniert über Session-Tokens. Allerdings ist die Handhabung etwas kompliziert. Dazu gibt es eine Art Orderbook, und es gibt teilweise höhere Aufschläge auf den üblichen Marktpreis. Die LN-BTC könnt ihr danach an via Invoice an eine Wallet eurer Wahl senden. Ein Anleitung findet ihr dazu hier.

Vorteile

• KYC-frei und anonym
• sicher durch Escrow Verfahren
• keine Anmeldung erforderlich
• mehre Zahlungsmethoden möglich

Nachteile

• etwas komplex in der Anwendung
• hohe Auschläge zum üblichen Marktpreis
• eher geringe Liquidität vorhanden

Fazit

Es gibt verschiedene Wege, um Bitcoin in Lightning BTC umzuwandeln – von Wallets wie Phoenix und Breez, die den Prozess nahtlos und einfach machen, über anonyme Dienste wie Boltz, bis hin zu direktem Kauf über Pocket Bitcoin. Welche Methode die beste für euch ist, hängt davon ab, wie ihr eure Bitcoin verwalten möchtet, ob euch Privatsphäre wichtig ist und welche Gebühren ihr in Kauf nehmen möchtet.

Für schnelle und unkomplizierte Umwandlungen sind Phoenix und Boltz besonders geeignet, während Pocket Bitcoin die ideale Lösung ist, wenn ihr direkt mit Fiat in Lightning einsteigen möchtet.

Probiert die Methoden aus und findet heraus, welche am besten zu euch passt!

The post Die schnellsten Möglichkeiten Bitcoin in Lightning BTC umzuwandeln appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Das Tutorial eignet sich sowie für den Raspiblitz, also auch für Umbrel, Start9, und MyNode Fullnode Betriebssysteme.

Vorausetzungen

Bevor ihr beginnt, stelle sicher, dass ihr folgende Dinge vorbereitet habt:

Computer mit Platz für 2 SSDs

• Ihr benötigt einen freien Computer, bzw. eine Arbeitsgerät, an dem ihr die 2 SSDs anklemmen könnt. Das kann auch ein Laptop sein, mit dem ihr die 2 SSDs via USB to SSD Adapter anschliesst.

GParted Live USB:

• Ladet das GParted Live-ISO von der offiziellen GParted Webseite herunter.
• Erstellt einen bootfähigen USB-Stick mit Rufus oder Balena Etcher.

SSD einbauen:

• Schließt beide SSDs an euren Rechner an.

Optional: Backup:

• Erstellt ein Backup der ersten SSD falls ihr auf Nummer sicher gehen wollt.

Vorbereitung

System vom GParted Live USB-Stick booten:

• Starte den Rechner neu und boote von deinem GParted Live USB-Stick. Achte darauf, im BIOS/UEFI den USB-Stick als erstes Bootmedium einzustellen.

GParted starten:

Im GParted Live-Boot-Menü wählt die Standardoptionen aus, bis ihr zur grafischen Oberfläche gelangt. Stellt sicher, dass ihr das richtige Tastaturlayout verwendet:

Wählt im nächsten Fenster eure Sprache aus, Deutsch ist in den meissten Fällen die Nummer 10. Nehmt danach den Modus 0:

Klonen der Partitionen

Quelllaufwerk auswählen

• Wählt die 1TB SSD aus dem Dropdown-Menü oben rechts in GParted aus. Ihr solltet die Partition(en) eurer 1TB SSD sehen.

Partition(en) kopieren

• Wählt die Partition, die ihr klonen möchtet (normalerweise die Hauptpartition mit euren Blockchaindaten und Diensten), und klickt mit der rechten Maustaste darauf. Wählt copy.

Ziellaufwerk auswählen

• Geht jetzt zur 2TB SSD im Dropdown-Menü. Klickt mit der rechten Maustaste auf den nicht zugewiesenen Speicherplatz auf der 2TB SSD und wählt paste.

Sollte auf der Ziel SSD bereits eine Partition bestehen, wählt diese einfach vorher aus, und löscht diese.

Anpassung der Partitiongrösse

Als nächst bekommt ihr ein Feld zu sehen, auf dem ihr die Partition gleich auf die Grösse der neuen SSD anpassen könnt:

Pakt den markierten Pfeil, und schiebt die neue Partition auf die volle Grösse der SSD. Klickt danach auf Paste.

Startet den Kopiervorgang mit dem grünen Haken:

Überprüfung und Testing

Hängt die neue SSD einfach an euren Raspiblitz an, er sollte automatisch alles erkennen, und dort weitermachen, wo er aufgehört hat. Anpassungen eurerseits sind nicht nötig.

Fazit

Mit GParted könnt ihr den Klonvorgang von einer 1TB auf eine 2TB SSD direkt und ohne zusätzliche Tools durchführen. Dies spart Zeit und erlaubt euch, alle notwendigen Schritte – vom Klonen bis zur Partitionserweiterung – in einer einzigen, vertrauten Umgebung durchzuführen. Indem ihr die Partition nach dem Klonen vergrößerst, stellt ihr sicher, dass ihr die volle Kapazität der neuen SSD nutzen könnt, sodass eure Blockchaindaten und Dienste weiterhin optimal funktionieren.

The post Fullnode 1TB SSD auf 2TB SSD klonen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist Satoshis Kleinanzeigen?

Satoshis Kleinanzeigen ist eine Online-Plattform, die es ihren Nutzern ermöglicht, Waren und Dienstleistungen im Peer-to-Peer-Stil zu handeln, ähnlich wie bei traditionellen Kleinanzeigenportalen. Der große Unterschied? Hier wird ausschließlich mit Bitcoin gehandelt. Die Plattform vereint die Anonymität und Sicherheit von Bitcoin mit den Vorteilen eines lokalen Marktplatzes, der ohne Zwischenhändler oder Banken auskommt. Die Idee dahinter ist simpel: Käufer und Verkäufer können sich direkt miteinander verbinden und Zahlungen in Bitcoin abwickeln, ohne auf zentrale Plattformen oder Zahlungsdienstleister angewiesen zu sein.

Peer-to-Peer Plattform

Da es sich um eine Peer-to-Peer-Plattform handelt, liegt die Verantwortung für die Sicherheit und die Abwicklung der Transaktionen direkt bei euch. Um Betrug zu vermeiden, können verschiedene Sicherheitsmechanismen genutzt werden, wie z. B. Treuhandservices, bei denen das Bitcoin-Guthaben eines Käufers erst freigegeben wird, wenn die Ware erhalten wurde. Dies gibt sowohl Käufern als auch Verkäufern ein gewisses Maß an Vertrauen in die Plattform.

Funktionen und Vorteile von Satoshis Kleinanzeigen

• Zahlungen in Bitcoin: Die Plattform ermöglicht ausschließlich Zahlungen in Bitcoin, was insbesondere für Krypto-Enthusiasten attraktiv ist, die eine Alternative zu herkömmlichen Fiat-Währungen suchen. Durch die Nutzung von Bitcoin entfällt die Notwendigkeit, sich mit Banken oder anderen zentralen Finanzinstitutionen auseinanderzusetzen.
• Privatsphäre und Anonymität: Anders als bei traditionellen Plattformen müssen Nutzer bei Satoshis Kleinanzeigen keine sensiblen persönlichen Daten preisgeben. Lediglich eine Bitcoin-Wallet-Adresse und eine Lightning Wallet sind nötig, um Transaktionen durchzuführen. Dies garantiert ein hohes Maß an Privatsphäre. Der Login is direkt über die eigene Lightning Node möglich.
• Gebührenfrei: Die Plattform ist grundsätzlich gebührenfrei, die User handeln untereinander und einigen sich über den Preis.

Herausforderungen und Zukunftsperspektiven

Obwohl Satoshis Kleinanzeigen zahlreiche Vorteile bietet, gibt es auch einige Herausforderungen, die die Plattform bewältigen muss. Eine der größten Hürden ist die allgemeine Akzeptanz von Bitcoin im Alltag. Während immer mehr Menschen Kryptowährungen nutzen, bleibt Bitcoin für viele immer noch ein Investment-Asset, anstatt eines tatsächlichen Zahlungsmittels. Die meissten Nutzer zögern immer noch, ihre Sats auszugeben, da die Hoffnung auf steigende Kurse im Vordergrund steht.

Ein weiteres potenzielles Problem ist die Anonymität der Nutzer. Obwohl diese ein Vorteil für den Schutz der Privatsphäre ist, kann sie auch von Betrügern ausgenutzt werden. Hier könnten verbesserte Sicherheitsmaßnahmen, wie z. B. Verifizierungen oder Bewertungen von Nutzern, in Zukunft eine Rolle spielen und die Handelssicherheit verbessern.

Nichtsdestotrotz bietet Satoshis Kleinanzeigen eine vielversprechende Alternative zu herkömmlichen Handelsplattformen und hat das Potenzial, besonders in der Krypto-Community Fuß zu fassen. Mit der wachsenden Akzeptanz von Bitcoin als Zahlungsmittel und dem steigenden Bewusstsein für die Vorteile dezentraler Plattformen könnte Satoshis Kleinanzeigen ein Vorreiter für den Handel in der digitalen Ära werden.

Nutzung von Satoshis Kleinanzeigen

Um Inserate anbieten zu können, müssen sich Nutzer aktuell mit einer Lightning Wallet anmelden. Klickt dazu oben rechts auf das Profilbild, und scannt dazu einfach mit einer Lightning Wallet eurer Wahl den Login-Code, und ihr werdet anhand eurer Private Keys eurer Lightning Wallet authentifziert. Diese Login-Methode nennt sich LN-Auth, und ist sicherer und zudem privater als jedes Google Login. Es funktionieren alle gängigen Lightning Wallets, wie zum Beispiel die Phoenix Wallet, die Wallet of Satoshi, die Breez Wallet sowie auch eine Alby oder Strike Wallet mit Lightning Funktion. Natürlich könnt ihr auch eure eigene Lightning FullNode für die Authenfizierung verwenden. Nach der erfolgreichen Authenfizierung, könnt ihr auch schon direkt Inserate erstellen.

Profil bearbeiten

Bevor ihr loslegen könnt, ist es am schlausten, sich sein Profil kurz zurecht zu machen. Klickt auf das Profilbild und geht auf Profil bearbeiten.

Ihr legt am besten ein Profilname fest, und fügt euren Telegram Link im Format @euer_tg_name hinzu damit man euch kontaktieren kann. Ein Profilbild kann genutzt werden, muss aber nicht. Eine Email Adresse kann optional auch angegeben werden. Klickt danach auf Profil Speichern.

Inserat erstellen

Auf oben in der Toolleiste findet ihr unter INSERIEREN ihr auch gleich die Funktion, um Inserate zu erstellen. Wählt die Option und lasst uns ein neues Inserat erstellen:

Fügt ein paar Bilder hinzu, gebt dem Produkt eine entsprechende Bezeichnung und Beschreibung, und setzt ein paar passende Hashtags. Danach kann noch der Angebotstyp festgelegt werden. Möglich sind beginnt bei, Festpreis, oder Verhandlungsbasis. Legt einen Preis in Satoshis fest, und wählt ob der Preis inklusive, oder exklusive Versand ist. Danach noch die entsprechende Kategorie wählen, und schon ist das Inserat fertig!

Das Inserat wird von den Admins noch geprüft, und danach, sollte es keine illegale Inhalte beinhalten, freigegeben. Ihr findet es danach unter den vorhandenen Inseraten.

Selber etwas kaufen

Dazu muss eigentlich nicht viel gesagt werden, da es ziemlich selbsterklärend ist. Durchstöbert die Inserate, und sucht euch etwas nettes aus. Danach könnt ihr den Inserent durch die bereit gestellten Kontaktmöglichkeiten kontaktieren.

Ein paar Sicherheitshinweise zum Handeln

Der Handel, Kauf und Verkauf basiert auf Satoshis Kleinanzeigen rein auf Vertrauen. Das hört sich zuerst gefährlich an, jedoch kommt es wirklich selten vor, dass Betrüger unterwegs sind. Die Bitcoin Community ist wirklich vertrauensvoll. Ich selber kaufe, und verkaufe immer mal wieder was auf Satoshis Kleinanzeigen, und benutze dabei auch meinen gesunden Menschenverstand. Hier ein paar Tipps für einen sicheren handeln:

• Seid kritisch wenn euch das Gegegenüber schnell zu Zahlungen auffordert, da er beispielsweise schnell weg muss und den Handel schnell über die Bühne bringen möchte.
• bevorzugt bei grösseren Beträgen lieber ein persönliches Treffen
• Schätzt die Art und Weise, wie der Gegenüber kommuniziert ein, wie bereits erwähnt, sind Zeit-Limits, Druck und Stress kein gutes Zeichen.
• Lasst euch Bilder der Waren schicken, oder bei Unsicherheit auch ein Ausweis des gegenübers.
• Solltet ihr über Telegram kommunzieren, checkt doch mal, ob das Gegenüber in bekannten Bitcoin Gruppen ist (Raspiblitz & Raspiblitz German, PlebNet, Nodestrich) und etc. Das erhöht das Vertrauen gleich um einiges.

Spenden an Satoshis Kleinanzeigen

Das Projekt wird quasi nur mit eigenen Ressourcen finanziert, in der Freizeit entwickelt, und ist deshalb auf Spenden der Nutzer und Anwender angewiesen. Satoshis Kleinanzeigen ist eine Graswurzel-Bewegung. Getrieben von der Leidenschaft, Bitcoin in der Praxis zu erproben, sind die Mitglieder eng vernetzt und handeln bereits aktiv miteinander. Das langfristiges Ziel ist die Entwicklung eines dezentralen Marktplatz-Protokolls, das als echte Alternative zu den mächtigen, zentralen Plattformen dient. Um weitere Funktionen wie eine User Bewertung, einen Treuhand-Service, oder weitere Ideen zu entwickeln und auch zu integrieren, braucht das Projekt eure Unterstützung. Die Betreiber und das Team, würden sich deshalb um eine Spende freuen!

Fazit

Satoshis Kleinanzeigen ist eine innovative Plattform, die die Möglichkeiten von Bitcoin voll ausschöpft. Sie bietet euch die Freiheit, Waren und Dienstleistungen ohne die Einmischung von Dienstleistern die horrende Gebühren kassieren, Banken oder zentralen Behörden zu handeln und garantiert dabei ein hohes Maß an Privatsphäre. Trotz der bestehenden Herausforderungen hat die Plattform das Potenzial, in einer Welt, die zunehmend auf Dezentralität und digitale Währungen setzt, eine wichtige Rolle zu spielen.

Für alle Bitcoin-Enthusiasten, die nach einer einfachen Möglichkeit suchen, mit ihrer bevorzugten Kryptowährung zu handeln, ist Satoshis Kleinanzeigen auf jeden Fall einen Blick wert!

The post Satoshis Kleinanzeigen - Die Bitcoin Handelsplattform appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dank des eingebauten WiFi-Mikrocontrollers (ESP32-S3-WROOM-1) lässt sich die Bitaxe einfach in eures Netzwerk integrieren und mit eurem bevorzugten Mining-Pool verbinden. Wir schauen uns in diesem Artikel die Einrichtung und Anwendung der Bitaxe an. Das BitaxeOS ist OpenSource, und der Sourcecode kann auf Github betrachtet werden.

Die Bitaxen sind echte Vorreiter, da sie vollständig montiert und einsatzbereit geliefert werden. So wird der Einstieg in das Bitcoin-Mining zu einem Kinderspiel. Dank der intuitiven Benutzeroberfläche von AxeOS könnt ihr sofort mit dem Mining beginnen, ohne euch mit komplexen Konfigurationen auseinandersetzen zu müssen.

Welche Bitaxe passt zu mir? Die Modelle im Überblick (2026)

Die Bitaxe gibt es in mehreren Varianten, die sich vor allem im verbauten ASIC-Chip und damit in Hashrate und Effizienz unterscheiden. Aktuell (Stand 2026) ist die Gamma mit dem modernen BM1370-Chip das Flaggschiff und die effizienteste Einzelchip-Variante. Hier die gängigen Modelle im Vergleich:

Für die meisten Einsteiger ist die Bitaxe Gamma die beste Wahl: höchste Hashrate pro Chip bei der besten Effizienz. Wer mehrere Geräte leise und sparsam betreiben möchte („Swarming“, dazu unten mehr), fährt mit der Supra gut. Die folgende Einrichtung ist bei allen Modellen praktisch identisch, da sie alle dieselbe AxeOS-Firmware nutzen.

Vorbereitungen und Voraussetzungen

Ihr benötigt eigentlich nur einen Platz mit möglichst gutem 2.4Ghz WLAN Empfang. 5Ghz unterstützt das Gerät leider nicht. Die Reichweite ist bei 2.4Ghz meisst auch höher, und die Verbindung ist zuverlässiger und stabiler, wenn auch nicht so schnell, und von den Latenzen halt auch etwas höher.

Des weiteren benötigt ihr zudem ein Smartphone um die erste Verbindung zur BitAxe herzustellen.

Einrichtung und Anwendung der Bitaxe

Gerät anschließen

Schließt das Netzteil an die Bitaxe an und verbindet es mit einer Stromquelle. Es gibt keinen An- und Ausschalter. Das Gerät startet automatisch, sobald es mit Strom versorgt wird.

Verbindung zum Access Point herstellen

Der erste Start erfolgt über das WLAN Access Point des Geräts.

Sucht in eurem WLAN nach dem Access Point der Bitaxe. Der Name des Netzwerks (SSID) ist auf dem Gerät Display zu sehen.

Verbindet euch mit diesem WLAN. Es ist kein Passwort erforderlich, da es sich um einen offenen Access Point handelt.

Konfiguration über Captive Portal

Nachdem ihr euch mit dem Access Point verbunden habt, öffnet sich automatisch ein Captive Portal (ähnlich wie in Hotels oder öffentlichen Netzwerken).

Geht in den Reiter Network des Geräts. Gebt hier die SSID eures Heim- oder Unternehmensnetzwerks sowie das Passwort ein, um die Bitaxe in euer WLAN zu integrieren. Speichert die Einstellungen und startet das Gerät über das Interface ganz unten neu.

Hinweis: Ab Version 2.6.1 ist es neu das WLAN über die Lupe zu suchen, das Gerät scannt dann automatisch alle WLANs, und ihr könnt das richtige dann einfach mit einem klick auswählen, anstatt die SSID manuell einzugeben.

Zugriff auf die Benutzeroberfläche

Nach dem Neustart verbindet sich die Bitaxe mit eurem WLAN. Um auf das Dashboard zuzugreifen, ermittelt die IP-Adresse des Geräts (entweder über den Router oder einen IP-Scanner)

Öffnet euren Browser und gebt die IP-Adresse ein. Für das Webinterface ist kein Passwort erforderlich.

Pool- und Wallet Konfiguration

Im Dashboard in den Poolsettings findet ihr die "Pool-Einstellungen".

Pool ändern: Ihr könnt unseren gebührenfreien Schweizer Pool `blitzpool.yourdevice.ch` auf Port 3333 verwenden. Tragt diese Informationen in die entsprechenden Felder ein. Ihr könnt natürlich jeden anderen Pool eurer Wahl nehmen.

Wallet-Adresse: Löscht die Standard-Bitcoin-Adresse und fügt eure eigene Bitcoin-Adresse ein, um sicherzustellen, dass die Mining Belohnungen direkt an euch ausgezahlt werden. Nutzt eine Bitcoin Adresse von einer Hard- oder Softwarewallet eurer Wahl. Wählt ein Passwort damit ihr eure Statistiken auch auf https://blitzpool.yourdevice.ch einsehen könnt.

Hinter eure BTC Adresse könnt ihr einen Namen anhängen. Somit lassen sich bestimmte Worker Gruppen erstellen. Eine bestimmte Gruppe aus Minern kann damit erstellt werden. Das geht indem ihr hintere eure BTC Adresse einen Namen anhängt, separiert mit einem Punkt. Somit lassen sich bestimmte Worker Gruppen erstellen. Eine Kombination aus Minern könnte zum Beispiel so aussehen:

bc1qnu7xxxxxxxxxxxxxxxxxxxxxxptez73ch4.bitaxe heissen, eine weitere zum Beispiel
bc1qnu7xxxxxxxxxxxxxxxxxxxxxxptez73ch4.nerdminer

So lassen sich die Geräte voneinander trennen. Der Reward geht natürlich immer noch an die selbe BTC-Adresse.
In den Pool Statistiken tauchen die Geräte dann gruppiert und den jeweiligen Workernamen auf.

Damit die Einstellungen wirksam werden, müsst ihr unten auf Save klicken, und dann links in der Einstellungsleiste Restart auswählen.

Fallback Pool definieren: Seit dem Update auf die Version 2.3.0 könnt, oder ist ein Fallback Pool definiert. Falls der Primary Pool ausfällt, mint die Bitaxe im automatisch im Fallback Pool weiter.

Stratum V1 oder V2

Neu könnt ihr in den Pool-Einstellungen zwischen Stratum V1 (SV1) und dem moderneren Stratum V2 (SV2) wählen. SV2 verschlüsselt die Verbindung zwischen Miner und Pool (Schutz vor Man-in-the-Middle-Angriffen), kommt mit deutlich weniger Datenverkehr aus und erlaubt es Minern perspektivisch, ihre Blockvorlage selbst zu bestimmen – ein wichtiger Schritt für mehr Dezentralisierung im Bitcoin-Netzwerk. Die Hintergründe haben wir im Beitrag Stratum V2 – Warum das Bitcoin-Mining ein neues Protokoll braucht ausführlich erklärt.

Für SV2 benötigt ihr neben Host und Port zusätzlich den Authority Key (den Public Key des Pools). Zwei empfehlenswerte SV2-Pools:

• Blitzpool (unser Schweizer Solo-Pool, 0 %) – Host blitzpool.yourdevice.ch, Authority Key:
  9bCoFxTszKCuffyywH5uS5o6WcU4vsjTH2axxc7wE86y2HhvULU
  Die vollständigen Verbindungsdaten findet ihr auf blitzpool.yourdevice.ch/stratum-v2.
• Braiins Pool (gepoolt, die Entwickler von Stratum V2) – Host stratum-v2.braiins.com, Port 3336, Authority Key:
  u95GEReVMjK6k5YqiSFNqqTnKU4ypU2Wm8awa6tmbmDmk1bWt
  Aktuelle Werte stets in der offiziellen Braiins-Anleitung prüfen.

Übernehmt eure Auswahl wie gewohnt mit SAVE und einem anschliessenden RESTART. Im Zweifel funktioniert SV1 nach wie vor problemlos – SV2 ist die zukunftssichere, aber optionale Wahl.

Welchen Mining-Pool für die Bitaxe wählen?

Mit einer Bitaxe minet man in der Regel solo – ihr nehmt also an einer Art Lotterie teil: Die Chance, einen ganzen Block zu finden, ist klein, dafür erhaltet ihr im Erfolgsfall die komplette Block-Belohnung. Dass das kein reines Märchen ist, zeigt der erste mit einer Bitaxe Supra solo gefundene Block #887.212 im März 2025. Für das Solo-Mining haben sich diese Pools etabliert:

• Blitzpool – unser eigener Schweizer Public-Pool (auf Basis der quelloffenen Public-Pool-Software). 0 % Gebühren, übersichtliche Statistiken und dank Serverstandort Schweiz niedrige Latenz für CH/EU. Stratum: stratum+tcp://blitzpool.yourdevice.ch:3333
• eusolo.ckpool.org – die EU-Variante von Con Kolivas’ ckpool (eigener Server in der EU seit Ende 2024, dadurch deutlich geringere Latenz als das originäre solo.ckpool.org). 2 % Gebühr im Erfolgsfall.
• Public Pool – der originale, quelloffene Public-Pool. 0 % Gebühren und sogar selbst hostbar – genau die Software, auf der auch unser Blitzpool läuft.

Bevor ihr euch realistische Erwartungen setzt, lohnt sich ein Blick in unsere Beiträge Solo Mining – die grössten Fehlannahmen und Die kleine Bitcoin Solo Mining Bibel. Wer lieber regelmässige Kleinauszählungen statt der Lotterie möchte, findet im Artikel Bitcoin Mining Pool die Alternative.

Mining starten

Der Miner startet automatisch, sobald die Pooleinstellungen korrekt eingegeben und gespeichert wurden sind. Seht ihr keine Hashrate, stimmt was mit euren Pool-Einstellungen nicht.

Unten findet ihr noch Informationen zum aktuellen Stromverbrauch, der ASIC Spannung, der Lüfterdrehzahl und der aktuellen Temperatur des Chips

Leistungsoptimierung

Passt die Mining-Einstellungen wie Hashrate, Spannung und Lüftergeschwindigkeit an. Es ist ratsam, zunächst mit den Standardeinstellungen zu beginnen. Es sei gesagt dass man durch Overclocking das Gerät beschädigen kann, und dass man dadurch natürlich jedliche Garantien und Gewährleistungen verliert. Die Temperaturen sollten im Auge behalten werden, es empfiehlt sich, andere Kühlkörper und Lüfter als die Standardlüfter zu verwenden. Der Noktua Lüfter eignet sich auch eher weniger für das Übertakten, da dieser von Haus aus leiser arbeitet, und nicht besser.

Speichert die Einstellungen und startet die Bitaxe anschliessend neu, um eure Einstellungen zu übernehmen.

Advanced Overclocking

Fügt ihr im Browser am Ende der Adresse ?oc= ein, öffnet sich der erweiterte Overclocking Modus. Hier können die Werte manuell und frei gewählt werden. Es sind nahezu keine grenzen gesetzt. Bitte achtet besonders drauf was hier ihr eingebt. Ausversehen 1.5v Asic Spannung eingegeben führen dann ziemlich schnell zum Tot des Asic Chips.

Beispiel:

👉 192.168.1.21/#/settings
👉 192.168.1.21/#/settings?oc=

Monitoring und Wartung

Beobachte die Temperatur und die Hashrate im Dashboard. Der Asic Miner taktet automatisch herunter, sollte die Temperaturen über 65° steigen. Alles bis zu 65° ist vollkommen in Ordnung.

Reinigt ausserdem das Gerät auch regelmäßig, um Überhitzung durch Staubansammlungen zu verhindern.

Sicherheit und Updates

Haltet die Firmware des Geräts auf dem neuesten Stand, um optimale Leistung und Sicherheit zu gewährleisten.

Klickt dafür auf esp-miner.bin und ladet die Firmware herunter, und für das Web-UI auf www.bin. Danach wählt ihr unter Update Firmware Browse Button und wählt die esp-miner.bin und bei Update Webseite die www.bin. Das Gerät läd die Firmware automatisch, und muss danach neu gestartet werden.

Swarming

Ihr könnt im Tab Swarm eure Geräte verbinden, um sie jeweils von einer Bitaxe aus alle zu konfigurieren. Fügt dafür einfach unter AxeOS Device IP die IP Adresse der anderen Miner hinzu:

Bitaxe herunterfahren

Um die Bitaxe herunterzufahren, müsst ihr nichts anderes tun, als das Stromkabel zu trennen. Das tut der Bitaxe keinen Schaden, und wird auch das Betriebssystem nicht beschädigen.

Bitaxe zurücksetzen und wieder in den Acess Point Modus bringen

Geht einfach auf das Web-UI der jeweiligen Bitaxe, und löscht eure WLAN Daten wie die SSID und das WLAN Passwort. Startet das Gerät anschliessend neu. Das Gerät wird dann wieder in den AP-Modus gehen. Bei einem Verkauf eurer Bitaxe, löscht ihr am besten gleich noch sämtliche Einstellungen wie den Pool, eure BTC-Adresse, und das Passwort.

Firmware neu Flashen

Falls irgendwas mal total schief gegangen ist, und die Bitaxe nicht mehr reagiert, hilft es, die Firmware neu zu flashen. Auch kann es vorkommen, dass der Overheating Modus durch ein Missgeschickt aktiviert wird, wenn sich das Gerät noch nicht mit dem WLAN verbunden hat. In diesem Fall agiert die Bitaxe nicht mehr als Access Point und der Overheating Modus kann nicht deaktiviert werden.

Besucht den Link für dem Online Firmwareflasher:

https://bitaxeorg.github.io/bitaxe-web-flasher

Schliesst eure Bitaxe an den Strom, und verbindet die Bitaxe mit einem USB-C Kabel mit eurem Rechner.

Klickt danach auf Connect, und wählt die ttyUSB Verbindung. Wählt das richtige Gerät, und das richtige Board aus, und beginnt das flashen der Firmware mit Start Flashing. Die Firmware wird nun auf eure Bitaxe geflasht. Die Bitaxe führt, danach einen Funktionscheck durch. Danach müsst ihr die Bitaxe noch neu starten, und sie befindet sich wieder im AP Modus.

Fazit

Mit der Bitaxe seid ihr bestens gerüstet, um in die Welt des Bitcoin-Minings einzutauchen. Die Einrichtung ist dank der benutzerfreundlichen Bedienoberfläche und einfachen Netzwerkanbindung schnell erledigt. Ob ihr ein erfahrener Miner oder Neueinsteiger seid – die Flexibilität und Leistungsfähigkeit dieses Geräts ermöglichen es euch, das Beste aus eurem Mining-Erlebnis herauszuholen. Sobald die Konfiguration abgeschlossen ist und der Miner korrekt läuft, könnt ihr entspannt zurücklehnen, während die Bitaxe effizient und zuverlässig ihre Arbeit erledigt. Viel Erfolg!

Falls ihr auf der Suche nach 'ner Bitaxe seid, schaut mal bei uns im Shop vorbei!

Sucht ihr nach mehr Infos und Theorie zum Mining, dann haben wir die kleine Bitcoin Mining Bibel für euch:

Habt ihr Lust unserem Mining Pool beizutreten? Unser Ziel ist es, in der Schweiz einen Block zu finden. Mit den Jungs aus der Schweiz und Plebs aus verschiedenen Ländern haben wir bereits gut Hashrate zusammen!

Nehmt euren Miner in die Hand, und konfiguriert diesen auf unseren Pool:

Stratum Host: blitzpool.yourdevice.ch
Port: 3333
Alternativer Port: 4444

Wir betreiben einen stark modifizierten Public-Pool Fork der welcher extrem erweitert worden ist, und sich auch fürs Mining mit Freunden eignet. Somit habt ihr, wenn ihr zusammen auf einer Adresse schürft, eure Worker komplett im Überblick.

Pool UI: https://blitzpool.yourdevice.ch

Häufige Fragen zur Bitaxe

Lohnt sich Solo-Mining mit einer Bitaxe?

Finanziell betrachtet ist es eine Lotterie: Die Wahrscheinlichkeit, mit einem einzelnen Gerät einen Block zu finden, ist sehr gering. Viele betreiben eine Bitaxe daher aus Überzeugung – um das Netzwerk zu dezentralisieren, zu lernen und die Chance auf den „Lottogewinn“ mitzunehmen – statt als zuverlässige Einnahmequelle.

Welche Bitaxe eignet sich für Einsteiger?

Die Bitaxe Gamma mit BM1370-Chip ist aktuell die Empfehlung: beste Effizienz (~15 J/TH) und höchste Hashrate aus einem einzelnen Chip. Sie kommt fertig montiert und läuft direkt mit der AxeOS-Firmware.

Wie viel Strom verbraucht eine Bitaxe?

Je nach Modell und Taktung etwa 12 bis 21 Watt. Eine Supra liegt um die 12 W, eine Gamma bei rund 15–21 W. Im „PowerSave“-Betrieb lässt sich der Verbrauch zugunsten der Effizienz weiter senken.

Ist die Bitaxe wirklich Open Source?

Ja. Sowohl das Hardware-Design als auch die Firmware AxeOS (ESP-Miner) sind quelloffen und auf GitHub einsehbar. Das ist einer der grössten Vorteile gegenüber herkömmlichen Closed-Source-Minern.

Zuletzt aktualisiert im Juni 2026 – Modellübersicht (inkl. Gamma BM1370), Pool-Empfehlungen und FAQ ergänzt.

The post Bitaxe Miner Einrichtung und Anwendung appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitungen

Das Tutorial basiert auf dem Artikel eigenen IP2Tor Server für den Rapsiblitz einrichten. Damit ihr einen groben Überblick habt, lesst euch den Artikel vorher durch, damit ihr vorbereitet seid, und die entsprechenden Bedienungen installiert habt. Die im Artikel beschriebene Einrichtung vom LND Dienst muss nicht eingerichtet werden, sie galt nur als Beispiel.

Installiert euch zudem den BTCPay Server, und / oder LNBits auf eurem Raspiblitz. Schreibt euch die Onion Adressen der jeweiligen Dienste auf. Die findet ihr im cli-menu unter den jeweiligen Einträgen:

Die Onion Addresse für LNBits findet ihr 2 Einträge unter BTCPay Server Info.

Domain einrichten

Damit ihr euren BTCPay Server über eine Domain via https erreichen könnt, müsst ihr eine Domain haben, die auf den Server zeigt, dass kann auch eine gratis DynDNS Addresse sein, falls ihr kein Geld ausgeben möchtet. Bei einem VPS Server mit statischer IP bietet es sich aber an, eine eigene fixe Domain zu kaufen, und diese auf den Server zeigen zu lassen. Das könnt ihr zum Beispiel bei https://strato.de, oder in der Schweiz bei https://hostpoint.ch tun.

Falls ihr kein Bock auf sowas habt, könnt ihr auch eine Domain bei uns kaufen. Wir erledigen die Einrichtung mit einem A-Record auch gerne gleich mit dazu.

In den DNS Records müsst ihr einen A-Record setzen, der auf die VPS IP zeigt. Dies sieht in der Regel bei Hostpoint zum Beispiel so aus:

Name: eure Subdomain, zum Beispiel btcpay oder btcpay-raspibliblitz, und für LNBits zum Beispiel einfach lnbits
TTL: Bleibt bei 300
IP-Adresse: die IP Adresse eurer VPS

Danach Record hinzufügen und bestätigen.

Einrichtung auf eurem IP2Tor Server

Ihr habt euch im bestenfall schon einen IP2Tor Server eingerichtet, falls nicht, lesst den oben verlinkten Beitrag, und richtet kurz Tor und Socat ein. Hier nochmals der Beitrag:

BTCPay Server IP2Tor Dienst einrichten

Erstellt euch einen neuen IP2TorDienst auf dem VPS mit:

sudo nano /etc/systemd/system/ip2tor_btcpay.service

und fügt folgenden Inhalt hinzu:

[Unit]
Description=Tor2IP Tunnel Service
After=network.target

[Service]
User=root
Group=root
ExecStart=/usr/bin/socat TCP4-LISTEN:23002,bind=127.0.0.1,fork SOCKS4A:localhost:eure_btcpay_onion_addresse.onion:80,socksport=9050
StandardOutput=journal

PrivateTmp=true
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true

[Install]
WantedBy=multi-user.target

Der Port ist frei wählbar, ihr könnt einen nehmen, der euch passt. Dieser muss dann einfach mit dem SystemD Dienst weiter übereinstimmen. Ersetzt den fett markierten Teil mit eurer BTCPay Onion Adresse die ihr euch von eurem Raspiblitz notiert habt. Speichert die Datei mit strg+o und beendet mit strg+x

Startet den Dienst mit neu mit sudo systemctl start ip2tor_btcpay.service und checkt den Dienst mit sudo systemctl status ip2tor_btcpay.service:

Mit sudo systemctl enable ip2tor_btcpay.service aktiviert ihr den Dienst bei Systemstart.

Nginx installieren, einrichten und SSL Zertifikat beantragen

Damit wir die Seite über unsere Domain erreichen können, müssen wir uns Nginx auf dem VPS installieren und einen Reverse Proxy einrichten, der die Anfrage an socat weiterleitet.

Installiert euch nginx mit

apt install nginx

Entfernt die Standard Konfigurationen mit

rm /etc/nginx/sites-available/default
rm /etc/nginx/sites-enabled/default

Fügt eine neue nginx Konfiguration hinzu mit:

nano /etc/nginx/sites-available/ip2tor_btcpay 

und fügt folgenden Eintrag ein:

server {
    server_name eure_domain.de;

    location / {
        proxy_pass http://127.0.0.1:23002;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Ersetzt den fett markierten Text mit eurer Domain die ihr bei eurem Hoster festgelegt habt und gebt den selben Port hier an!

Erstellt einen syslink in den sites-enabled Ordner:

ln -s /etc/nginx/sites-available/ip2tor_btcpay /etc/nginx/sites-enabled/

checkt ob alles korrekt ist mit dem Befehl nginx -t und falls ihr ein Syntax OK bekommt, ladet nginx mit sudo systemctl reload nginx neu.

SSL Zertifikat holen

Für die Domain brauchen wir ein SSL Zertifikat um eine gesicherte Verbindung herstellen zu können. Dafür müssen wir uns ein SSL-Zertifikat holen. Das geht am besten mit certbot. Damit lassen sich einfach Lets Encrypt Zertifikate beantragen, und direkt die entsprechende nginx Konfiguration anpassen.

Installiert euch certbot auf dem VPS mit:

apt install certbot python3-certbot-nginx

und beantragt anschliessend nach der Installation eine Zertifikat mit:

certbot --nginx -d eure_domain.de -m eure_mail_addresse

Ersetzt eure_domain.de mit eurer gekauftet Domain, und gebt eure Mail-Addresse an. Die Domain muss die selbe sein wie in der nginx Konfiguration, welche wir angelegt haben!

Ihr bekommt 2 Fragen von Letsencrypt. Einmal ob ihr mit den Vertragsbediengungen einverstanden seid, und einmal ob ihr Neuigkeiten von Letsencrypt erhalten wollt. Stimmt den Vertragsbediengungen hinzu, und nehmt den Newsletter an, oder nicht. Falls alles geklappt habt, bekommt ihr folgende Meldung:

Das SSL Zertifikat wird automatisch erneuert, falls es abläuft. Die Zertifikate sind in der Regel 90 Tage gültig.

Hat alles geklappt, könnt ihr nun euren BTCPay Server via Domain und https Verbindung aufrufen:

LNBits Server IP2Tor Dienst einrichten

Die Ablauf ist der selbe wie beim BTCPay Server. Natürlich müsst ihr auf eurem Hoster eine neue Subdomain erstellen, zum Beispiel lnbits.eure_domain.de. Erzeugt eine neuen LNBits Dienst auf dem VPS mit:

sudo nano /etc/systemd/system/ip2tor_lnbits.service

Fügt folgenden Inhalt hinzu:

[Unit]
Description=Tor2IP Tunnel Service
After=network.target

[Service]
User=root
Group=root
ExecStart=/usr/bin/socat TCP4-LISTEN:5002,bind=0.0.0.0,fork SOCKS4A:localhost:eure_lnbits_addresse.onion:80,socksport=9050
StandardOutput=journal

PrivateTmp=true
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true

[Install]
WantedBy=multi-user.target

Speichert die Datei ab, startet den Dienst mit sudo systemctl start ip2tor_lnbits.service und aktiviert den Dienst bei Systemstart mit sudo systemctl enable ip2tor_lnbits.service

Erstellt eine neue Nginx Kongifurationsdatei mit

nano /etc/nginx/sites-available/ip2tor_lnbits 

und fügt folgenden Inhalt hinzu:

server {
    server_name eure_lnbits_domain.de;

    location / {
        proxy_pass http://127.0.0.1:5002;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Achtet darauf dass ihr den selben Port nehmt, wie in eurer Nginx Konfiguration! Fügt einen neuen symlink hinzu mit:

ln -s /etc/nginx/sites-available/ip2tor_lnbits /etc/nginx/sites-enabled/

Testet die Konfiguration mit nginx -t und ladet Nginx neu mit systemctl reload nginx

Danach wieder das SSL Zertifikat beantragen mit:

certbot --nginx -d lnbits-eure_domain.de -m info@yourdevice.ch

Passt die fett markierten Einträge entsprechend an.

Anschliessend solltet ihr über die URL auf eure LNBits Instanz kommen:

Damit ihr auf euren Server Account kommt, fügt die Wallet Addresse am Ende der URL hinzu, die euch der Info-Screen des Raspiblitzes gibt:

Abschluss

Die Einrichtung von Tor-Diensten über socat, Tor und Nginx mit SSL-Zertifikat bietet eine sichere und anonyme Methode, um verborgene Dienste im Clearnet zugänglich zu machen. Dieser Prozess ermöglicht es euch, die Vorteile des Tor-Netzwerks zu nutzen, während ihr gleichzeitig die Benutzerfreundlichkeit und Sicherheit einer HTTPS-Verbindung gewährleistet. Ich hoffe der Artikel <BTCPay und LNBits auf Raspiblitz über Clearnet erreichen mit IP2Tor> hat euch gefallen. Habt ihr Fragen, hinterlasst sie in den Kommentaren!

Keine Lust da selber einzurichten? Wir bieten ein IP2Tor Dienst in unserem Webshop direkt an:

The post BTCPay und LNBits auf Raspiblitz über Clearnet erreichen mit IP2Tor appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was richten wir hier genau ein

Wir richten einen sogenannten Tor-to-IP-Tunnel-Dienst ein. Dabei wird der Datenverkehr von einem Tor Hidden Service über einen VPS geleitet, sodass er über eine normale IP-Adresse oder Domain zugänglich ist. Der VPS fungiert hierbei als Brücke zwischen dem Tor-Netzwerk und dem öffentlichen Internet.

Wie es funktioniert

1. Tor Hidden Service: Ein Dienst, der nur über das Tor-Netzwerk erreichbar ist, wird auf deinem lokalen Rechner betrieben.
2. VPS: Ein Virtual Private Server, der als öffentlich zugänglicher Einstiegspunkt dient.
3. socat: Ein Tool, das den Datenverkehr zwischen dem VPS und dem Tor Hidden Service weiterleitet.

Vorteile

• Verbirgt die IP-Adresse des Hosts vor der Öffentlichkeit und dem VPS.
• Kein Port-Forwarding im lokalen Netzwerk (LAN) des Hosts erforderlich.
• Zusätzliche Verschlüsselung durch Tor zwischen dem Host und dem VPS.

Nachteile

• Die Lösung ist elegant, um die eigenen Dienste via Clearnet zu erreichen, die Verbindung danach erfolgt aber weiterhin über Tor, ist also nicht so schnell wie zum Beispiel die VPN Lösung Tunnelsats.

Voraussetzungen

• SSH-Zugang zu einem Virtual Private Server (VPS) - Zum Beispiel ein minimales Paket bei IONOS oder Hetzner für für ca. 2-4 Euro pro Monat.
• Ein Rapsiblitz der voll synchronisiert ist. Die Dienste müssen eingerichtet sein, und funktionieren.
• Portfreigabe auf dem VPS Server: Der entsprechene Port muss in der Firewall des VPS Servers freigegeben sein!

Schritt-für-Schritt Anleitung

Einrichtung von Tor und Socat auf dem VPS Server

Meldet euch mit SSH als root-Benutzer an:

ssh root@VPS_IP_ADDRESSE

Bringt eures System auf den neusten Stand mit:

apt update && apt upgrade -y && apt autoremove -y && apt autoclean -y

Installiert socat:

apt install socat

Installiert danach Tor:

$ apt install apt-transport-https

$ sh -c 'echo "deb [arch=amd64 signed-by=/usr/share/keyrings/deb.torproject.org-keyring.gpg] https://deb.torproject.org/torproject.org $(lsb_release -sc) main" >> /etc/apt/sources.list.d/tor-project.list'

$ apt update

$ apt install tor

Einrichtung eines systemd-Dienstes

Erstellt einen separaten Prozess für jeden verbundenen Hidden Service, um zu vermeiden, dass jede Verbindung neu gestartet werden muss, wenn ein Dienst hinzugefügt oder entfernt wird. Vorteilhaft wäre es, den verwendeten Port und den Dienstnamen im Namen des Dienstes anzugeben, z.B. tor2ip<VPS_PORT>_<lnd>.

Erstellt die Dienstdatei

nano /etc/systemd/system/tor2ip9236_lnd.service

Fügt den folgenden Inhalt ein und passt die Variablen an:

• VPS_PORT: Der Port, der öffentlich zugänglich sein soll (in diesem Beispiel: 9236).
• TOR_HIDDEN_SERVICE_ADDRESS.onion: Die Adresse des Hidden Services.
  • Die Adresse erhaltet ihr auf dem Raspiblitz für Lightning zum Beispiel mit:
    lncli getinfo
• TOR_PORT: Der Port, den der Hidden Service verwendet (in diesem Beispiel für LND: 9735).

[Unit]
Description=Tor2IP Tunnel Service
After=network.target

[Service]
User=root
Group=root
ExecStart=/usr/bin/socat TCP4-LISTEN:9236,bind=0.0.0.0,fork SOCKS4A:localhost:TOR_HIDDEN_SERVICE_ADDRESSE.onion:9735,socksport=9050
StandardOutput=journal

[Install]
WantedBy=multi-user.target

TOR_HIDDEN_SERVICE_ADRESS ist dabei die Adresse vom Raspiblitz die ihr mit lncli getinfo auf dem Raspiblitz erhalten habt:

Die Tor Adresse ist der Teil nach dem @!

Dienst aktivieren und starten

systemctl enable tor2ip9236_lnd
systemctl start tor2ip9236_lnd

Überprüfung und Überwachung

Überprüft, ob der Tunnel aktiv ist mit:

netstat -tulpn

Achtet auf die Zeile:

tcp        0      0 0.0.0.0:9236            0.0.0.0:*               LISTEN      13684/socat  

Dienst überwachen

   systemctl status tor2ip9236

Beispielausgabe:

   ● tor2ip9236_lnd.service - Tor2IP Tunnel Service
      Loaded: loaded (/etc/systemd/system/tor2ip9236.service; enabled; vendor preset: enabled)
      Active: active (running) since Sun 2024-06-20 14:58:43 BST; 2min 23s ago
    Main PID: 13684 (socat)
       Tasks: 1 (limit: 1078)
      Memory: 540.0K
      CGroup: /system.slice/tor2ip9236.service
              └─13684 /usr/bin/socat TCP4-LISTEN:9236,bind=0.0.0.0,fork SOCKS4A:localhost:TOR_HIDDEN_SERVICE_ADDRESS.onion:9735,socksport=9050

   Jun 20 14:58:43 VPS_hostname systemd[1]: Started Tor2IP Tunnel Service.

Port freigeben auf dem VPS Server

In den Server Einstellungen bei eurem VPS Provider muss der Port 9236 wie in diesem Beispiel freigegeben werden. Bei Ionos findet ihr die Einstellungen unter Netzwerk -> Firewall Richtlinien:

Abschluss

Herzlichen Glückwunsch! Ihr habt erfolgreich einen Tor-to-IP-Tunnel-Dienst eingerichtet. Ihr könnt nun weitere Dienste hinzufügen, indem ihr unterschiedliche Ports auf dem VPS verwendet. Um auf die Ports/Dienste des Host-Computers zuzugreifen, verwendet dazu einfach die VPS_IP_ADRESSE:VPS_PORT.

Beispiel für die Verbindung zu LND. Eure Peers können sich nun mit der IP Adresse eures VPS und dem entsprechenden Port mit euch verbinden:

lncli connect NODE_PUBLIC_KEY@VPS_IP_ADRESSE:9236

Mit dieser Konfiguration im Artikel "Tor Dienste mit IP2Tor auf dem Raspiblitz via Clearnet ansprechen" habt ihr eine sichere und anonyme Möglichkeit geschaffen, Tor Hidden Services im Clearnet zugänglich zu machen. Achte darauf, die Sicherheit deiner Dienste stets im Auge zu behalten und die Regeln deines VPS-Anbieters zu beachten.

Resourcen:

https://github.com/openoms/bitcoin-tutorials/blob/master/tor2ip_tunnel.md

The post Tor Dienste mit IP2Tor auf dem Raspiblitz via Clearnet ansprechen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Denn der Gewinn ist real, und der Preis auch. Wer viele Kanäle betreibt, kennt das Problem: Tor-Verbindungen brauchen länger, brechen häufiger ab, und bei zeitkritischen HTLC-Weiterleitungen entscheidet das darüber, ob eine Zahlung über euch läuft oder über jemand anderen. Wer dagegen in Ruhe ein paar Kanäle für den Eigenbedarf hält, hat von Clearnet wenig und verschenkt dafür den Standort seines Anschlusses. Dieser Artikel zeigt, wie ihr den Hybridmodus einrichtet — und woran ihr vorher erkennt, ob ihr ihn überhaupt wollt.

Was der LND Hybrid Mode macht — und was nicht

Eingeführt wurde die Betriebsart mit LND 0.14.0-beta. In den Release Notes steht dazu wörtlich: „A new flag has been added to enable a hybrid tor connectivity mode, where tor is only used for onion address connections, and clearnet for everything else." Dieses Flag heisst tor.skip-proxy-for-clearnet-targets, und mehr ist es im Kern nicht.

Wichtig ist der Unterschied zwischen ausgehend und eingehend. Ausgehend entscheidet LND ab sofort je Gegenstelle, welchen Weg es nimmt. Eingehend ändert sich erst dann etwas, wenn ihr der Node zusätzlich eine öffentliche Adresse mitgebt und der Port von aussen erreichbar ist. Die Onion-Adresse bleibt in beiden Fällen bestehen — ihr verliert sie nicht, ihr bekommt eine zweite Adresse dazu.

Achtung: Clearnet und die Privatsphäre

Eine Node hinter Tor zu betreiben hat gute Gründe, und für kleinere Nodes ist es weiterhin die naheliegende Wahl. Sobald ihr eine öffentliche Adresse ankündigt, steht sie im Netzwerkgraphen des Lightning-Netzes, und jeder, der den Graphen liest, kann sie einer groben geografischen Lage zuordnen. Das ist keine Randnotiz, sondern die eigentliche Entscheidung dieses Artikels.

LND selbst formuliert das in der Beispielkonfiguration unmissverständlich: „WARNING: This option will reveal the source IP address of the node, and should be used only if privacy is not a concern." Dazu kommt, dass ihr mindestens einen Port (Vorgabe: 9735) von aussen erreichbar machen müsst und damit für die Absicherung des darunterliegenden Systems selbst verantwortlich seid.

Setzt den Hybridmodus also dann ein, wenn Erreichbarkeit, Stabilität und Latenz für euch schwerer wiegen als die Anonymität des Standorts. Wenn ihr das umgekehrt seht, aber trotzdem Clearnet-Vorteile wollt, springt weiter unten zum Abschnitt über Tunnelsats. Und wer sich zuerst grundsätzlich sortieren möchte, findet im Ratgeber zum Schutz der Privatsphäre die Abwägung in allgemeiner Form.

Voraussetzungen: Port, feste IP-Adresse — und kein DS-Lite

Damit eure Node von aussen angesprochen werden kann, müssen drei Dinge stimmen.

1. Zugriff auf den Router. Ihr braucht Zugang zu den Einstellungen, um eine Portweiterleitung anzulegen. Für die NAT-Variante weiter unten muss der Router zusätzlich UPnP beherrschen.
2. Offener Port. Der Standardport für Lightning ist 9735. Er muss auf die lokale IP-Adresse eures RaspiBlitz weitergeleitet sein.
3. Feste lokale IP-Adresse. Bekommt der RaspiBlitz beim nächsten Neustart eine andere Adresse aus dem DHCP-Bereich, zeigt die Weiterleitung ins Leere.

Wie ihr eine Portweiterleitung einrichtet, steht in der Anleitung zur Port-Weiterleitung für Dienste.

Feste IP-Adresse für den RaspiBlitz vergeben

• Netzwerkeinstellungen öffnen. Sucht im Menü eures Routers nach den Netzwerk- oder DHCP-Einstellungen. Die Bezeichnung unterscheidet sich je nach Modell.
• DHCP-Reservierung anlegen. Je nach Hersteller heisst die Funktion „DHCP-Reservierung", „Statische IP" oder „IP-Adressen-Zuweisung".
• Gerät auswählen. Der RaspiBlitz wird meist über seine MAC-Adresse identifiziert. Auslesen könnt ihr sie auf der Node selbst.
• Adresse festlegen und neu starten. Die Adresse muss im Subnetz eures Routers liegen. Danach den RaspiBlitz neu starten, damit er sie auch bezieht.

ip addr
sudo systemctl reboot

Wenn euer Anschluss hinter DS-Lite hängt

Dieser Punkt fehlte in der ursprünglichen Fassung dieses Artikels und ist der häufigste Grund, warum der Hybridmodus am Ende trotzdem nicht funktioniert: Bei einem DS-Lite-Anschluss teilt ihr euch die öffentliche IPv4-Adresse mit anderen Kunden desselben Anbieters. Eine Portweiterleitung auf IPv4 ist dann schlicht nicht möglich, egal was im Routermenü steht. Prüft das, bevor ihr anfangt — welche Wege es in diesem Fall gibt, steht in der Anleitung zu Diensten hinter DS-Lite.

Wo die lnd.conf auf dem RaspiBlitz wirklich liegt

Korrektur gegenüber der früheren Fassung: Dort stand /mnt/hdd/lnd/ als Ablageort der lnd.conf. Das stimmt heute nicht mehr. Das Installationsskript des Projekts legt die Datei unter /mnt/hdd/app-data/lnd/ ab und startet den Dienst mit --configfile=/mnt/hdd/app-data/lnd/lnd.conf.

Ihr müsst euch den Pfad aber gar nicht merken. Dasselbe Skript legt eine Abkürzung an, die immer auf die richtige Datei zeigt — auch dann, wenn ihr Testnet oder Signet parallel betreibt:

lndconf

Das öffnet die Konfiguration im Editor nano. Legt vorher eine Kopie an, dann habt ihr einen Rückweg:

sudo cp /mnt/hdd/app-data/lnd/lnd.conf /mnt/hdd/app-data/lnd/lnd.conf.bak

Der eine Eintrag, auf den es ankommt

In den Abschnitt [tor] der lnd.conf gehört diese Zeile:

[tor]
; Allow the node to connect to non-onion services directly via clearnet. This
; allows the node operator to use direct connections to peers not running behind
; Tor, thus allowing lower latency and better connection stability.
; WARNING: This option will reveal the source IP address of the node, and should
; be used only if privacy is not a concern.

tor.skip-proxy-for-clearnet-targets=true

Dazu gehört eine zweite Bedingung: Die Stream-Isolation muss aus sein. Sie gibt jeder Verbindung einen eigenen Tor-Kanal und verträgt sich mit dem Hybridmodus nicht. Im Leitfaden von blckbx, auf den sich die meisten Anleitungen zu diesem Thema stützen, steht dazu: „tor.streamisolation=false must be turned off/not present when using hybrid-mode".

Auf dem RaspiBlitz müsst ihr euch darum nicht selbst kümmern, und das ist der angenehmste Befund dieser Überarbeitung. Das Prüfskript lnd.check.sh, das vor jedem Start von LND läuft, erkennt euren Eintrag und zieht die passende Einstellung selbst nach:

if [ $(cat ${lndConfFile} | grep -c "^tor.skip-proxy-for-clearnet-targets=true") -gt 0 ] ||
   [ $(cat ${lndConfFile} | grep -c "^tor.skip-proxy-for-clearnet-targets=1") -gt 0 ]; then
  setting ${lndConfFile} ${insertLine} "tor.streamisolation" "false"
fi

Dasselbe Skript setzt auch tor.active, tor.v3 und den listen-Eintrag auf Port 9735. Einen eigenen Menüpunkt für den Hybridmodus hat der RaspiBlitz dagegen bis heute nicht — der Wunsch danach steht seit Jahren als offenes Issue 2787 im Projekt. Die Handarbeit an der lnd.conf bleibt euch also, das Skript nimmt sie euch nur nicht wieder weg.

Die externe Adresse: drei Wege, einer davon fällt weg

Damit eingehende Verbindungen möglich werden, muss LND wissen, unter welcher Adresse eure Node von aussen erreichbar ist. Dafür gibt es drei Möglichkeiten — und auf dem RaspiBlitz scheidet ausgerechnet die einfachste aus.

externalip: auf dem RaspiBlitz nicht haltbar

Bei einer festen öffentlichen IP-Adresse wäre externalip der direkte Weg. Auf dem RaspiBlitz hat dieser Eintrag jedoch keinen Bestand, sobald Tor aktiv ist — und aktiv ist Tor im Hybridmodus immer. Das erwähnte Prüfskript entfernt die Zeile bei jedem Start wieder:

# enforce PublicIP if (if not running Tor)
if [ "${runBehindTor}" != "on" ]; then
  setting ${lndConfFile} ${insertLine} "externalip" "${publicIP}:${lndPort}"
else
  # when running Tor a public ip can make startup problems - so remove
  sed -i '/^externalip=*/d' ${lndConfFile}
fi

Wer sich also wundert, warum die von Hand eingetragene IP-Adresse nach einem Neustart verschwunden ist: Das ist kein Fehler, sondern Absicht. Für nat und externalhosts enthält das Skript keine solche Regel, diese beiden Einträge bleiben stehen.

Variante 1: NAT über UPnP

Mit nat=true versucht LND, die externe Adresse selbst zu ermitteln und bei einem Wechsel nachzuziehen. Die Beispielkonfiguration von LND nennt dazu gleich die Einschränkungen: Beide Techniken „require proper hardware support", und wird sie nicht erkannt, beendet sich LND mit einem Fehler. Ausserdem: „This does not support devices behind multiple NATs."

[Application Options]
listen=0.0.0.0:9735
nat=true

[tor]
tor.active=true
tor.v3=true
tor.skip-proxy-for-clearnet-targets=true

externalip und nat werden dabei nie zusammen gesetzt; LND kommt mit der Kombination nicht zurecht. Der Leitfaden von blckbx geht noch weiter und rät nach Rückmeldungen aus der Praxis ganz davon ab: „Concluding from feedback on this, nat really doesn't work well and should be avoided!" Das ist eine Einschätzung dieses Leitfadens und keine Aussage des LND-Projekts — sie deckt sich aber mit den Einschränkungen, die LND selbst aufführt. Probiert diese Variante, wenn euer Router UPnP zuverlässig beherrscht, und wechselt auf die zweite, wenn es hakt.

Variante 2: DynDNS über externalhosts

Der stabilere Weg bei wechselnder IP-Adresse ist eine DynDNS-Domain. Ein Dienst aktualisiert dabei den DNS-Eintrag auf eure jeweils aktuelle Adresse, und LND löst den Namen regelmässig auf. Wie ihr eine solche Domain anlegt, steht in der Anleitung zum DynDNS-Eintrag bei dynamischer IP. Der gewählte Name spielt keine Rolle.

Die zuständige Option heisst externalhosts. LND beschreibt sie als „A list of domains for lnd to periodically resolve, and advertise the resolved IPs for the backing node".

[Application Options]
listen=0.0.0.0:9735
externalhosts=eure_dyndns_domain:9735

[tor]
tor.active=true
tor.v3=true
tor.skip-proxy-for-clearnet-targets=true

Eine Stolperfalle, die schnell zu einer verlorenen Stunde führt: Der RaspiBlitz hat unter SETTINGS einen eigenen Menüpunkt DynamicDNS. Der ist nützlich, macht aber etwas anderes. Er hinterlegt Domain und Aktualisierungsadresse in der raspiblitz.conf und trägt die Domain in das TLS-Zertifikat von LND ein — damit ihr eure Node unter diesem Namen fernsteuern könnt. In die lnd.conf schreibt er nichts. Den Eintrag externalhosts setzt ihr weiterhin selbst.

Nach jeder Änderung startet ihr LND neu:

sudo systemctl restart lnd.service

Funktionstest: zwei URIs statt einer

Ob die Umstellung gegriffen hat, beantwortet ein einziger Befehl:

lncli getinfo

Im Feld uris müssen jetzt zwei Einträge stehen, einer davon mit eurer öffentlichen Adresse. Die IP-Adresse im folgenden Beispiel ist ein Platzhalter:

"uris": [
    "<euer_pubkey>@203.0.113.17:9735",
    "<euer_pubkey>@<eure_adresse>.onion:9735"
]

Steht dort nur die Onion-Adresse, hat die Ankündigung nicht funktioniert. Die drei häufigsten Ursachen: Die Portweiterleitung zeigt auf die falsche lokale Adresse, der Anschluss liegt hinter DS-Lite, oder es wurde externalip gesetzt und beim Start wieder entfernt. Eine Gegenprobe von aussen liefert eine Gegenstelle, die euch direkt anspricht:

lncli connect <euer_pubkey>@<eure_adresse>:9735

Wer noch keine Gegenstellen hat, die das übernehmen könnten, findet im Beitrag zu Channel Peers finden und Lightning Kanäle eröffnen den Weg dorthin.

Betreibt ihr LNDg, taucht die Clearnet-Adresse dort ebenfalls auf:

Tunnelsats: Clearnet, ohne die eigene Adresse zu zeigen

Tunnelsats ist ein VPN-Dienst, der eigens für Lightning-Nodes gebaut wurde. Statt eurer eigenen IP-Adresse kündigt die Node die Adresse des Tunnelendpunkts an. Ihr bekommt damit eine gleichbleibende öffentliche Adresse und die Latenzvorteile des Clearnets, ohne den eigenen Anschluss offenzulegen — und ohne eine Portweiterleitung im Router, was den Weg auch für DS-Lite-Anschlüsse öffnet.

Bezahlt wird über Lightning im Abonnement; der Monatspreis lag beim Abruf am 13.09.2026 bei rund 3900 Sat, für ein Jahr gibt es einen Rabatt. Die Einrichtung ist aufwendiger als der eine Eintrag oben, aber entlang der Projektanleitung machbar. Der Haken bleibt derselbe wie bei jedem VPN: Ihr tauscht das Wissen eures Internetanbieters gegen das Wissen des Tunnelanbieters.

Wer diesen Tausch nicht eingehen will, kann denselben Aufbau mit einem eigenen kleinen Server nachbauen — die Grundlagen dazu stehen im Beitrag Schnell und einfach einen Wireguard VPN betreiben. Der Aufwand ist deutlich höher, die Kontrolle dafür vollständig.

Worauf ihr achten solltet

• Zuerst DS-Lite prüfen, dann alles andere. Ohne eigene öffentliche IPv4-Adresse führt keine Portweiterleitung zum Ziel, und der ganze Rest ist verlorene Zeit.
• Die Adresse bleibt im Netz, auch nach dem Rückbau. LND kündigt zuvor gesetzte Adressen weiter an, wenn ihr den Eintrag einfach löscht. Sie müssen ausdrücklich zurückgenommen werden — die LND-Beispielkonfiguration nennt dafür lncli peers updatenodeannouncement --address_remove=.
• Legt vor der Änderung eine Kopie der lnd.conf an. Ein Tippfehler im Abschnittsnamen reicht, damit LND nicht mehr startet.
• Erwartet keine neuen Kanäle über Nacht. Der Hybridmodus verbessert Erreichbarkeit und Latenz. Ob jemand einen Kanal zu euch öffnet, entscheiden Gebührenpolitik und Liquidität, nicht die Transportschicht.
• Die Sicherung der Kanäle bleibt Pflicht. Eine besser erreichbare Node ist keine sicherere Node. Wie ihr die channel.backup aus dem Haus bekommt, steht im Backup- und Restore-Leitfaden für Lightning Fullnodes und im Beitrag zum SCB-Backup auf einer Nextcloud.
• Haltet die Node aktuell. Die Angaben hier beziehen sich auf RaspiBlitz 1.12.1; wie ihr aktualisiert, steht in der Anleitung zum Aktualisieren des RaspiBlitz.

Fazit: Der Hybridmodus ist ein Tausch, kein Upgrade

Technisch ist der LND Hybrid Mode eine der unaufwendigsten Verbesserungen, die eine Lightning Node erfahren kann: eine Zeile in der lnd.conf, eine Adresse für eingehende Verbindungen, ein Neustart. Die Wirkung ist messbar — direkte Verbindungen statt Tor-Umwege bedeuten kürzere Laufzeiten und weniger Abbrüche, und wer viele Kanäle führt, merkt das an der Zahl der Weiterleitungen.

Gratis ist das aber nicht. Bezahlt wird nicht in Sat, sondern mit der Preisgabe des eigenen Anschlusses: Die Adresse steht im öffentlichen Netzwerkgraphen, dauerhaft, und lässt sich grob verorten. Wer eine Node aus Neugier oder für den eigenen Zahlungsverkehr betreibt, hat davon wenig und verliert etwas — für den bleibt Tor die richtige Wahl. Wer Routing betreibt und an Verfügbarkeit gemessen wird, kommt an dieser Zeile kaum vorbei. Und wer beides will, findet in Tunnelsats oder einem eigenen Tunnelserver den Mittelweg, der monatlich etwas kostet statt einmalig die Anonymität.

Die einzige falsche Antwort ist, den Schalter umzulegen, ohne die Frage gestellt zu haben.

Quellen und weiterführende Links

• lightningnetwork/lnd — sample-lnd.conf: Wortlaut der Optionen nat, externalip, externalhosts, listen und der Tor-Einstellungen.
• lightningnetwork/lnd — Release Notes 0.14.0: Einführung des Hybridmodus.
• raspiblitz/raspiblitz — lnd.check.sh: Prüfskript vor dem Start von LND, setzt tor.streamisolation und entfernt externalip bei aktivem Tor.
• raspiblitz/raspiblitz — lnd.install.sh: Ablageort der lnd.conf und die Abkürzung lndconf.
• raspiblitz/raspiblitz — internet.dyndomain.sh: was der Menüpunkt DynamicDNS tatsächlich setzt.
• raspiblitz/raspiblitz — Issue 2787: offener Wunsch nach einem eigenen Menüpunkt für den Hybridmodus.
• blckbx/lnd-hybrid-mode: der Leitfaden, auf dem die meisten Anleitungen zum Thema aufbauen.
• tunnelsats.com: Preise und Regionen, abgerufen am 13.09.2026.

The post Raspiblitz Lightning LND via clearnet im Hybrid Mode appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist BTCMap?

BTCMap ist eine mobile Anwendung, die es Nutzern ermöglicht, Bitcoin-freundliche Geschäfte und Dienstleister in ihrer Umgebung zu finden. Die App nutzt eine umfangreiche Datenbank, die kontinuierlich aktualisiert wird, um die besten Orte für Bitcoin-Transaktionen anzuzeigen. Egal ob Cafés, Restaurants, Einzelhandelsgeschäfte oder Dienstleistungsanbieter – mit BTCMap findet ihr schnell und einfach heraus, wo ihr eure Sats ausgeben könnt.

Hauptfunktionen von BTCMap

1. Interaktive Karte:
   Die App bietet eine benutzerfreundliche, interaktive Karte, auf der alle Bitcoin-freundlichen Orte markiert sind. Ihr könnt zoomen und durch verschiedene Stadtteile navigieren, um zu sehen, welche Geschäfte in eurer Nähe Bitcoin akzeptieren.
2. Detaillierte Informationen:
   Für jeden Eintrag gibt es, falls vom Geschäft hinterlegt, Informationen, einschließlich der genauen Adresse, Öffnungszeiten, Kontaktinformationen und eine Beschreibung der angebotenen Produkte oder Dienstleistungen.
3. Benutzerfreundlichkeit:
   BTCMap ist einfach zu bedienen und hat ein intuitives Design. Die Navigation durch die App ist flüssig und erfordert keine technischen Vorkenntnisse.
4. Aktualisierte Datenbank:
   Die Datenbank wird regelmäßig aktualisiert, um sicherzustellen, dass alle Informationen aktuell und korrekt sind. Nutzer können auch neue Orte hinzufügen und bestehende Einträge aktualisieren, um der Community zu helfen. Die Daten basieren auf Open-Source Daten von Open Street Maps.

Vorteile der Nutzung von BTCMap

• Zeitersparnis: Anstatt stundenlang im Internet nach Bitcoin-freundlichen Orten zu suchen, habt ihr alle Informationen auf einen Blick parat.
• Community-basiert: Die App lebt von den Beiträgen und Rückmeldungen der Community. Dadurch bleibt die Datenbank immer aktuell und genau.
• Förderung der Bitcoin-Akzeptanz: Indem ihr Bitcoin-freundliche Orte unterstützt, tragt ihr zur weiteren Verbreitung und Akzeptanz von Bitcoin bei.

Installation und Nutzung

BTCMap ist sowohl für Android als auch für iOS verfügbar und kann kostenlos im F-Droid oder Aurora bzw. im Apple App Store heruntergeladen werden. Nach der Installation erfordert die App keine Registrierung, was die Nutzung noch einfacher macht. Ihr könnt sofort loslegen und die Bitcoin-freundlichen Orte in Deiner Umgebung entdecken.

Eures eigene Geschäft zu BTCMap hinzufügen

Ihr könnt auch euer Geschäft ganz einfach selber zu BTCMap hinzufügen. Das ist etwas kompliziert, wir erklären euch aber genau, wie es funktioniert.

Schritt 1: Account bei OpenStreetMap erstellen

Erstellt euch einen Account bei OpenStreetMap hier.

Schritt 2: Punkt hinzufügen und taggen

Ihr müsst als nächstes eures Lokal erstellen, und die benötigten Information hinterlegen, damit sie die App BTCMap erkennt. Nachdem ihr euch eingeloggt habt, sucht oben Links nach eurer Adresse, oder eurem Standort des Geschäfts. Nachdem ihr diesen gefunden habt, könnt ihr oben über dem Suchfeld auf bearbeiten gehen:

Anschliessend startet der Bearbeitungsmodus. Klickt oben in der Mitte dann auf Point, und wählt nun mit dem Mauszeiger das Gebäude eures Geschäfts aus. Sucht in der linken Arbeitsleiste nun nach der Kategorie eures Geschäfts, zum Beispiels Computerfachhandel:

Fügt nun links in der neuen Arbeitsleiste Informationen zu eurem Geschäft hinzu. Name des Betreibers, Name des Geschäfts, Telefonnummer und etc.

Nun fügen wir die Daten hinzu, die BTCMap benötigt, um das Geschäft zu erkennen und in der App hinzu zufügen. Dieses sind die folgenden Tags: Diese müsst ihr weiter unten im Tab Eigenschaften hinzufügen:

currency:XBT=yes - zeigt an, das Bitcoin akzeptiert wird.

payment:onchain=yes - zeigt an dass on-chain Zahlungen akzeptiert werden.

payment:onchain=no - zeigt an, dass on-chain Zahlungen nicht akzeptiert werden.

payment:lightning=yes - zeigt an, dass Zahlungen in Lightning akzeptiert werden.

payment:lightning=no - zeigt an, dass Lightning Zahlungen nicht akzeptiert werden.

payment:lightning_contactless=yes - zeigt an, dass Lightning Zahlungen per NFC akzeptiert werden.

payment:lightning_contactless=no - zeigt an, dass Lightning Zahlungen per NFC nicht akzeptiert werden.

survey:date=yyyy-mm-dd - zeigt an, dass die Daten am heutigen Tag hinzugefügt und verifiziert worden sind haltet euch an das Format im Screenshot.

Anschliessend sollten die Zahlungen im Feld Zahlungsarten vorhanden sein:

Schritt 3: Arbeit speichern

Speichert eure Arbeit ab, indem ihr oben rechts auf den Upload Button drückt. Gebt dem Eintrag eine Beschreibung, und wählt anschliessend das hochladen aus:

Jetzt müsst ihr eine Weile warten, und BTCMap zeigt euch den Shop dann in der jeweiligen Region an:

Wem das ganze zu kompliziert ist, der kann hier sein Geschäft hier vom BTCMap Team, von freiweiligen eintragen lassen, scrollt nach unten zum Punkt Form Option, und gebt hier eure Daten ein:

Fremde Geschäfte hinzufügen

Ihr könnt natürlich auch selber Geschäfte hinzufügen, die Bitcoin als Zahlungsmittel akzeptieren. Dafür müsst ihr nicht Besitzer des Geschäfts sein. Hinterlasst jedoch trotzdem dem Shop, den ihr selber hinzufügt eine Nachricht. Setzt den tag survey:date=yyyy-mm-dd erst, wenn ihr sicher seid, dass der Shop auch wirklich Bitcoin akzeptiert, dass könnt ihr zum Bespiel tun, indem ihr das Geschäft per Mail anfragt.

Fazit

BTCMap ist ein unverzichtbares Tool für jeden Bitcoin-Nutzer. Mit seiner benutzerfreundlichen Oberfläche, den detaillierten Informationen und der aktiven Community ist die App ideal, um den Alltag mit Bitcoin zu meistern. Egal, ob ihr auf Reisen seid oder einfach nur in eurer Heimatstadt neue Orte entdecken möchtet – BTCMap hilft euch dabei, Bitcoin als Zahlungsmittel zu nutzen und zu erleben.

Probiert die App aus und entdecke die Welt der Bitcoin-freundlichen Geschäfte in eurer Umgebung! Für weitere coole Apps, schaut in der Sektion Android vorbei!

The post Bitcoin Shops finden und hinzufügen mit BTCMap appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was das RaspiBlitz SCB Backup sichert — und was nicht

SCB steht für Static Channel Backup. Die Datei channel.backup enthält laut der Wiederherstellungsdokumentation von LND Einträge für alle derzeit offenen Kanäle und wird jedes Mal neu geschrieben, wenn ein Kanal geöffnet oder geschlossen wird. Verschlüsselt ist sie mit einem Schlüssel, der aus eurer Seedphrase abgeleitet wird — ohne die Seed ist die Datei für Dritte wertlos. Genau deshalb ist es unbedenklich, sie in eine Cloud zu legen.

Wichtig ist, was beim Wiederherstellen tatsächlich passiert. LND startet mit der Datei, verbindet sich zu euren früheren Peers, und diese erkennen über das DLP-Protokoll, dass ihr Daten verloren habt. Die Gegenseite schliesst den Kanal daraufhin zwangsweise und schickt euch das Schlüsselmaterial, mit dem ihr an euer Guthaben kommt. Ihr bekommt also eure Mittel zurück, nicht eure Kanäle. Wer nach einem Ausfall weitermachen will, baut die Kanäle neu auf — wie das geht, steht im Beitrag zum Finden von Peers und Eröffnen von Kanälen. Wer gar keine eigene Node betreibt, hat diese Aufgabe nicht: Bei Wallets wie der Phoenix Wallet kümmert sich die App selbst um die Kanaldaten.

Zwei Grenzen nennt die LND-Dokumentation ausdrücklich. Erstens holt ein SCB nur Mittel zurück, die in den regulären Ausgängen des Kanals liegen, nicht solche, die gerade in einer schwebenden Zahlung stecken. Zweitens ist eine veraltete Sicherungsdatei gefährlich: Wurde der Kanal seit dem Backup weiterbenutzt, kann die Gegenseite oder ein Watchtower eine Straftransaktion auslösen und das gesamte Kanalguthaben einziehen. Ein SCB ist damit kein Backup im Sinne von „irgendeine Kopie genügt“, sondern nur die jeweils jüngste Fassung taugt etwas. Das ist der eigentliche Grund, warum sich diese Datei automatisch nachführen muss.

Warum drei Kopien im selben Gehäuse keine drei Kopien sind

Der RaspiBlitz sichert die Datei von sich aus mehrfach, und das ist wenig bekannt. In der Hintergrundschleife des Systems vergleicht er laufend die Prüfsumme des Originals mit der seiner Kopie. Sobald sich die Datei ändert, legt er sie unter /home/admin/backups/scb/channel.backup ab, zusätzlich eine zweite Kopie mit Zeitstempel im Dateinamen, und ausserdem eine auf der Bootpartition unter /boot/firmware/channel.backup. Nachlesen lässt sich das in home.admin/_background.sh im Projekt-Repository.

Das klingt nach vielen Kopien und ist trotzdem eine einzige, was Katastrophen angeht. Alle drei liegen im selben Gehäuse auf demselben Tisch. Ein Festplattenausfall wird davon aufgefangen, ein Brand, ein Wasserschaden oder ein Einbruch nicht. Genau das meint die 3-2-1-Regel, wenn sie eine Kopie ausser Haus verlangt: Es geht nicht um die Anzahl, sondern um die Trennung. Die Nextcloud-Funktion ist die einzige der vier Kopien, die diese Trennung herstellt — und sie ist die einzige, die ihr von Hand einschalten müsst.

Vorbereitung: ein eigenes Passwort für die Node

Ihr braucht eine Nextcloud-Instanz eures Vertrauens. Wir stellen unseren Lesern 5 GB Nextcloud-Speicher gratis zur Verfügung; registriert euch auf der Webseite, und die Zugangsdaten aus der Registrierung sind zugleich eure Nextcloud-Logindaten. Jede andere Instanz tut es genauso, die Funktion spricht schlicht WebDAV.

Vor der Einrichtung ein Punkt, den die Anleitung früher verschwiegen hat und der wichtiger ist als jeder Klick danach: Der RaspiBlitz speichert die Zugangsdaten im Klartext. Das Einrichtungsskript sagt das bei der Passwortabfrage selbst — „will get stored in cleartext on raspiblitz“ — und legt Server, Benutzername und Passwort anschliessend in der Konfigurationsdatei des Systems ab. Wer dort sein Nextcloud-Kontopasswort einträgt, gibt jedem, der irgendwann Lesezugriff auf die Node bekommt, das gesamte Konto.

Legt deshalb in der Nextcloud ein eigenes App-Passwort an und tragt dieses ein. Ihr findet die Funktion in den persönlichen Einstellungen unter Sicherheit, bei den Geräten und Sitzungen. Ein App-Passwort lässt sich einzeln widerrufen, ohne dass ihr euer Konto anfassen müsst. Wenn ihr Zwei-Faktor-Authentisierung aktiviert habt, führt ohnehin kein Weg daran vorbei: Ein Zugriff über WebDAV mit dem normalen Kontopasswort scheitert dann, wie ein offener Fehlerbericht im Nextcloud-Projekt beschreibt.

Das Backup in der Nextcloud einrichten

Stellt eine SSH-Verbindung zu eurem RaspiBlitz her. Öffnet das Konsolenmenü mit menu und geht in die SETTINGS:

Steuert auf den Eintrag SCB/Emergency-Backup on Nextcloud, markiert ihn mit der Leertaste und bestätigt unten mit OK:

Anschliessend öffnet sich ein weiteres Fenster. Gebt die URL eurer Nextcloud-Instanz ein, auf der die Datei gesichert werden soll:

https://cloud.yourdevice.ch wäre die URL unserer Nextcloud-Instanz. Bestätigt mit OK. In zwei weiteren Fenstern werdet ihr nach Username und Passwort gefragt — hier gehört das App-Passwort hinein, nicht euer Kontopasswort. Nach der Eingabe meldet das System, ob der erste Upload geklappt hat:

Ein Hinweis zu den fünf Bildschirmfotos in diesem Abschnitt: Sie stammen aus dem Mai 2024. Der Menüpfad und die Abfragen sind seither unverändert — der Eintrag steht bis heute im Einstellungsmenü des Projekts, nachzulesen in 00settingsMenuBasics.sh —, Farben und Randbeschriftungen können in eurer Version leicht abweichen.

Auf der Nextcloud nachsehen

Loggt euch in eure Nextcloud ein und geht oben in der Arbeitsleiste auf Dateien. Angelegt wird ein Ordner mit dem Namen raspiblitz, darin liegt die channel.backup:

Die channel.backup selbst bleibt wenige Kilobyte gross und wächst kaum, solange ihr ungefähr gleich viele Kanäle betreibt. Der Ordner wird trotzdem voller: Der RaspiBlitz lädt neben der festen Datei auch die datierte Kopie jeder Änderung hoch. Wer viel öffnet und schliesst, sammelt dort mit der Zeit eine ganze Reihe von Ständen ein. Das ist kein Fehler, sondern gewollt — nur solltet ihr wissen, dass ihr dort irgendwann aufräumen dürft, und dass die jüngste Datei die einzige ist, die ihr im Ernstfall benutzen dürft.

Von Hand prüfen, ob der Upload läuft

Ihr müsst nicht auf den nächsten Kanalschluss warten, um zu sehen, ob die Verbindung steht. Das Skript, das die Funktion ausführt, lässt sich direkt aufrufen:

sudo /home/admin/config.scripts/nextcloud.upload.sh \
     upload /home/admin/backups/scb/channel.backup

Bei Erfolg antwortet es mit File /home/admin/backups/scb/channel.backup has been uploaded. Schlägt es fehl, kommt err='File upload failed' zurück; fehlen die hinterlegten Zugangsdaten, meldet es err='Nextcloud credentials are missing'. Die drei Meldungen stehen so in config.scripts/nextcloud.upload.sh. Ein fehlgeschlagener Upload ist fast immer eine falsche Adresse oder ein Passwort, das die Nextcloud nicht annimmt — siehe den Abschnitt zum App-Passwort weiter oben.

Abschalten lässt sich die Funktion über denselben Menüeintrag; das Skript kennt dafür den Parameter off, der die hinterlegten Zugangsdaten wieder entfernt. Das ist der Weg, wenn ihr eure Node verkauft oder weitergebt — sonst wandert das Passwort mit.

Was diese Sicherung leistet — und was nicht

• Sie bringt eure Kanaldaten ausser Haus. Das ist die eine Trennung, die alle lokalen Kopien nicht schaffen.
• Sie ersetzt kein Seed-Backup. Ohne eure Seedphrase ist die Datei unbrauchbar, und die gehört nicht in dieselbe Cloud.
• Sie sichert die Kanäle von LND. Hochgeladen wird laut Menüskript die channel.backup aus dem LND-Datenverzeichnis; wer den RaspiBlitz mit Core Lightning betreibt, muss sich um seine Sicherung getrennt kümmern.
• Sie kostet ein Passwort im Klartext auf der Node. Mit einem App-Passwort ist der Schaden begrenzt, mit dem Kontopasswort nicht.
• Sie ist kein Ersatz für ein Systembackup. Was ihr sonst noch sichern solltet, steht im Backup- und Restore-Leitfaden für Lightning-Fullnodes, und wie ihr die ganze Node auf neue Hardware hebt, im Beitrag zum Umzug auf neue Hardware.

Wer seine Kanalzustände zusätzlich in einer Oberfläche im Blick behalten will, findet im Beitrag zu Thunderhub und Amboss den zweiten Weg zur Sicherung der Kanaldaten. Und wenn ihr euch fragt, ob eure Version die hier beschriebene Funktion überhaupt hat: Sie steckt seit Jahren im Einstellungsmenü und ist auch in der aktuellen Fassung 1.12.1 vorhanden. Wie ihr aktualisiert, steht in der Anleitung zum RaspiBlitz-Update.

Fazit: Doppelt genäht hält nur, wenn der zweite Faden woanders liegt

Die Nextcloud-Funktion des RaspiBlitz ist in zwei Minuten eingeschaltet und erledigt danach das, was kein lokales Backup kann: Sie bringt die jüngste channel.backup aus dem Haus, automatisch, bei jeder Kanaländerung. Für eine Node, die echtes Geld hält, ist das keine Kür. Der Preis ist ein Zugangsdatensatz im Klartext auf dem Gerät — tragbar, solange dort ein widerrufbares App-Passwort steht und nicht der Generalschlüssel zu eurer Cloud. Und weil die Datei mit einem aus eurer Seed abgeleiteten Schlüssel verschlüsselt ist, gilt weiterhin: Die Cloud sieht davon nichts — solange die Seed nicht danebenliegt.

Schaut gerne hier vorbei für den kompletten Backup & Restore Leitfaden für Fullnodes:

Quellen und weiterführende Links

• lnd/docs/recovery.md — Verschlüsselung der SCB-Datei, DLP-Protokoll, Grenzen der Wiederherstellung und die Warnung vor veralteten Sicherungen
• raspiblitz/home.admin/config.scripts/nextcloud.upload.sh — WebDAV-Zielpfad, Ordnername, Parameter und Meldungen des Skripts
• raspiblitz/home.admin/00settingsMenuBasics.sh — der Menüeintrag und der Pfad der hochgeladenen Datei
• raspiblitz/home.admin/_background.sh — Prüfsummenvergleich, lokale Kopien und der automatische Upload
• raspiblitz/CHANGES.md — Versionsstände des Projekts
• nextcloud/server, Issue 59085 — WebDAV-Zugriff bei aktivierter Zwei-Faktor-Authentisierung braucht ein App-Passwort
• docs.raspiblitz.org — die offizielle Projektdokumentation

The post Raspiblitz SCB Backup auf einer Nextcloud appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Einleitung

In diesem Tutorial geht es explizit darum, wie ihr eure Node auf ein komplett neues Gerät migirieren könnt, mit samt einer neuen SSD. Möchtet ihr die SSD des alten Raspberries weiter verwenden, müsst ihr nichts anderes tun, als die alte SSD an den neuen Raspberry 5 zu hängen, und das Gerät mit einer frisch geflashten SD Karte starten. Das Gerät wird die alten Daten auf der SSD erkennen, und euch die Migration anbieten.

Vorbereitungen

Ihr benötigt für die Migration nur einen Laptop, oder einen Rechner im selben Netzwerk wie die Raspberries. Windows, MacOS oder Linux spielt hierbei keine Rolle. USB Sticks oder ähnliches werden nicht benötigt.

Einrichtung und Synchronisieren

Der neue Raspberry 5 muss zuerst mit einem frischen SD-Karten Image eingerichtet werden. Im Internet gibt es dazu genügend Tutorials. Da ihr bereits einen Raspberry 4 habt, sollte das für euch kein Problem sein. Los gehts auf jedenfall mit Setup a New Raspiblitz, danach <DELETE DATA>. Danach die ganze Einrichtung durchmachen mit Passwörter festlegen, bei der Lightning Implementierung kann NONE gewählt werden, da wir später sowieso alles alles wieder löschen, ausser die Blockchaindaten, um das Migrationfile aufzuspielen

Am Schluss der Einrichtung werdet ihr gefragt, wie ihr die Blockchain synchroniseren wollt. Wählt hier Copy from Computer/Raspiblitz over LAN. Wählt danach Raspiblitz aus.

Es öffnet sich ein Fenster dass euch informiert, dass der Raspi 5 im Bereitschaftsmodus ist:

Öffnet auf dem alten Raspberry 4 das cli-menu, und geht auf die Repair Options, klickt dort auf COPY-SOURCE, und gebt im nächsten Fenster die IP Adresse eures neuen Raspis ein.

Nachdem die IP Adresse eingegeben wurden ist, müsst ihr das A Passwort des neuen Raspberry 5 eingeben.

Anschliessend müsst ihr warten, bis die Synchronisation, beziehungsweise der Kopiervorgang abgeschlossen ist. Das kann je nach Netzwerkgeschwindigkeit 6 bis 12 Stunden dauern.

Sobald die Synchronisation fertig ist, geht ihr zurück auf das Terminal des neuen Raspis, und bestätigt mit ENTER, dass der Kopiervorgang abgeschlossen ist. Der neue Pi wird die Blockchain erkennen, und die Node einrichten und danach Final neu starten.

Weitere Methoden, die Blockchain zu synchroniseren, findet ihr in diesem Artikel:

Migration-File auf dem alten Raspberry 4 erstellen

Als erstes müssen wir ein Backup, beziehungsweise das Migrations-File auf der alten Node erstellen. Dieses Archiv wird anschliessend auf den neuen Blitz kopiert, und dort wiederherstellt.

Öffnet das cli-menu und geht wieder auf die Repair Options. Wählt dort auf MIGRATION aus:

Der Raspi erstellt jetzt ein Migration File, sobald er fertig ist, bekommt ihr Information dazu in einem neuen Abschnitt. Hier findet ihr Informationen dazu, wie ihr das Migration-File auf euren lokalen Rechner transferiert:

Führt den Befehl, entsprechend eures Betriebsystems im Terminal des Rechner nun aus. Ihr werdet auf eurem Rechner nach einem Passwort gefragt. Gebt hier das Passwort A vom alten Raspiblitz ein. Die Datei wird nun auf euren Rechner kopiert. Die Datei landet im Verzeichnis, indem ihr euch beim Kopiervorgang befindet. In den meissten Fällen ist das der Home-Ordner.

Auf einem Linux Rechner könnt ihr md5sum <dateienname> ausführen um die Prüfsumme zu vergleichen. Auf MacOS wäre es einfach md5 -r <dateienname>
Auf Windows ist der Befehl etwas komplexer und ist je nach Pfad der Datei anzupassen:

certutil -hashfile "C:\Users\benutzername\<dateienname" MD5

Habt ihr die Datei überprüft, könnt, und müsst ihr den alten Blitz jetzt herunterfahren.

Migration File auf dem neuen Gerät ausführen

Der neue Blitz, falls selber zusammengestellt, ist wie in den Vorbereitungen nun synchronisiert und bereit. Damit ihr nun in das Migrationsmenu kommt, müsst ihr den Pi zuerst zurücksetzten. Geht im cli-menu wieder in die Repair Options, und wählt hier nun RESET-HDD - Delete HDD Data but keep Blockchain

Überspringt in den nächsten Schritt nun jedliche Sicherungen von LND oder sonstiges, ihr benötigt keine Backups oder Sicherungen, da auf dem neuen Blitz noch nichts vorhanden ist. Im Terminal werdet ihr nochmals gefragt, ob ihr euch sicher seid, alles zu löschen, bestätigt mit Enter. Der Blitz fährt danach runter. Entfernt die SD Karte des neuen Blitzes, und flasht ein frisches Image darauf.

Startet mit einem frischen Image den neuen Raspi. Stellt ihr nun eine neue SSH Verbindung her, werdet ihr zwangsläufig eine Fehlermeldung bekommen. Ihr werdet gewarnt dass, das Gerät seine Identität geändert hat. Dies kommt davon, dass der Blitz beim flashen eines neuen Images ein neuen Key-Pair generiert. Euer Rechner hat aber noch den alten Public-Key zu der jeweiligen IP Adresse gespeichert. Ihr müsst also den alten Public Key aus der known-hosts im SSH Ordner löschen. Ihr könnt das einfach mit

ssh-keygen -R <IP-Adresse oder Hostname>

auf Windows, Mac und Linux System lösen. IP Adresse entsprechend anpassen.

Danach kommt in das Setup Menu mit der bekannten Auswahl:

Wählt hier nun FROMBACKUP aus. Im nächsten Fenster wählt ihr USE BLOCKCHAIN:

Wählt im nächsten Fenster DELETE DATA:

Als nächstes werdet ihr aufgefordert, das Migration-File bereit zu stellen, Kopiert nun mit dem entsprechenden Befehl auf eurem Computer das Migration File wieder zurück auf das neue Gerät. Führt diesen Befehl auf eurem Rechner. Der Befehl muss dort ausgeführt werden, indem sich das Raspiblitz tar.gz Archiv befindet:

Ihr werdet auf dem Rechner nach einem Passwort gefragt. Gebt hier raspiblitz ein. Anschliessend wird die Datei auf den Raspiblitz geladen. Ist der Upload fertig. bestätigt mit Enter auf dem neuen Raspiblitz. Der Raspiblitz wird euch bescheid sagen, wenn er das Archiv gefunden hat: Bestätigt mit Enter.

Anschliessend startet das Setup. Ihr müsst nun wieder eure Passwörter A, B und C festlegen. Benutzt am besten die selben, wie auf eurem alten Raspiblitz.

Der Raspiblitz wird nun die Node konfigurieren, und eure alten Daten auf die neue Node übernehmen. Wartet ab, und seid geduldig. Nach dem die Konfiguration abgeschlossen worden ist, gibts nen finalen Reboot. Bestätigt diesen, und lasst die Kiste neu starten. Anschliessend benötigt der neue Raspiblitz einige Zeit, um den Rest der Blockchain zu resynchronisieren.

Festplatte des alten Raspberries löschen

Habt ihr die Node erfolgreich migriert, darf der alte Blitz auf keinen Fall wieder ans Internet. Stellt sicher, dass ihr die Node ausser Betrieb nehmt. Löscht die Festplatte am besten auf einem anderen Rechner. Ihr könnt auch den alten Blitz nochmals OHNE Netzwerkkabel in betrieb nehmen, einen Monitor und eine Tastatur anschliessen, euch mit euren alten Credentials einloggen, und die Festplatte mit diesem Befehl löschen:

sudo rm -R /mnt/hdd/*

Nochmals, stellt bitte sicher, dass ihr den alten Blitz nicht mehr mit der alten Festplatte online nehmt, es besteht sonst die grosse Gefahr, dass all eure Lightning Kanäle geschlossen werden, sollte die Node mit den alten Daten Online gehen.

Weitere Hinweise

Hattet ihr auf eurer alten Node das SCB Auto Backup laufen lassen, stellt sicher, dass ihr den selben USB Stick auf dem neuen System verwendet.

Überprüfen könnt ihr den status des Backups mit:

sudo ./config.scripts/blitz.backupdevice.sh status

Stelt sicher, dass die UUID des USB Sticks auch in der etc/fstab enthalten ist:

UUID='1B08-0CE4' /mnt/backup vfat defaults 0 2

Stellt sicher, dass die UUID die, die des USB-Sticks eurerseits ist.

Tipps zur Sicherung der Node

Wir haben ein grossen Beitrag zur Sicherung und Wiederherstellung von Lightning Nodes geschrieben. Ich empfehle euch, den Beitrag zu lesen und ihn gut zu studieren, um euch vor Ausfällen abzusichern:

Fazit

Ihr habt nun erfolgreich eure Node auf den nen Raspberry migriert. Alle eure Apps die ihr vorher hattet, sind nun auch auf dem neuen Blitz vorhanden. Die Kanäle gehen wieder online, sobald der Blitz den Rest der Chain synchronisiert hat. Herzlichen Glückwunsch zur neuen Node!

The post Raspiblitz auf neue Hardware und neue SSD migrieren appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dieser Beitrag zeigt euch beides: wann der Beschleuniger überhaupt der richtige Griff ist, und wie ihr ihn dann benutzt. Dazu die Bedingungen für die kostenlose Variante — und zwar die, die ViaBTC selbst dokumentiert, nicht die, die im Umlauf sind.

Bitcoin Transaktion beschleunigen: drei Wege, in dieser Reihenfolge

Eine Transaktion hängt fest, wenn ihre Gebührenrate unter dem liegt, was die Miner gerade in einen Block aufnehmen. Sie ist dabei nicht verloren, sie wartet nur. Was ihr dagegen tun könnt, hängt nicht am Mining-Pool, sondern an der Transaktion selbst.

• RBF, Replace-by-Fee. Ihr ersetzt die wartende Transaktion durch dieselbe Zahlung mit höherer Gebühr. Das ist der saubere Weg, weil ihr ihn allein gehen könnt und niemanden um etwas bitten müsst. In den Release Notes zu Bitcoin Core 28.0 steht dazu wörtlich: „The default value of the -mempoolfullrbf configuration option has been changed from 0 to 1". Seither ersetzen die Knoten im Netz auch Transaktionen, die nicht ausdrücklich als ersetzbar markiert waren.
• CPFP, Child Pays For Parent. Geht RBF nicht, weil eure Wallet es nicht anbietet, könnt ihr das Wechselgeld der hängenden Transaktion mit einer zweiten, hoch bezahlten Transaktion weiterschicken. Die Miner nehmen dann beide zusammen, weil sich das für sie erst zusammen rechnet.
• Der Beschleuniger. Erst wenn beides ausfällt, wird ein fremder Mining-Pool gebeten, eure Transaktion bevorzugt einzupacken. Ihr gebt damit die Sache aus der Hand und bekommt keine Zusage, wann etwas passiert.

Wie RBF und CPFP im Einzelnen funktionieren und welche Wallets was können, steht ausführlich im Beitrag Bitcoin Gebühr nachträglich erhöhen mit RBF und CPFP. Wer wissen will, wie die Gebührenrate überhaupt zustande kommt, findet das unter Bitcoin Onchain Gebühren einfach berechnen.

Was der ViaBTC Accelerator technisch macht

Der Accelerator ist ein Dienst des Mining-Pools ViaBTC. Ihr reicht dort die ID einer unbestätigten Transaktion ein, und der Pool nimmt sie in die Liste auf, die seine Miner bevorzugt in den nächsten Block packen. Am Netz ändert das nichts: Eure Transaktion bekommt keine höhere Gebühr, sie wird nur bei einem einzelnen Pool vorgezogen.

Warum das keine Zusage ist

Daraus folgt die entscheidende Einschränkung, und der ursprüngliche Artikel hat sie zu leise gesagt: Es passiert erst etwas, wenn ausgerechnet ViaBTC den nächsten Block findet. Ein Pool mit einem Zehntel der Rechenleistung findet im Schnitt jeden zehnten Block; bis dahin liegt eure Transaktion genauso da wie vorher. Der Beschleuniger verkürzt also nicht die Wartezeit, er verbessert nur die Chance bei einem von mehreren Blockproduzenten.

Wer sich fragt, wie viel Macht ein einzelner Pool über die Zusammenstellung eines Blocks überhaupt hat, findet die längere Antwort in Stratum V2 und die Coinbase-Hoheit. Genau diese Hoheit ist es, die der Beschleuniger benutzt — und das ist ein Grund mehr, ihn nicht zum Normalfall zu machen.

Die Bedingungen für die kostenlose Beschleunigung

Hier stand in der ursprünglichen Fassung dieses Artikels eine Zahl, die sich an ViaBTCs eigener Dokumentation nicht belegen lässt. Das Hilfecenter von ViaBTC nennt für die Gratis-Einreichung diese Anforderungen:

• Gebührenrate: „the transaction fee rate should be ≥ 0.0001 BTC/KB". Das sind rund 10 Satoshi je virtuellem Byte, nicht 20, wie hier früher zu lesen war.
• Grösse: „a single transaction must be ≤0.5 KB", also höchstens rund 500 Bytes.
• Kontingent: „ViaBTC supports 20 FREE acceleration chances per hour". Diese zwanzig Plätze teilen sich alle Nutzer weltweit. Ein zusätzliches Tageslimit je Konto, wie es hier früher stand, steht in keiner der Quellen.
• Konto: Für die Einreichung müsst ihr angemeldet sein.

Dazu nennt das Hilfecenter fünf Gründe, aus denen eine kostenlose Einreichung abgelehnt wird — zwei davon fehlten hier bisher: zu niedrige Gebühr, zu grosse Transaktion, ausgeschöpftes Stundenkontingent, noch unbestätigte vorangehende Transaktionen in derselben Kette, und eine Transaktion, die als double spent markiert ist. Und: Eine einmal abgeschickte Einreichung lässt sich weder zurücknehmen noch erstatten.

Ein offener Punkt in eigener Sache. ViaBTCs Weboberfläche hat zeitweise 20 Satoshi je virtuellem Byte angezeigt, das Hilfecenter dokumentiert 0,0001 BTC pro KB. Welche Angabe heute in der Oberfläche steht, liess sich beim Überarbeiten nicht nachprüfen. Verlasst euch deshalb auf die Zahl, die euch die Seite im Moment der Einreichung nennt, und nehmt die dokumentierte als Untergrenze.

Vorbereitung: Konto bei ViaBTC

Eröffnet ein Konto bei ViaBTC. Dafür genügt eine Wegwerf-Adresse, wenn ihr eure gewöhnliche Mailadresse nicht mit einem Mining-Pool verbinden wollt. Geht danach in der oberen Leiste auf Tools und dort auf Transaction Accelerator. Ihr seht dann, wie viele der zwanzig Plätze in der laufenden Stunde noch frei sind.

Die Bildschirmfotos in diesem Abschnitt stammen vom Mai 2024. Die Oberfläche kann heute anders aussehen; der Weg über Tools und die beiden Felder für ID und Einreichung sind seither unverändert dokumentiert.

Die Transaktions-ID heraussuchen

Als nächstes braucht ihr die txID eurer Transaktion. Die findet ihr in eurer Wallet bei der ausgehenden, noch unbestätigten Zahlung. In der BitBox-App zum Beispiel über die Lupe rechts neben der ausstehenden Transaktion; es öffnet sich ein Fenster, und die Transaktions-ID steht ganz unten.

Im selben Fenster steht auch die Grösse der Transaktion. Im Beispiel sind es 203 Bytes, also deutlich unter der Grenze von 0,5 KB.

Zeigt eure Wallet die Grösse nicht an, gebt die ID auf mempool.space ein und schaut unten unter Details nach:

Warum die Grösse einer Transaktion überhaupt so stark schwankt, hat mit der Zahl der verwendeten Eingänge zu tun — nachzulesen unter Was bedeutet UTXO im Bitcoin Netzwerk und, mit Blick auf die Gebühren, unter Mit UTXO Management Bitcoin Onchain Gebühren sparen. Wie der Mempool selbst arbeitet, steht hier:

Die Transaktion einreichen

Erfüllt die Transaktion die Bedingungen, tragt ihr die Transaktions-ID in das Feld ein und klickt auf Free Submission. Prüft die ID vorher Zeichen für Zeichen — eine falsche ID lässt sich nicht zurücknehmen, und der Platz in der Stunde ist verbraucht.

Ihr bekommt eine Meldung, dass die Transaktion aufgenommen wurde. Danach ist nichts weiter zu tun.

Wann die Transaktion tatsächlich im Block landet

Sobald ViaBTC einen Block findet, wird eure Transaktion mit aufgenommen — auch dann, wenn die üblichen Gebühren in diesem Moment deutlich höher liegen. Wann das ist, sagt euch niemand, und ViaBTC sagt es ausdrücklich auch nicht zu. Bleibt die Bestätigung über Stunden aus, liegt das nicht an eurer Einreichung, sondern daran, dass der Pool in dieser Zeit keinen Block gefunden hat.

Wenn die Transaktion die Bedingungen nicht erfüllt

Ist die Transaktion grösser als 0,5 KB oder liegt die Gebühr unter der Schwelle, bleibt für den Beschleuniger nur der kostenpflichtige Dienst. Einen festen Preis nennt ViaBTC dafür nicht; das Hilfecenter schreibt, der Preis werde berechnet „based on factors such as transaction volume, current cryptocurrency price, and so on", bezahlt wird in BTC, BCH oder LTC. Die früher hier genannte Grössenordnung von rund 200 US-Dollar ist an keiner Stelle belegt und deshalb entfallen.

Der bessere Weg ist ohnehin der, der euch nichts kostet: Liegt eure Transaktion unter der Gebührenschwelle, hebt sie per CPFP darüber. Hardware-Wallets bieten das oft nicht an; welche Wallet was kann, steht in Welche Bitcoin Wallets gibt es. Eine Seedphrase nur zu diesem Zweck in eine Software-Wallet zu importieren ist ein schlechter Tausch — ihr löst ein Wartezeitproblem und handelt euch ein Sicherheitsproblem ein. RTL, das auf Full-Node-Systemen wie RaspiBlitz oder Umbrel läuft, beherrscht die Gebührenanhebung ebenfalls.

Was ich anders mache

Ich habe den Beschleuniger seit dem Erscheinen dieses Artikels kaum noch gebraucht, und das liegt nicht an ViaBTC. Es liegt daran, dass RBF inzwischen im ganzen Netz greift und meine Wallets es anbieten. Wenn bei mir eine Zahlung liegen bleibt, hebe ich die Gebühr in der Wallet an und habe die Sache damit selbst in der Hand, statt darauf zu warten, dass ein bestimmter Pool Glück hat.

Wo ich den Beschleuniger trotzdem empfehle: bei einer Transaktion aus einer Hardware-Wallet, die weder RBF anbietet noch brauchbares Wechselgeld für CPFP hinterlassen hat. Genau dafür ist er gut — und für nicht viel mehr. Und ich setze die Gebühr beim Senden lieber gleich richtig, statt sie hinterher zu reparieren; dabei hilft ein Blick in den Mempool mehr als jede Faustregel.

Fazit: Der Beschleuniger ist die Rückfallebene, nicht die Abkürzung

Der ViaBTC Accelerator tut, was er verspricht, und er kostet in der Gratis-Variante nichts ausser einem Konto. Aber er ist ein Bittgesuch an einen einzelnen Mining-Pool, kein Eingriff ins Netz: Er hilft erst, wenn ausgerechnet dieser Pool den nächsten Block findet, er nimmt nur kleine Transaktionen über einer Mindestgebühr, und zwanzig Gratis-Plätze pro Stunde für die ganze Welt sind schnell weg.

Wer eine Bitcoin Transaktion beschleunigen will, greift deshalb zuerst zu RBF, dann zu CPFP und erst danach hierher. Das ist der Unterschied zwischen selbst handeln und hoffen — und Hoffen war noch nie eine Gebührenstrategie.

Quellen und weiterführende Links

• ViaBTC Help Center: BTC Transaction Accelerator — Bedingungen der kostenlosen Einreichung, Ablehnungsgründe und Preisbildung des kostenpflichtigen Dienstes. Stand der Seite: 08.05.2024.
• ViaBTC — der Mining-Pool und die Oberfläche des Accelerators unter Tools.
• Bitcoin Core 28.0 Release Notes vom 02.10.2024 — Umstellung von -mempoolfullrbf auf den Standardwert 1.
• mempool.space — Transaktionsgrösse, virtuelle Grösse und Gebührenrate einer einzelnen Transaktion nachschlagen.
• Bitcoin Gebühr nachträglich erhöhen mit RBF und CPFP — der ausführliche Weg zu den beiden Verfahren, die vor dem Beschleuniger kommen.

The post Bitcoin Transaktionen mit ViaBTC gratis beschleunigen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dieser Artikel ist am 30. August 2026 überarbeitet worden. Die Versionsstände, der Platzbedarf und der Pflegezustand der drei Projekte haben sich seit der Erstfassung deutlich verschoben, und der oft zitierte Geschwindigkeitsvergleich von Sparrow ist inzwischen über vier Jahre alt. Beides steht weiter unten im Detail.

Electrum Server selber hosten: was der Dienst leistet und was er voraussetzt

Ein Electrum Server ist die Brücke zwischen eurer Wallet und der Blockchain. Leichte Wallets laden nicht die gesamte Kette herunter, sondern fragen einen Server: Welche Transaktionen gehören zu diesen Adressen, und wie viele Bestätigungen haben sie? Genau diese Frage verrät alles – wer sie beantwortet, kennt eure Adressen. Deshalb ist der eigene Server kein Bastelprojekt, sondern der Unterschied zwischen einem privaten und einem beobachteten Wallet. Die Sparrow Wallet arbeitet so, ebenso die BitBox02 von Shift Crypto, für die wir eine eigene Anleitung zur Verbindung mit einer Raspiblitz Full Node haben.

Der Server selbst rechnet nichts nach. Er baut aus den Daten einer eigenen Bitcoin Full Node einen Suchindex über alle Adressen auf, damit die Antwort in Millisekunden statt in Stunden kommt. Daraus folgt die wichtigste Voraussetzung, die in vielen Anleitungen untergeht: Keiner der drei Server läuft auf einer Node mit gekürzter Blockchain. Wer Pruning eingeschaltet hat, um Platz zu sparen, kann keinen Electrum Server danebenstellen. Die Dokumentation von electrs verlangt Bitcoin Core ausdrücklich mit -prune=0, ElectrumX schreibt vor, dass der Dienst auf einem „non-pruning bitcoin daemon“ laufen muss, und Fulcrum braucht txindex=1, was ohne vollständige Blockchain nicht zu haben ist.

Rechnet also grosszügig. Die Blockdateien allein lagen im Beispiel der electrs-Dokumentation im Juli 2026 bei rund 800 GB, dazu kommt der Index des jeweiligen Servers. Eine 1-TB-SSD wird damit knapp; wie ihr sie ohne Neuaufbau tauscht, steht in unserer Anleitung zum Klonen einer Full-Node-SSD von 1 TB auf 2 TB.

Was für den eigenen Server spricht

Der Hauptgrund ist die Privatsphäre. Fragt eure Wallet einen öffentlichen Server, dann weiss dessen Betreiber, welche Adressen zusammengehören, wie viel darauf liegt und wann ihr nachschaut. Diese Verknüpfung lässt sich nachträglich nicht mehr aufheben – sie ist der Gegenspieler zu allem, was wir unter Bitcoin privat und anonym versenden beschrieben haben.

Dazu kommen drei praktische Gründe. Ihr entscheidet selbst, wann aktualisiert wird und ob ein Update überhaupt eingespielt wird. Ihr hängt nicht an der Verfügbarkeit eines fremden Dienstes, der ohne Vorwarnung abgeschaltet werden kann. Und jeder zusätzliche unabhängige Server macht das Netz als Ganzes widerstandsfähiger. Wer den Aufwand nicht selbst tragen will, kann übergangsweise unseren privaten Electrum Server nutzen – das bleibt aber Vertrauen in einen Dritten, auch wenn dieser Dritte wir sind.

electrs

electrs ist in Rust geschrieben und beschreibt sich selbst als „efficient re-implementation of Electrum Server“. Es ist der sparsamste der drei und der einzige, der kein txindex=1 in der bitcoin.conf verlangt – die Dokumentation stellt ausdrücklich fest, dass txindex für die Bitcoin-Node nicht nötig ist. Das spart nicht nur Platz, sondern auch einen kompletten Reindex, falls eure Node bisher ohne lief. Auf fertigen Node-Distributionen ist electrs deshalb meist die vorinstallierte Wahl; im Umbrel App Store steht derzeit die Fassung 0.11.1-patch.1.

Ressourcenanforderungen

• Indexgrösse: rund 7 Prozent der Blockdateien, während des ersten Aufbaus vorübergehend bis etwa 14 Prozent. Im Beispiel der Dokumentation vom Juli 2026 sind das 56 GB.
• Indexaufbau: stark hardwareabhängig. Die Dokumentation nennt rund 18 Stunden auf einem ODROID-HC1 mit 2 GB RAM und SSD, und rund 2 Stunden auf einer Maschine mit 6 Kernen, 32 GB RAM und NVMe.
• Weitere Anforderungen: Bitcoin Core ab Version 31, gestartet mit -server=1 -rest=1 -prune=0. Kein txindex nötig.

Verwendung
Optimal für einzelne Anwender, die den Server auf der eigenen Node betreiben und wenig Plattenplatz übrig haben.

Vorteile

• mit Abstand der kleinste Index der drei
• kein txindex=1 in der bitcoin.conf nötig, also auch kein Reindex der Node
• läuft auch auf schwacher Hardware zuverlässig

Nachteile

• Auf der Release-Seite liegen nur Quelltextarchive, keine fertigen Binärdateien. Übersetzen oder ein fertiges Paket der Node-Distribution nehmen.
• Der kleine Index wird mit Rechenzeit bezahlt: Was nicht gespeichert ist, muss bei der Abfrage aus den Blockdateien geholt werden.

ElectrumX

Bei ElectrumX ist seit der Erstfassung dieses Artikels das Wichtigste passiert, und es steht in keinem Changelog, sondern in den Projektbeschreibungen: ElectrumX ist nicht mehr ein Projekt, sondern zwei. Das ursprüngliche Repository von Neil Booth trägt heute die Zeile „For a future network with bigger blocks“. Die Electrum-Entwickler führen daneben einen eigenen Zweig und begründen ihn damit, der ursprüngliche Autor habe „dropped support for Bitcoin, which we intend to keep“. Ein Datum nennt keine der beiden Seiten, und Booth selbst äussert sich in seinem README nicht dazu – die Aussage über den Wegfall stammt also von der abspaltenden Seite. An der praktischen Folge ändert das nichts: Wer heute ElectrumX für Bitcoin installiert, nimmt die Fassung von spesmilo.

Diese Fassung lebt: Version 2.0.0 ist am 3. Juli 2026 erschienen. Das gilt allerdings nicht für alles, was ElectrumX heisst. Wer im Umbrel App Store auf ElectrumX klickt, bekommt 1.16.0-patch.3 – also genau die Fassung, die Sparrow im Februar 2022 vermessen hat. Das ist immerhin konsequent.

Ressourcenanforderungen

• Indexgrösse: Die Dokumentation nennt gut 46,9 GB – allerdings gemessen bis Blockhöhe 611'600, also auf dem Stand von Anfang 2020. Eine aktuelle Zahl liefert das Projekt nicht; empfohlen werden 70 bis 80 GB freier Platz vor dem Start.
• Indexaufbau: mehrere Tage, ebenfalls nach älteren Angaben der Dokumentation. Der Index lässt sich auf einer stärkeren Maschine vorbereiten und übertragen.
• Weitere Anforderungen: txindex=1 in der bitcoin.conf, ausdrücklich auf einer nicht gekürzten Node. War txindex bisher aus, muss die Node einmal komplett neu indexieren.

Verwendung
Für Betreiber, die einen öffentlich erreichbaren Server anbieten wollen und mit Python-Umgebungen umgehen können.

Vorteile

• kleinerer Index als Fulcrum
• deutlich schnellere Abfragen als electrs, jedenfalls im Vergleich von 2022
• als Python-Paket über PyPI installierbar, ohne Compiler

Nachteile

• Die Dokumentation zu Platzbedarf und Aufbauzeit ist seit Jahren nicht nachgeführt worden. Ihr plant hier mit Zahlen, die niemand mehr bestätigt.
• Zwei Repositories mit demselben Namen, von denen nur eines ausdrücklich für Bitcoin gepflegt wird. Die Verwechslungsgefahr ist real.
• txindex=1 erzwingt einen Reindex, wenn die Node bisher ohne lief.

Der frühere Satz „nicht für einen Raspberry Pi geeignet“ ist übrigens gestrichen, und zwar aus einem einfachen Grund: Der Vergleich, auf den sich dieser Artikel stützt, lief genau dort. Sparrow hat ElectrumX 1.16 auf einem Raspberry Pi 4 mit 8 GB RAM getestet. Es läuft, es ist nur nicht schnell.

Fulcrum

Fulcrum ist in C++ geschrieben, wird am aktivsten gepflegt und ist das genaue Gegenteil von electrs: Es speichert grosszügig, um bei der Abfrage nichts mehr nachrechnen zu müssen. Version 2.1.2 ist am 20. August 2026 erschienen – von den drei Projekten der jüngste Stand, und der Umbrel App Store liefert ihn bereits aus.

Ressourcenanforderungen

• Indexgrösse: rund 133 GB für Bitcoin mainnet laut README. Das ist gut das Doppelte von electrs.
• Arbeitsspeicher: Das README nennt 1 GB RAM als Minimum. Die Belastung liegt hier klar auf der Platte, nicht im Speicher.
• Weitere Anforderungen: txindex=1 in der bitcoin.conf, ausdrücklich gefordert.

Verwendung
Für alle, die Antwortzeiten wollen und den Platz dafür haben – egal ob als persönlicher oder als öffentlicher Server.

Vorteile

• fertige Binärdateien für Linux x86_64, Linux ARM64 und Windows 64 Bit. Die ARM64-Variante läuft damit auch auf einem Raspberry Pi, ohne Compiler.
• nach dem Indexaufbau die mit Abstand schnellsten Abfragen
• der aktivste Entwicklungsstand der drei

Nachteile

• mit rund 133 GB der grösste Platzbedarf
• txindex=1 nötig, also gegebenenfalls ein Reindex der Node
• für macOS gibt es keine fertige Binärdatei, dort wird übersetzt

Der Sparrow-Vergleich und was er heute noch wert ist

Craig Raw hat für Sparrow Wallet die drei Server direkt gegeneinander vermessen. Diese Zahlen kursieren seither in jeder Diskussion zum Thema – auch in der Erstfassung dieses Artikels, dort allerdings ohne Datum und ohne Link. Beides wird hier nachgeholt, weil beides den Wert der Zahlen bestimmt. Der Testbericht trägt den Stand 1. Februar 2022.

Getestet wurde auf einem Raspberry Pi 4 mit 8 GB RAM unter Ubuntu 21.10 in 64 Bit, mit einer externen 1-TB-USB-SSD und einer Wallet mit rund 3000 benutzten Adressen. Die geprüften Fassungen waren ElectrumX 1.16, electrs 0.9.4 und Fulcrum 1.6.0.

Wallet initial Start

Wallet Refresh

Testergebnisse

Test 1: Initial Load

• Fulcrum lädt in etwa 1,4 bis 2,3 Sekunden.
• ElectrumX braucht 40,7 bis 54,1 Sekunden.
• electrs liegt bei 322 bis 428 Sekunden.

Zusammenfassung: Fulcrum war rund 22-mal schneller als ElectrumX und etwa 300-mal schneller als electrs.

Test 2: Wallet Refresh

• Fulcrum führt mit 7,4 bis 14,2 Sekunden.
• electrs holt deutlich auf und liegt bei 11,2 bis 17,6 Sekunden.
• ElectrumX fällt auf 66,2 bis 114,5 Sekunden zurück.

Zusammenfassung: Fulcrum war beim Aktualisieren etwa 8-mal schneller als ElectrumX und 1,5-mal schneller als electrs.

Warum die Zahlen mit Vorsicht zu lesen sind

Der Erklärungsansatz von damals gilt weiter und ist der eigentliche Ertrag des Tests: electrs speichert bewusst nicht alles, was für eine schnelle Zuordnung nötig wäre, und holt den Rest bei jeder Abfrage aus den Blockdateien nach. Das kostet Rechenzeit und macht sich beim erstmaligen Laden einer Wallet mit vielen Adressen brutal bemerkbar. ElectrumX und Fulcrum legen diese Zuordnung im Index ab und antworten deshalb sofort. Dass Fulcrum dabei nochmals klar vorne liegt, hängt an der Umsetzung in C++ gegenüber Python bei ElectrumX.

Trotzdem: Diese Messung ist von Februar 2022. Zwei der drei geprüften Fassungen sind seither um mehrere Hauptversionen weitergezogen – electrs von 0.9.4 auf 0.11.1, Fulcrum von 1.6.0 auf 2.1.2, ElectrumX von 1.16 auf 2.0.0. Die Blockchain ist in dieser Zeit um Jahre gewachsen. Wer die Sekundenwerte heute als Tatsache zitiert, zitiert eine Momentaufnahme aus einer anderen Zeit. Die Rangfolge ist plausibel geblieben, weil sie aus dem Aufbau der Indizes folgt und nicht aus einer Optimierung. Die Faktoren sind es nicht. Einen neueren, unabhängigen Vergleich aller drei Server auf identischer Hardware gibt es nach unserer Recherche nicht.

Worauf ihr achten solltet

• Zuerst der Plattenplatz, dann alles andere. Rechnet die Blockdateien und den Index zusammen, bevor ihr euch für einen Server entscheidet. Zwischen electrs und Fulcrum liegen beim Index gut 75 GB – das entscheidet auf einer 1-TB-SSD alles.
• Prüft, ob eure Node txindex=1 hat, bevor ihr ElectrumX oder Fulcrum installiert. Fehlt der Eintrag, indexiert Bitcoin Core einmal komplett neu, und das dauert je nach Hardware Stunden bis Tage.
• Pruning und Electrum Server schliessen sich aus. Wer Platz gespart hat, indem er die Blockchain kürzen liess, muss diese Entscheidung zuerst zurücknehmen.
• Bei ElectrumX auf das richtige Repository achten. Für Bitcoin gepflegt wird ausdrücklich die Fassung der Electrum-Entwickler unter spesmilo/electrumx. Eine Anleitung, die noch auf kyuupichan/electrumx zeigt, gehört gegengeprüft.
• Schaut nach, welche Version eure Node-Distribution wirklich ausliefert. Ein App Store kann jahrealte Fassungen führen, ohne das anzuschreiben. Welche Distribution zu euch passt, haben wir in RaspiBlitz vs. Umbrel verglichen.
• Plant den ersten Indexaufbau ein. Egal welcher Server: Der erste Durchlauf dauert und belastet die Node. Startet ihn nicht an dem Abend, an dem ihr eine Zahlung erwartet.

Fazit: Die Wahl entscheidet der Plattenplatz, nicht der Benchmark

Alle drei Server erfüllen ihren Zweck, und der wichtigste Schritt ist ohnehin getan, sobald eure Wallet überhaupt einen eigenen Server befragt statt eines fremden. Die Entscheidung zwischen ihnen fällt danach an drei nüchternen Fragen:

• electrs, wenn der Platz knapp ist oder eure Node ohne txindex läuft. Ihr bezahlt den kleinen Index mit langsamem erstmaligem Laden – im Alltag, beim Aktualisieren, ist der Abstand klein.
• Fulcrum, wenn ihr die 133 GB übrig habt. Es ist der schnellste, der am aktivsten gepflegte und der einzige mit fertigen Binärdateien für Linux und Windows. Für die meisten Aufbauten ist es heute die naheliegende Wahl.
• ElectrumX, wenn ihr in einer Python-Umgebung zu Hause seid oder einen öffentlichen Server betreibt und die Fassung der Electrum-Entwickler bewusst wollt. Rechnet damit, dass ihr die Angaben zum Platzbedarf selbst nachmessen müsst.

Und wenn ihr aus diesem Artikel nur einen Satz mitnehmt, dann diesen: Prüft vor dem Kauf der nächsten SSD, welcher der drei Server darauf landen soll. Es ist billiger, das vorher zu wissen.

Quellen und weiterführende Links

• romanz/electrs – Projektseite und README, Angaben zu Indexüberhang und txindex.
• electrs, Dokumentation zur Inbetriebnahme – Anforderungen an Bitcoin Core, Indexgrösse, Beispielwerte zum Indexaufbau.
• electrs, Release-Übersicht – Version 0.11.1 vom 22. Februar 2026.
• kyuupichan/electrumx – das ursprüngliche Repository und seine heutige Ausrichtung.
• spesmilo/electrumx – die von den Electrum-Entwicklern gepflegte Fassung und die Begründung der Abspaltung.
• ElectrumX, Dokumentation und Changelog – Version 2.0.0 vom 3. Juli 2026.
• ElectrumX, HOWTO – Pflicht zu txindex=1 und zur nicht gekürzten Node, Angaben zum Platzbedarf.
• cculianu/Fulcrum – README mit Platzbedarf, Arbeitsspeicher und txindex-Anforderung.
• Fulcrum, Release-Übersicht – Version 2.1.2 vom 20. August 2026 und die angebotenen Binärdateien.
• Sparrow Wallet, Server Performance – der Geschwindigkeitsvergleich vom 1. Februar 2022 samt Testaufbau.
• Umbrel App Store: electrs, ElectrumX und Fulcrum – die dort ausgelieferten Fassungen, abgerufen am 30. August 2026.

The post ElectRS vs ElectrumX vs Fulcrum appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Vorbereitungen

Auf eurer Lightning Full Node muss LND laufen, und es müssen natürlich ein paar Kanäle vorhanden sein, damit das ganze Sinn ergibt. Lightningshell für LND benötigt ihr nicht. Das ganze lässt sich normal via SSH Zugang installieren. Loggt euch via SSH auf euer Umbrel System ein. Zuerst erstellen wir uns ein paar Standard Ordner, und notieren uns die LND Container IP:

sudo mkdir -p /mnt/data/upgrades/charge-lnd
sudo touch /mnt/data/upgrades/charge-lnd/charge.config

Der erste Befehl erstellt den Ordner, indem wir unseren Konfigurationsdatei ablegen, der zweite Befehl die Konfigurationsdatei charge.config

Danach müssen wir uns die IP des LND Containers notieren, das geht mit dem Befehl:

sudo cat ~/umbrel/.env

Wir bekommen eine Übersicht aller Verbindungsdaten zum den Diensten wie Bitcoin Core und LND. Wir notieren uns die LND IP Adresse:

Das wäre in meinem Fall die IP 10.21.21.9 und der Standard LND gRPC Port 10009

Charge LND installieren und ausführen

Charge LND müssen wir nicht direkt installieren. Das ganze kommt fertig in einem Docker Container. Da Umbrel bereits Docker komplett eingerichtet hat, müssen wir auch nichts mehr installieren. In einem nächsten Artikel zum Blitz, zeigen wir euch die Installation auf einem System ohne Docker.

Um Charge LND auszuführen benötigen wir nur einen einzigen Befehl. Dieser stellt sicher dass sich charge-lnd mit dem Umbrel Docker Netzwerk verbinden kann, sich mit LND selber befinden kann und ausserdem weiss wo sich wichtige Dateien wie die admin.macaroon befinden. Mit diesem Befehl führt ihr charge-lnd einmal aus, und ruft die Konfigurationsdatei ab:

docker run --rm -it --network=umbrel_main_network -e GRPC_LOCATION=LND_IP:10009 -e LND_DIR=/data/.lnd -e CONFIG_LOCATION=/app/charge.config -v /root/umbrel/app-data/lightning/data/lnd:/data/.lnd -v
/mnt/data/upgrades/charge-lnd/charge.config:/app/charge.config accumulator/charge-lnd:latest

In diesem Beispiel müsst ihr die LND_IP mit eurer notierten LND IP Adresse ersetzen! Führt ihr diesem Befehl aus, wird erstmal nicht viel passieren, da eure charge.config noch leer ist.

Charge-lnd konfigurieren

Die Konfigurationsmöglichkeiten für charge-lnd sind wirklich enorm. Deshalb zeigen wir euch erstmal nur eine Konfiguration, die verhindert, dass der Kanal unter die Kanal-Reserve leergezogen wird, was zu einem Force-Closure führen wird. Dies ist ein LND Bug der erst mit der Version 0.18 behoben wird.

Öffnet mit

sudo nano /mnt/data/upgrades/charge-lnd/charge.config

die Konfigurationsdatei, und platziert folgenden Inhalt hinein:

[default]
# no strategy, just defaults
# not setting min automatically to allow manually setting some channels
# min_htlc_msat = 1000
max_htlc_msat_ratio = 1

[inbound_only]
# these are channels that we are either setting up to close (we have opened bigger channels)
# or that we are using for rebalance out only
# ACINQ: 916131780004872194
chan.id = 916131780004872194
base_fee_msat = 0
fee_ppm = 0
strategy = disable

[100%-5%]
chan.min_ratio = 0.05
strategy = static
# only allow up to 95% of channel capacity to be used in a single HTLC
max_htlc_msat_ratio = 0.95

# to prevent draining channel too much, disable when it gets to 5% or lower
# this also will hopefully catch it before the LND pre-0.18 bug of hitting below-reserve limit and force-closing
[5%-0%]
chan.max_ratio = 0.05
strategy = disable

Dies ist die Standard Konfiguration von Zapo-Matic, einem befreundetem Node-Runner aus dem Lightning Netzwerk. Der Link dazu hier!

Weitere Konfigurations Beispiele gibts bei charge-lnd auf der Github Seite selber:

https://github.com/accumulator/charge-lnd/tree/master/examples

Schaut euch mal die Konfigurationen an, ihr könnt damit alle möglichen Szenarien abdecken auf Basis von vorgegeben Werten und Variablen.

https://github.com/accumulator/charge-lnd?tab=readme-ov-file#more-examples

Crontab erstellen

Bei jedem ausführen des Befehls, wird die charge.config nur einmal abgerufen, und charge-lnd führt die darin enthaltenen Konfigurationen aus. Damit HTLC Anpassungen die auf vorhandene Kapazität zum Beispiel regelmässig angepasst werden, muss charge-lnd regelmässig ausgeführt werden. Bei dynamischen HTLC Anpassungen, wie zum Beispiel in dieser Konfiguration, ist eine ausführung alle 5 Min bei einer Node, auf der sich viel bewegt, empfehlenswert. Bei einer kleineren Node, reicht auch eine Ausführung alle 60 Minuten.

Öffnet mit sudo crontab -e den Crontab Editor, und fügt am Ende folgende Zeile hinzu:

5/* * * * * docker run --rm -it --network=umbrel_main_network -e GRPC_LOCATION=LND_IP:10009 -e LND_DIR=/data/.lnd -e CONFIG_LOCATION=/app/charge.config -v /root/umbrel/app-data/lightning/data/lnd:/data/.lnd -v
/mnt/data/upgrades/charge-lnd/charge.config:/app/charge.config accumulator/charge-lnd:latest

Möchtet ihr eine stündliche ausführen, wäre dass zum Beispiel 0 */1 * * * also:

0 */1 * * * docker run --rm -it --network=umbrel_main_network -e GRPC_LOCATION=LND_IP:10009 -e LND_DIR=/data/.lnd -e CONFIG_LOCATION=/app/charge.config -v /root/umbrel/app-data/lightning/data/lnd:/data/.lnd -v
/mnt/data/upgrades/charge-lnd/charge.config:/app/charge.config accumulator/charge-lnd:latest

Mit dem crontab guru könnt ihr mit die Crontab Zeitangaben etwas herumexperimentieren.

Nun wird die Konfiguration entsprechend des Zeitintervals regelmässig ausgeführt.

Abschluss

Das Tool charge-lnd erweist sich als eine wertvolle Ressource für Lightning Node Betreiber im Lightning Network, indem es eine flexible und effiziente Verwaltung von Gebühren ermöglicht. Die Installation des Tools ist durch die detaillierten Anweisungen im Bericht klar und unkompliziert gestaltet, wodurch Nutzer auch ohne tiefgreifende technische Vorkenntnisse in der Lage sind, "charge-lnd" erfolgreich einzurichten. Die Vielfalt der Konfigurationsmöglichkeiten, darunter die Einstellung von Gebühren für Autobalancing, die Nutzung von On-Chain-Gebühren als Referenz und die Anpassung an die Kanalaktivität, bietet Nutzern die Flexibilität, ihre Gebührenstrategien präzise auf ihre spezifischen Bedürfnisse und Ziele abzustimmen. Abschließend lässt sich sagen, dass "charge-lnd" nicht nur eine Lösung zur Optimierung von Gebührenstrukturen bietet, sondern auch dazu beiträgt, die allgemeine Effizienz und Rentabilität von Lightning-Netzwerkaktivitäten zu verbessern. Wer mehr lieber mit einer Weboberfläche Fee Anpassungen tätigt, der ist mit LNDg besser beraten, jedoch muss dort, für dynamische HTLC Anpassung, auch das Algorythmus, welcher in Python geschrieben ist, anpassen.

Interessiert Ihr euch für eine Fullnode? Schaut bei uns im Shop vorbei, wir bieten vorinstallierte Lightning Full Nodes auf Basis vom Raspi 4 und 5 an.

The post Charge-lnd auf Umbrel installieren appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Einleitung

Normerweilse verbindet sich RaspiBlitz auschliesslich mit dem Tor Netzwerk, um die die initiale Blockchain Synchronisation auszuführen. Das soll der Privatsphäre dienlich sein, und verhindern, dass andere erspähen können, dass man sich die Blockchain herunterlädt, und somit auch Schlüsse gezogen werden könnten, dass man eine Node zuhause betreibt. Der Ansatz ist Privacy per Default, und auch absolut zu unterschreiben. Mann kann aber die initiale Synchronisation auch über das Internet beziehungsweise genauer gesagt, oder auch Clearnet genannt, durchführen, wobei die ich Nachteile davon eher weniger schwer gewichte. Die Blockchain wird von fest definierten trusted nodes heruntergeladen, welche in der Regel nicht interessiert sind, euch auszuspionieren. Auch wenn eine daten-sammelnde Node darunter wäre, wäre die Info weniger gefährlich, da sich tausende Nodes ständig ebenso die Blockchain über das Clearnet herunterladen.

Eure Internetgeschwindigkeit sollte unter 75Mbit einen RaspiBlitz 4 beim Sync nicht ausbremsen, sollten die auch tatsächlich voll zur Verfügung stellen. Eine Raspi 5 benötigt für sein volles Potential bereits an die 150-200Mbit an Interneteschwindigeit.

Vorbereitungen

Der Raspiblitz muss installiert sein, das Image geflasht und das Betriebsystem geladen haben. Danach könnt ihr euch via SSH auf dem Raspiblitz einloggen. Falls ihr dass das erste mal tut wäre das:

ssh admin@ip_addr

Das Initialpasswort lautet raspiblitz, wir gehen aber jetzt davon aus, dass ihr euch bereits einmal eingeloggt hattet, und der Blitz bereits schon bereits angefangen hat zu synchronisieren. Falls ihr euch im Menu befindet, beendet dieses mit strg+c damit ihr auf die Komandozeile kommt:

Änderung der Konfiguration

Danach befindet ihr euch auf der Befehlszeile. Stoppt mit dem Befehl sudo systemctl stop bitcoind.service den Synchronisationvorgang. Das kann, falls ihr bereits schon eine Weile dabei seid, etwas länger gehen, da die die gespeicherten Blockchaindaten aus dem Cache auf die Platte geschrieben werden müssen. Checkt mit sudo systemctl status bitcoind.service, ob der Service angehalten hat:

Danach öffnet ihr mit sudo nano /mnt/hdd/bitcoin/bitcoin.conf die bitcoind Konfigurationsdatei. Hier scrollt ihr ganz nachen unten zum Abschnitt # tor by default. Erledigt die Änderungen wie folgt und fügt oberhalb die Zeilen #ipv4sync und onlynet=ipv4 hinzu, falls nicht schon vorhanden. Falls onlynet=ipv4 bereits vorhanden ist, müsst ihr keinen gesonderten Bereich einrichten.

#ipv4sync
onlynet=ipv4

# tor by default
deprecatedrpc=addresses
#onlynet=onion
#proxy=127.0.0.1:9050
main.bind=127.0.0.1
test.bind=127.0.0.1
dnsseed=0
dns=0
debug=tor
debug=i2p
#i2psam=127.0.0.1:7656
#i2pacceptincoming=1
#onlynet=i2p
shrinkdebugfile=1

Kommentiert onlynet=onion, proxy=127.0.0.1, i2psam=127.0.0.1:7656, i2pacceptincoming=1 und onlynet=i2p aus.

Danach könnte es folgendermassen aussehen:

Danach speichert ihr die Datei mit strg+o und beendet mit strg+x

Startet bitcoind nun neu mit sudo systemctl start bitcoind.service
Bitcoin Core wird nun neu starten, und sich für die weitere Synchronisation mit Clearnet Clients verbinden.

Synchronisation checken

mit dem Befehl sudo tail -f /mnt/hdd/bitcoin/debug.log könnt ihr checken, ob sich die Node weiter synchronisiert:

Änderungen Rückgängig machen

Nachdem die Blockchain synchronisiert wurde, könnt ihr die Änderungen natürlich rückgängig machen. Das geht ganz einfach, indem ihr die Hashsymbole vor den Tor und i2p Optionen wieder entfernt:

onlynet=ipv4 kann aktiviert bleiben, da der Raspiblitz damit auch clearnetpeers über den Torproxy erreichen kann.

Startet danach Bitcoin Core wieder neu mit sudo systemctl restart bitcoind.service
Alle nachfolgenden Blöcke wird der RaspiBlitz nun wieder via Tor herunterladen.

Abschluss

Viele wundern sich, warum das teilweise auf dem Pi4 so extrem lange dauert, bis die Blockchain synchronisiert wird, und denken dabei schnell daran, dass der Raspiberry 4 extrem langsam ist. Das liegt aber nicht nur an der Hardware, sondern einfach am Tor Netzwerk. Mehr wie 1.5 - bis 3MB/sec Download sind da einfach nicht drin. Ich finde es sowieso besser, wenn das Tor Netzwerk nicht mit dem Download riesiger Datenmengen überlastet wird, wie z.B das herunterladen der Blockchain, oder das Streamen via Tor, den das sind unter anderem Gründe, wieso Tor auch sehr langsam ist. Da ihr wahrscheinlich sowieso Bitcoin Content im Internet betrachtet, weiss man sowieso schon, dass ihr euch für Bitcoin interessiert.

The post Raspiblitz deutlich schneller via Clearnet synchronisieren appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Berechnung von Bitcoin-Transaktionsgebühren, auch bekannt als "On-chain Fees", hängt von verschiedenen Faktoren ab, darunter die Größe der Transaktion in Bytes und die aktuelle Auslastung des Bitcoin-Netzwerks. Im Allgemeinen zahlen Benutzer eine höhere Gebühr, um ihre Transaktion schneller bestätigen zu lassen. Bitcoin-Transaktionen können im Legacy-Format (auch bekannt als P2PKH) oder im SegWit-Format (beispielsweise P2SH-SegWit und native SegWit oder Bech32), oder Taproot (P2TR) durchgeführt werden. SegWit- und Taproot Transaktionen sind günstiger, da sie effizienter gestaltet sind und weniger Platz im Block beanspruchen. Auf der Seite mempool.space könnt ihr gleich mal die aktuellen Gebühren abrufen, damit ihr wisst, was aktuell gezahlt werden muss.

Legacy-Transaktionen (P2PKH) berechnen

Die Größe einer Legacy-Transaktion lässt sich mit einer allgemeinen Formel schätzen:

Transaktionsgröße = 10 + (Anzahl der Inputs * 146) + (Anzahl der Outputs * 33) Bytes

• 10 Bytes sind für den Transaktionsheader.
• Jeder Input benötigt im Durchschnitt 146 Bytes.
• Jeder Output benötigt im Durchschnitt 33 Bytes.

Anschliessen können wir mit der Transaktionsgrösse die Gebühr berechnen:

Beispiel 2 Inputs (also 2UTXOs aus eurer Wallet) und 1 Output, zum Beispiel die Empfangsadresse eures Partners:

Schritte zur Berechnung der Transaktionsgröße:

• Inputs: Jeder Input in einer Legacy-Transaktion benötigt im Durchschnitt etwa 148 Bytes.
• Outputs: Ein Output benötigt im Durchschnitt etwa 34 Bytes.
• Fixe Zusatzbytes: Zusätzlich zu den Inputs und Outputs gibt es einen Basiswert von etwa 10 Bytes für die Transaktion selbst.

Berechnung Tx Grösse

• Transaktionsgröße in vbyte = (Anzahl der Inputs * 146) + (Anzahl der Outputs * 33) + 10
• Transaktionsgröße in vbyte = (2 * 146) + (1 * 33) + 10 = 335 Bytes

Gebührenberechnung

• Gebühr = Transaktionsgröße (Bytes) * Gebührensatz (Sats pro vByte)
• Gebühr = 335 Bytes * 20 Sats/Byte = 6.700 Sats

SegWit-Transaktionen (P2SH-SegWit und Bech32) berechnen

Für SegWit-Transaktionen (Segregated Witness) wird die Größe in "vbytes" (virtuelle Bytes) gemessen. Dies spiegelt die Implementierung von SegWit wider, die eine effizientere Nutzung des Blockplatzes ermöglicht, indem bestimmte Teile der Transaktionsdaten (die Witness-Daten) separiert und anders gewichtet werden. Die Berechnung der Transaktionsgröße für SegWit nutzt daher eine spezifische Formel, die diese Unterschiede berücksichtigt:

Transaktionsgrösse = (Anzahl der Inputs * 68.5) + (Anzahl der Outputs * 31) + 10

• 68.5 vbytes werden pro Input geschätzt, um die Basisdaten und die reduzierte Gewichtung der Witness-Daten zu berücksichtigen.
• 31 vbytes pro Output reflektieren die Größe der Output-Daten.
• Zusätzlich 10 vbytes werden für Basisdaten der Transaktion selbst addiert.

Diese Methode zur Berechnung der Transaktionsgröße bietet eine genauere Schätzung unter Berücksichtigung der durch SegWit eingeführten Effizienzverbesserungen. Die Nutzung von SegWit führt somit zu geringeren Transaktionsgebühren führen, besonders bei Transaktionen mit mehreren Inputs, da SegWit die Größe der Inputs effizient reduziert.

Jetzt können wir auch hier die Transaktionsgebühr berechnen:

Beispiel wieder 2 Inputs (also 2UTXOs aus eurer Wallet) und 1 Output, zum Beispiel die Empfangsadresse eures Partners und einer Gebühr von 20 Sats/vbyte:

Schritte zur Berechnung der Transaktionsgröße:

Für eine SegWit-Transaktion verwenden wir eine vereinfachte Berechnung, um die Transaktionsgröße (in vbytes) abzuschätzen, da die genaue Größe von der Witness-Data Grösse abhängt. Im Durchschnitt:

• Inputs: Ein SegWit Input ist etwas größer als ein Legacy Input, da er zusätzliche Daten enthält. Jedoch, für die Berechnung der Gebühren, wird er effizienter gewichtet. Nehmen wir an, dass jeder SegWit-Input im Durchschnitt 68 vbytes benötigt (dies berücksichtigt die gewichteten Witness-Daten).
• Outputs: Ein Output benötigt im Durchschnitt etwa 34 Bytes bzw. vbytes (für Outputs gibt es keinen Unterschied zwischen Legacy und SegWit).
• Fixe Zusatzbytes: Die Basis der Transaktion benötigt ungefähr 10 vbytes.

Berechnung Tx Grösse

• Transaktionsgröße in vbyte = (Anzahl der Inputs * 68.5) + (Anzahl der Outputs * 31) + 10
• Transaktionsgröße in vbyte = (2 * 68.5) + (1 * 31) + 10 = 178 vBytes

Gebührenberechnung

• Gebühr = Transaktionsgröße (vbytes) * Gebührensatz (Sats pro vbyte)
• Gebühr = 178 vBytes * 20 Sats/vbyte = 3.560 Sats

Taproot (PTR2) Transaktionen berechnen

Bei einer "normalen" Transaktion, die einfache Transfers ohne komplexe Skripte oder Bedingungen umfasst, ähnelt die Struktur einer Taproot-Transaktion (die Schnorr-Signaturen und den neuen Bech32m-Adresstyp verwendet) tatsächlich sehr der einer SegWit-Transaktion, insbesondere hinsichtlich der Größe, wenn man die grundlegenden Elemente betrachtet.

Ähnlichkeiten in der Größe

• SegWit (beispielsweise P2SH-SegWit und native SegWit oder Bech32) und Taproot (P2TR, mit Bech32m-Adressen) nutzen beide das Konzept der "Block Weight" und "Virtual Size" (vsize), um die Transaktionsgröße effizienter zu messen. Dies führt dazu, dass die effektive Nutzung des Blockplatzes optimiert wird.
• Sowohl bei SegWit- als auch bei Taproot-Transaktionen werden Signaturdaten vom Rest der Transaktion getrennt behandelt (Segregated Witness), was die Flexibilität erhöht und Skalierungsverbesserungen ermöglicht.

Schlussendlich wird also mit der Segwit Formel wieder die Transaktionsgrösse berechnet, und dann damit die Transaktionsgebühr.

Online Rechner

Sobald erfolgreich erste Transaktionsgebühren berechnet worden sind, darf der Online-Rechner benutzt werden! Ich habe euch hier einen einfach und simple zu bedienenden Rechner herausgesucht. Hier könnt ihr auswählen, ob Legacy oder Segwit genutzt werden soll, zudem lassen sich Anzahl Inputs und Outputs angeben:

Den Online-Rechner findet ihr hier auf dieser Seite.

Auch hier stimmt die Gebührenschätzung nicht wirklich mit dem aktuellen Gebühren überein. Nutzt also schnell https://mempool.space um die Gebühren zu sichten, und um zu wissen, in welcher Anzahl Blocks eine Bestätigung wahrscheinlich ist. Nutzt den oben markierten Regler, und schiebt in an die gewünschte Position, damit ihr im unteren markierten Bereich auf die gewünschte Transaktionsgebühr kommt.

Abschluss

Im Verlauf dieses Berichts haben wir uns eingehend mit der Berechnung von Bitcoin-Transaktionsgebühren beschäftigt, mit einem besonderen Fokus auf die Unterschiede zwischen Legacy- SegWit- und Taproot Transaktionen. Wir haben gesehen, dass die Gebührenberechnung von mehreren Faktoren abhängt, einschließlich der Transaktionsgröße in Bytes oder vbytes und der aktuellen Auslastung des Netzwerks. Insbesondere die Einführung von SegWit hat die Landschaft für Bitcoin-Transaktionen erheblich verändert, indem sie effizientere und kostengünstigere Transaktionen ermöglicht, ohne die Sicherheit oder die dezentralisierte Natur des Netzwerks zu beeinträchtigen.

Legacy-Transaktionen, die ältere Form der Bitcoin-Transaktionen, nutzen mehr Platz im Block, was zu höheren Gebühren führen kann, besonders in Zeiten hoher Netzwerkauslastung. SegWit-Transaktionen hingegen nutzen den Blockplatz effizienter durch die Trennung bestimmter Transaktionsdaten, was zu geringeren Gebühren und schnelleren Bestätigungszeiten führt.

The post Bitcoin Onchain Gebühren einfach berechnen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Wer gerade erst eine Node aufsetzt, legt sich diese Anleitung für später zur Seite. Eine Datenbank, die nie aufräumt, benimmt sich wie ein Keller: Lange fällt nichts auf, und dann passt eines Tages das Fahrrad nicht mehr hinein. Die Anleitung erschien erstmals im März 2024 und ist im September 2026 gegen die aktuelle LND-Beispielkonfiguration, den Quelltext von LND sowie die Repositories von RaspiBlitz und BTCPay Server geprüft worden.

Warum die channel.db wächst und wann ihr sie verkleinern solltet

Die channel.db ist die zentrale Datenbank einer LND-Node im Lightning-Netzwerk, der Zahlungsschicht auf Bitcoin. Darin liegen Kanalzustände, Rechnungen, Zahlungen und der Netzwerkgraph. Sie liegt im Unterordner data/graph/mainnet/ des LND-Verzeichnisses und wächst mit der Zeit immer weiter an.

Der Grund liegt im Speicherformat. LND verwendet standardmässig die Datenbank bbolt; laut der Beispielkonfiguration sample-lnd.conf ist bolt weiterhin das voreingestellte Backend, Postgres und SQLite sind Alternativen. Die Projektbeschreibung von bbolt hält fest, dass die Datenbank ihre Datei nicht kürzen und freie Seiten nicht an das Dateisystem zurückgeben kann; sie führt sie intern in einer Freiliste und verwendet sie später wieder. Die Datei wird also nicht kleiner, auch wenn darin weniger steht. Erst eine Kompaktierung schreibt den Inhalt dicht gepackt in eine neue Datei. Eine kleinere Datei heisst weniger Arbeit beim Start und weniger Speicherbedarf; wer in letzter Zeit merkt, dass seine Node träge reagiert, findet hier oft eine Ursache.

Eine Einschränkung vorweg: Seit einigen Versionen kann LND Rechnungen und den Graphen auch in nativen SQL-Tabellen führen (db.use-native-sql, Vorgabe false). Wer seine Node auf Postgres oder SQLite betreibt, hat keine bbolt-Kanaldatenbank und kann diese Anleitung überspringen. Für die üblichen Node-Pakete wie Umbrel, RaspiBlitz und BTCPay Server gilt sie.

Warum ich diesen Artikel geschrieben habe: Auf GitHub gibt es etliche Beiträge über grosse Datenbankdateien und immer langsamere Nodes, aber kaum eine zusammenhängende Anleitung, wie ihr die Kompaktierung selbst einrichtet.

channel.db Grösse überprüfen

Die Grösse der channel.db prüft ihr mit ls -lh. Als Faustregel aus meinem eigenen Betrieb: Ab rund 3 GB lohnt sich die erste Kompaktierung. Das ist ein Erfahrungswert, keine Vorgabe von LND. Je nach System liegt die Datei hier:

Umbrel (Pfad aus der Zeit vor umbrelOS 1.x, siehe Hinweis unten)

ls -lh /root/umbrel/app-data/lightning/data/lnd/data/graph/mainnet/

RaspiBlitz

sudo ls -lh /mnt/hdd/app-data/lnd/data/graph/mainnet/

BTCPay Server

ls -lh /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/graph/mainnet/

Beim RaspiBlitz stand hier früher /mnt/hdd/lnd/. Die aktuellen Installations- und Prüfskripte des Projekts (lnd.install.sh, lnd.check.sh) arbeiten durchgehend mit /mnt/hdd/app-data/lnd/. Beim Umbrel-Pfad gilt: Er stammt aus der Zeit vor umbrelOS 1.x. Ob er auf einem heutigen umbrelOS noch genau so lautet, liess sich für diese Überarbeitung nicht prüfen.

Exemplarisch, bei mir war die channel.db nach der Kompaktierung 2,6 GB gross, vorher rund 4,7 GB:

Wie LND die Datenbank kompaktiert

Bevor es an die einzelnen Systeme geht, lohnt ein Blick darauf, was die Kompaktierung tatsächlich tut. Das erklärt nämlich zwei Aussagen, die in älteren Anleitungen — auch in der ersten Fassung dieser hier — falsch standen.

Gesteuert wird sie über zwei Optionen im Abschnitt [bolt] der lnd.conf. db.bolt.auto-compact schaltet sie ein; laut sample-lnd.conf ist sie ab Werk aus, weil sie während des Vorgangs zusätzlichen Speicherplatz braucht. db.bolt.auto-compact-min-age legt fest, wie lange die letzte Kompaktierung zurückliegen muss, bevor LND beim nächsten Start erneut kompaktiert. Die Vorgabe ist 168h, also eine Woche. Wer 0 einträgt, kompaktiert bei jedem Start.

Daraus folgt: Wer nur db.bolt.auto-compact=true setzt, kompaktiert nicht bei jedem Neustart, sondern höchstens einmal pro Woche. Die Zeile db.bolt.auto-compact-min-age=168h schadet nicht, wiederholt aber nur den Standardwert. Und wer die Kompaktierung ausschaltet, bekommt keine Kompaktierung — nicht etwa eine bei jedem Start.

Den Ablauf beschreibt der Quelltext in kvdb/backend.go: LND schreibt den verdichteten Inhalt in eine temporäre Datei namens temp-dont-use.db und tauscht sie erst danach per Umbenennen gegen die alte aus. Vorher prüft kvdb/bolt_compact.go, ob auf dem Datenträger genug Platz für eine vollständige Kopie plus zehn Prozent Reserve frei ist; sonst beginnt die Kompaktierung gar nicht erst. Den Zeitpunkt der letzten Kompaktierung merkt sich LND in einer Datei neben der Datenbank, channel.db.last-compacted. Fehlt diese Datei, kompaktiert LND beim nächsten Start.

channel.db kompaktieren auf Umbrel, BTCPay Server und RaspiBlitz

Wir schauen uns die Kompaktierung auf drei Systemen an: BTCPay Server, Umbrel und dem RaspiBlitz. Welche Zusatzoptionen dabei sinnvoll sind, steht gesammelt im Abschnitt danach.

Umbrel Fullnode

Auf Umbrel geschieht das über die Oberfläche der Lightning-Node-App. Öffnet die App und geht oben rechts über die drei Punkte in die Einstellungen. Die folgenden Bildschirmfotos stammen vom März 2024 und zeigen die Oberfläche vor umbrelOS 1.x; wie die Einstellungen heute genau heissen und wo sie sitzen, liess sich für diese Überarbeitung nicht prüfen.

Navigiert hinunter zu den Optimierungen und aktiviert diese Einstellungen:

db.bolt.auto-compact=true
db.bolt.auto-compact-min-age=168h
gc-canceled-invoices-on-startup=true
gc-canceled-invoices-on-the-fly=true
ignore-historical-gossip-filters=true
stagger-initial-reconnect=true

Achtet auf die kleine, rot markierte Beschriftung, dann findet ihr die richtigen Schalter:

Die erste Fassung dieser Anleitung empfahl hier zusätzlich sync-freelist und payments-expiration-grace-period=9999h. Beides steht nicht mehr in der Liste; warum, erklärt der Abschnitt über die übrigen Optionen.

BTCPay Server

Auf dem BTCPay Server gibt es für die Kompaktierung ein fertiges Fragment namens opt-lnd-autocompact. Es tut genau eines: Es hängt die Zeile db.bolt.auto-compact=true an die LND-Konfiguration. Loggt euch per SSH ein, werdet root und wechselt in das Verzeichnis, in das btcpayserver-docker bei der Installation geklont wurde — nach der Installationsanleitung im Repository ist das BTCPayServer/btcpayserver-docker im Home-Verzeichnis von root:

sudo su -
cd BTCPayServer/btcpayserver-docker
export BTCPAYGEN_ADDITIONAL_FRAGMENTS="$BTCPAYGEN_ADDITIONAL_FRAGMENTS;opt-lnd-autocompact"
. ./btcpay-setup.sh -i

Vergesst den Punkt vor ./btcpay-setup.sh nicht. Danach erzeugt das Skript die Docker-Konfiguration neu und startet die Container mit den neuen Einstellungen. Die aktuelle Dokumentation im Repository nennt dafür inzwischen auch den kürzeren Befehl btcpay-fragments add opt-lnd-autocompact; im Fragmentkatalog steht das Fragment als „Enable LND database auto-compaction“.

In der ersten Fassung stand hier, der Server kompaktiere mit diesem Fragment bei jedem Neustart, und db.bolt.auto-compact-min-age lasse sich nur über einen Umweg setzen. Das stimmt nicht: Weil LND ohne weitere Angabe den Standardwert von 168 Stunden nimmt, kompaktiert der Server höchstens einmal pro Woche.

Wer weitere Optionen setzen will, legt ein eigenes Fragment an. Wichtig, und in der ersten Fassung falsch: Ein Fragment ist eine YAML-Datei im Format von Docker Compose, keine lnd.conf. Die LND-Zeilen gehören in die Variable LND_EXTRA_ARGS des Dienstes lnd_bitcoin, genau so wie im mitgelieferten Fragment. Laut der Anleitung zur Anpassung enden eigene Fragmente auf .custom.yml, damit Git sie bei Updates in Ruhe lässt:

nano docker-compose-generator/docker-fragments/opt-lnd-additionals.custom.yml

services:
  lnd_bitcoin:
    environment:
      LND_EXTRA_ARGS: |
        gc-canceled-invoices-on-startup=true
        gc-canceled-invoices-on-the-fly=true
        ignore-historical-gossip-filters=true
        stagger-initial-reconnect=true

Speichert mit Strg+O und beendet mit Strg+X. Der Generator hängt mehrzeilige Werte aus mehreren Fragmenten aneinander, statt sie zu überschreiben; die Zeilen landen also zusätzlich zu den bestehenden. Aktiviert das Fragment wie oben:

export BTCPAYGEN_ADDITIONAL_FRAGMENTS="$BTCPAYGEN_ADDITIONAL_FRAGMENTS;opt-lnd-additionals.custom"
. ./btcpay-setup.sh -i

Die Liste aller mitgelieferten Fragmente steht im Fragmentkatalog der BTCPay-Dokumentation.

RaspiBlitz Fullnode

Auf dem RaspiBlitz ist die Kompaktierung bereits eingeschaltet. Das Installationsskript schreibt in den Abschnitt [bolt] der lnd.conf die Zeilen db.bolt.auto-compact=true und db.bolt.auto-compact-min-age=672h; kompaktiert wird also höchstens alle vier Wochen, jeweils beim Start von LND. Die übrigen empfehlenswerten Optionen — gc-canceled-invoices-on-startup, gc-canceled-invoices-on-the-fly, ignore-historical-gossip-filters und stagger-initial-reconnect — setzt es bei Neuinstallationen ebenfalls schon.

Die erste Fassung empfahl an dieser Stelle, die Zahl in der lnd.conf herunterzusetzen. Das hält nicht: Vor jedem Start von LND läuft lnd.check.sh prestart und setzt beide Werte im Abschnitt [bolt] wieder auf true und 672h zurück. Eine Handänderung ist nach dem nächsten Neustart weg.

Wollt ihr die Kompaktierung sofort auslösen, statt bis zu vier Wochen zu warten, geht das über die Zeitstempeldatei aus dem Abschnitt oben. Fehlt sie, kompaktiert LND beim nächsten Start. Stoppt zuerst LND:

sudo systemctl stop lnd.service

Prüft, ob die Datei vorhanden ist, und entfernt sie:

sudo ls -l /mnt/hdd/app-data/lnd/data/graph/mainnet/
sudo rm /mnt/hdd/app-data/lnd/data/graph/mainnet/channel.db.last-compacted

Startet LND wieder:

sudo systemctl start lnd.service

Den Verlauf verfolgt ihr im LND-Log, das der RaspiBlitz hier ablegt:

sudo tail -f /mnt/hdd/app-data/lnd/logs/bitcoin/mainnet/lnd.log

LND meldet den Beginn mit „Compacting database file at …“ und den Abschluss mit „DB compaction of … successful“ samt Grösse vorher und nachher. Wenn LND gar nicht erst hochkommt, hilft sudo journalctl -u lnd weiter; mehr dazu steht in der Anleitung zur Problembehebung im systemd.

Das folgende Bildschirmfoto vom März 2024 zeigt, wo die Optionen in der lnd.conf stehen. Die db.bolt-Zeilen gehören unter [bolt], die übrigen unter [Application Options]; so ist auch die sample-lnd.conf aufgebaut. Die Datei liegt heute unter /mnt/hdd/app-data/lnd/lnd.conf.

Wer seinen RaspiBlitz ohnehin aktualisieren will, findet die Schritte in der Anleitung RaspiBlitz auf die neueste Version aktualisieren. Welches der beiden Node-Pakete zu euch passt, klärt RaspiBlitz VS Umbrel.

Was die übrigen Optionen tun — und welche ihr weglasst

In vielen Anleitungen, auch in der ersten Fassung dieser hier, wird ein ganzer Block an Optionen mitkopiert. Was jede davon laut sample-lnd.conf tut:

• gc-canceled-invoices-on-startup=true räumt beim Start abgebrochene Rechnungen aus der Datenbank. Sinnvoll für alle, die viele Rechnungen erzeugen.
• gc-canceled-invoices-on-the-fly=true löscht neu abgebrochene Rechnungen sofort, statt sie aufzubewahren.
• ignore-historical-gossip-filters=true beantwortet Anfragen anderer Nodes nach historischen Gossip-Daten nicht. Laut Beschreibung senkt das Speicher- und Bandbreitenbedarf.
• stagger-initial-reconnect=true verteilt die Wiederverbindung zu festen Peers beim Start zufällig über 0 bis 30 Sekunden; die ersten zehn Verbindungen laufen trotzdem sofort.

Zwei Optionen aus der ersten Fassung sind gestrichen:

sync-freelist stand dort als start sync-freelist=1. Das Wort „start“ davor gehört nicht zum Optionsnamen; so eingetragen ist die Zeile schlicht ungültig. Wichtiger ist die Sache selbst: Laut sample-lnd.conf verkürzt die Option die Startzeit, kann aber bei sehr grossen Datenbanken die Leistung verschlechtern und den Speicherbedarf erhöhen — also genau bei den Nodes, für die diese Anleitung gedacht ist. Das RaspiBlitz-Projekt hat sie nach Issue 3251 („don't use sync-freelist=true in lnd.conf“) aus der Vorgabe genommen; ein Nutzer berichtet dort von einer channel.db, die mit der Option um 600 MB bis 1 GB pro Tag wuchs und ohne sie um 100 MB in sieben Tagen. Das Installationsskript kommentiert die Option inzwischen mit dem Rat, sie bei Nodes mit vielen Kanälen auf false zu setzen.

payments-expiration-grace-period=9999h hat mit der Datenbankgrösse nichts zu tun. Laut Beschreibung ist das die Wartezeit, bevor LND einen Kanal schliesst, in dem eine selbst ausgelöste Zahlung abgelaufen ist; die Vorgabe ist 0s, das Beispiel in der Dokumentation 30s. 9999 Stunden sind gut 416 Tage und schalten diese Schutzreaktion für eigene Zahlungen damit praktisch ab. Wer das will, soll es bewusst entscheiden — in einer Anleitung zum Aufräumen der Datenbank hat es nichts verloren.

Achtung: Kompaktierung braucht Zeit und freien Speicher

Auf einem kleinen System kann die Kompaktierung lange dauern. Auf einem RaspiBlitz mit mehreren Dutzend Kanälen und einer channel.db von mehreren Gigabyte habe ich ein bis drei Stunden erlebt. Solange sie läuft, ist LND noch nicht gestartet und die Node nicht erreichbar. Wartet ab. Startet die Node in dieser Zeit nicht neu und zieht nicht den Stecker.

In der ersten Fassung stand hier, bei einem Abbruch seien alle Kanäle mit hoher Wahrscheinlichkeit beschädigt. Das gibt der Quelltext nicht her: Weil LND in eine temporäre Datei schreibt und die alte erst nach erfolgreichem Abschluss ersetzt, bleibt die ursprüngliche channel.db bei einem Abbruch unangetastet, und beim nächsten Kompaktierungslauf löscht LND die halbfertige Kopie, bevor es neu beginnt. Ein harter Stromausfall bleibt trotzdem ein Risiko für jede Datenbank und jede SSD — dafür braucht es keine Kompaktierung.

Der RaspiBlitz gibt LND beim Start übrigens TimeoutStartSec=1200, also zwanzig Minuten, und begründet das in der Unit-Datei ausdrücklich mit der Datenbankkompaktierung. Wer eine sehr grosse Datenbank hat und beobachtet, dass LND während der Kompaktierung neu gestartet wird, findet hier den ersten Anhaltspunkt.

Bevor ihr LND neu startet

• Freien Platz prüfen. Auf dem Datenträger muss mindestens die Grösse der channel.db plus zehn Prozent frei sein, sonst bricht LND die Kompaktierung vor dem Start ab. Bei einer vollen SSD hilft zuerst mehr Platz, etwa mit der Anleitung Fullnode 1TB SSD auf 2TB SSD klonen.
• Kanalsicherung aktuell halten. Die Kompaktierung ist kein Backup und ersetzt keines. Wie ihr eine Node richtig sichert und warum eine alte channel.db nie zurückgespielt werden darf, steht im Backup- und Restore-Leitfaden für Lightning Fullnodes; eine automatische Sicherung der Kanal-Notfalldatei beschreibt RaspiBlitz SCB Backup auf einer Nextcloud.
• Zeit einplanen. Löst die Kompaktierung nicht mitten in einer Phase aus, in der ihr die Node dringend braucht, etwa vor einer erwarteten Zahlung.
• Keine Optionen doppelt setzen. Auf dem RaspiBlitz sind die meisten Optionen schon gesetzt; wer sie ein zweites Mal in die lnd.conf schreibt, erzeugt nur Verwirrung beim nächsten Nachsehen.
• Das Log mitlesen. Nur die Meldung „DB compaction of … successful“ sagt euch, dass es geklappt hat und wie viel es gebracht hat.

Fazit: Die Kompaktierung ist ein Schalter, kein Eingriff

Die channel.db zu verkleinern ist kein riskantes Handwerk an der offenen Datenbank. Es ist eine Funktion, die LND selbst mitbringt, die ab Werk ausgeschaltet ist und die mit einer Zeile dauerhaft läuft. Auf dem RaspiBlitz ist sie schon an, auf dem BTCPay Server reicht ein Fragment, auf Umbrel ein Schalter. Mit den ls -lh-Befehlen oben prüft ihr anschliessend, was es gebracht hat.

Die Kanaldatenbank wächst trotzdem weiter. Nach einem Jahr Routing mit vielen Kanälen habe ich Datenbanken von 15 bis 20 GB gesehen. Wichtig ist, regelmässig zu kompaktieren und dafür genug Ressourcen zu haben. Für grössere Routing-Nodes ist ein RaspiBlitz auf einem Raspberry Pi deshalb nicht die richtige Hardware; mehr zur Frage, was eine Bitcoin Full Node leisten muss, steht im Grundlagenartikel. Und wer von der Kompaktierung die Lösung aller Probleme erwartet, sollte wissen: Sie räumt den Keller auf, sie baut keinen grösseren.

Quellen und weiterführende Links

• LND: sample-lnd.conf (Beschreibung und Vorgabewerte aller genannten Optionen)
• LND: kvdb/backend.go (Ablauf der Kompaktierung, temporäre Datei, .last-compacted)
• LND: kvdb/bolt_compact.go (Prüfung des freien Speichers)
• LND: Releases
• bbolt: Projektbeschreibung, Abschnitt zu Einschränkungen (Datei schrumpft nicht)
• RaspiBlitz: lnd.install.sh und lnd.check.sh
• RaspiBlitz: Issue 3251, „don't use sync-freelist=true in lnd.conf“
• BTCPay Server: Fragment opt-lnd-autocompact, Anleitung zu eigenen Fragmenten und Fragmentkatalog
• BTCPay Server: btcpayserver-docker, Installationsanleitung

The post channel.db auf LND Lightning Nodes verkleinern appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist der Bitcoin Mempool?

Der mempool (kurz für Memory Pool) ist eine Art Wartezimmer oder Sammelstelle für alle unbestätigten Bitcoin-Transaktionen. Jedes Mal, wenn jemand eine Bitcoin-Transaktion sendet, landet diese zunächst im mempool, bevor sie in einen Block aufgenommen und von den Minern bestätigt wird. Wichtig zu verstehen: der mempool ist keine zentrale Sammelstelle aller Transaktionen, sondern ein Abbild aller aktuelle Transaktionen die im mempool des jeweiligen Knotenpunktes vorliegen. Jeder Miner, und jeden Full Node Betreiber hat seinen eigenen mempool, dieser kann vom mempool von der Seite https://mempool.space, ein öffentlich einsehbarer mempool, abweichen.

Funktion des Mempools

Kommen wir zu den wichtigsten Funktionen des mempools un seinem Nutzen:

1. Sammelstelle für Transaktionen: Der Mempool sammelt alle Transaktionen, die noch nicht in einen Block aufgenommen wurden. Diese Transaktionen warten darauf, von Minern ausgewählt und in den nächsten Block der Blockchain eingefügt zu werden.
2. Priorisierung nach Gebühren: Miner wählen Transaktionen aus dem Mempool basierend auf den angehängten Gebühren. Höhere Gebühren können eine schnellere Bestätigung bedeuten, da Miner natürlich daran interessiert sind, die rentabelsten Transaktionen zuerst zu bearbeiten.
3. Verwaltung des Netzwerkverkehrs: In Zeiten hoher Netzwerkaktivität kann der Mempool überfüllt sein, was zu Verzögerungen führt. Dieser Stau zeigt, wie das Netzwerk mit großem Transaktionsaufkommen umgeht.

Nutzen des Mempools

• Transparenz: Jeder kann den Mempool einsehen, um den Status einer Transaktion zu überprüfen. Das bietet Transparenz und ermöglicht es Nutzern, angemessene Transaktionsgebühren festzulegen.
• Netzwerkauslastung: Der Zustand des Mempools gibt Aufschluss über die Auslastung und Effizienz des Bitcoin-Netzwerks. Ein überfüllter Mempool kann auf einen ein sehr hohes Transaktionsvolumen hinweisen.

Verbindung mit Bitcoin-Wallets und Lightning Network

Bitcoin-Wallets:

• Gebührenschätzung: Moderne Wallets analysieren den Mempool, um eine Schätzung der erforderlichen Transaktionsgebühren vorzunehmen.
• Transaktionsstatus: Wallets nutzen den Mempool, um Nutzern Informationen über den Status ihrer Transaktion zu liefern (z.B. ob sie noch unbestätigt ist). Viele Apps lassen euch den mempool selber festlegen. Es kann z.B auch der eigene verwendet werden, der auf der eigenen Fullnode läuft.

Lightning Network (LN) und LND (Lightning Network Daemon):

• off-Chain-Transaktionen: Das Lightning Netzwerk ermöglicht Off-Chain-Transaktionen, die nicht direkt im Mempool erscheinen. LN-Transaktionen werden erst dann an den Mempool gesendet, wenn Kanäle geöffnet oder geschlossen werden.
• mempool Entlastung: Durch das Ausführen von Transaktionen außerhalb der Blockchain hilft LN, den Mempool zu entlasten und onchain Transaktionen im Bitcoin-Netzwerk zu reduzieren.

Verwendung des Mempools auf mempool.space

Auf der offziellen Webseite mempool.space gibts es einen öffentlich einsehbaren mempool. Dieser muss wie gesagt, nicht zu 100% mit dem mempool andere Netzwerknoten, oder mit eurem eigenem übereinstimmen. Es kann sein, dass ein Miner andere Blöcke validiert und bestimmte Transaktionen priorisiert, weil es dafür einen bestimmten Grund gibt. Ein Miner kann selber entscheiden, welche Transaktionen er validieren möchte, und welche nicht. ViaBTC führt z.B einen LowFee Accelerator. Sie bestätigen bestimmte Transaktion, die eine sehr niedrige Fee haben, obwohl die Gebühren eigentlich deutlich höher sind. Das soll helfen, stecken gebliebene Transaktionen zu bestätigen, wenn die Gebühren über längere Zeit stark ansteigen. Wir schauen uns nun im nachfolgenden den mempool etwas genauer an.

Die Übersicht

Schauen wir uns den Mempool in der Übersicht an, seid beruhigt, es gibt viele Zahlen, Informationen, viele Felder und Graphen, im Grunde funktioniert der mempool aber relativ einfach.

Ganz oben seht ihr die aktuelle Blockchain visualiert dargestellt. Links seht ihr die unbestätigten Transaktionen, rechts die bestätigten Transaktionen. Sobald ein Block validiert wurden ist, wandert er nach rechts, und ist nicht mehr veränderbar oder im Nachhinein anzupassen, ausser, es kommt zu einem Fall, in der 2 Miner genau zur gleichen Zeit einen gültigen Blocken finden, dann wird der Block der kürzeren Kette verworfen, ein sogenannter Chain Reorg kommt vor.

Genau genommen, gehört der bestätigte Teil nicht zum mempool sondern ist ein sogenannter Blockexplorer.

Auf der linken Seite kommen ständig neue Transaktionen hinzu, die Blöcke verändern sich, die Gebühren können steigen oder gar Transaktionen verschoben werden: dies ist der eigentliche mempool, beziehungsweise der Wartebereich, in dem sich die unbestätigten Transaktionen befinden. Die Transaktionen in den Blöcken werden in der Regel der Gebühr nach geordnet.

Die Gebühren

Hier seht ihr die aktuellen Gebühren des Netzwerkes. Die Einteilung geschieht in Prioritäten. Zahlungen mit Gebühren höher als das Minimum der höchsten Priotität haben die höchsten Chancen im ersten Block zu landen. Hier könnt ihr also die Gebühren abschätzen, zum Beispiel welche Gebühr ihr am besten für eure Transaktionen nehmen sollt. Bitte merkt euch, dass es hier zu Schwankungen nach oben kommen kann. Es ist also Möglich, das bei vielen einkommenden Transaktionen, die Minimalgebühr von 13 Sats pro Virtualbyte hier in diesem exemplarischen Beispiel nicht mehr ausreichen könnten, um in den ersten Block zu kommen. Bezahlt also lieber etwas mehr, um wirklich im ersten Block zu landen. Eine Zahlung mit zu niedrigen Gebühren, kann unter Umständen also lange im Mempool verhaaren, bis sie bestätigt wird.

Die Blockzusammensetzung

Unter den Gebühren seht ihr, wie der aktuelle Block aussieht. Dieser ändert sich quasi im Sekundentakt.

Es kommen neue Transaktionen hinzu, werden ersetzt, oder fallen aus dem Block heraus, da die Gebühren möglicherweise nicht mehr ausreichen.

Im markierten Bereich können wir die Transaktionen etwas genauner analysieren. Es kann zwischen der Normalansicht, also All, Consolidation, Coinjoins und Data gefiltert werden. Consolidation sind Transaktionen, die kleinere UTXOs in einen einzigen zusammen fassen, um zum Beispiel Gebühren zu sparen. Coinjoins sind Transaktionen, die er Erhöhung der Anonymität im Netzwerk dienlich sind. Wie ihr seht, sobald ihr darauf klickt, ist die Anzahl der Coinsjoins sehr gering. Data Transaktionen sind möglicherweise Ordinals, beziehungszweise Transaktionen, auf denen Affenbildchen und so ein Kram gespeichert sind.

Klickt ihr auf einen unbestätigen Block, seht ihr dessen Aufbau im Detail:

Mit der kleinen Brille bekommt Ihr noch weitere Einsichten zum aktuellen Block, und es lässt sich weiter nuancieren, welche Transaktionen enthalten sind. Links seht ihr die Gebührenverteilung im ausgewählten Block.

Klickt ihr einen bestätigten Block, seht etwas anderes:

Links seht ihr den Exptect Block, also den erwarteten Block, rechts den Actual Block, als so wie er vom Miner schlussendlich gemint wurden ist. Hier kann und darf es zu Unterschieden kommen. Jeder Miner darf einen Block so bauen, wie er es möchte. Manche Miner nehmen z.B. Blöcke auf mit niedriger Fee (siehe oben: Low Fee Accelerator) oder lehnen bestimmte Data Transaktionen (Ordinals, NFTs etc) ab. Der Ursprung ist hier das jeder Miner frei über seinen Mempool bestimmen darf und seine eigene Version des Mempool hat.

Ihr seht links auch die Healthangabe. Diese stellt da, inwiefern der Block vom Miner sich vom Expected Block unterscheidet. Ist die Zahl 100% hat der Miner keine eigens priorisierten Transaktionen mit in den Block aufgenommen, Ist die Zahl nicht 100%, hat der Miner eigens ausgewählte Transaktionen, die auch zum Beispiel von den Gebühren her stark vom aktuellen Blockdurschnitt abweichen, mit in den Block aufgenommen.

Die Difficulty beziehungsweise die aktuelle Schwierigkeitsanpassung

Rechts unter den Bestätigten Block seht ihr die voraussichtliche Schwierigkeitsanpassung. Hier findet ihr Angaben darüber, wie schnell ein Block im Durschnitt aktuell gemint wird, und in wiefern die Difficulty nach der Periode von 2 Wochen, oder genau 2016 Blöcken angepasst wird. Läuft die Blockchain schneller als 10 Minuten Blockzeit, wird die Schwierigkeit entsprechend erhöht, läuft die Blockchain langsamer als 10 Minuten Blockzeit, wird sie entsprechend gesenkt, damit anschliessend die 10 Minuten Blockzeit erreicht wird. Dies geschieht vollautomatisch, und benötigt keiner Steuerung seitens irgendeiner Entität.

Unter der Schwierigkeitsanpassung seht ihr die aktuelle Anzahl eingehender Transaktionen. Die gestrichelte Linie stellt die Transaktionsgeschwindigkeit dar. Die ist in der Regel fest. Das Bitcoincoin Netzwerk kann in der Regel ca 6000-7000 Transaktionen pro 10 Minuten Blockzeit abarbeiten. Die schwankende farbige Linie, sind die eingehenenden Transaktionen. Ist diese deutlich über der gestrichelten weissen Linie, kommen mehr Blöcke hinzu, als das Netzwerk verarbeiten kann. Das bedeutet auch, dasd die Gebühren tendienziell steigen könnten. Ist die Linie lange unter der gestrichelten, bedeutet dies, dass eher weniger Transaktionen hinzukommen, und dass die Gebühren eher fallen werden.

Transaktionen verfolgen

Habt ihr eine Transaktion, z.B aus einer Überweissung, könnt ihr die TxID oben rechts im Suchfeld eingeben. Danach zeigt euch der Blockexplorer die Transaktion an, und wo diese sich in der Warteschlange befindet aber natürlich auch wenn diese Transaktion bereits bestätigt worden ist:

Im oberen Feld seht ihr eine Übersicht, also zum Beispiel die aktivierten Features wie RBF, Segwit oder Taproot. Ausserdem, der Gebührensatz, die Gebühr selber und wer den Block gemint hat. Unten findet ihr das Flussdiagram. Rechts der Input, welcher aus einem UTXO eurer Wallet besteht, und links die Zieladressen. Wenn rechts mehrere Flüsse dargstellt sind, besteht die Transaktion aus mehreren UTXOs! Das heisst also, um die Bezahlung zu ermöglichen, wurden mehreren UTXOs verwendet, weil es keinen gab, der Überweissung vollständig decken konnte. Links findet ihr also die Outputs der Transaktion. Sie besteht in der Regel aus der Gebühr für den Miner (erster Outflow, der eigentlichen Zahlung für die Transaktion (zweiter Fluss) und dem Wechselgeld aus der Transaktion (dritter Outflow). Das Wechselgeld geht in der Regel auf die eigene Wallet zurück.

Die Transaktion mit der TxID faf4902204dd792428c4d65a1d5e9e4771f247659a2d3ec3511a8f014e319002 hat also 2 Outputs:

faf4902204dd792428c4d65a1d5e9e4771f247659a2d3ec3511a8f014e319002:0

und

faf4902204dd792428c4d65a1d5e9e4771f247659a2d3ec3511a8f014e319002:1

Die Zahl hinter der TxID ist der Output Index oder auch TxOut genannt. Der Outputindex hilft dabei, jeden einzelnen Output innerhalb einer Transaktion eindeutig zu identifizieren.

Das Feld unter den Flow gibt Angaben von wo, und wohin die Outputs gesendet werden:

Die Zahlung kommt von der Adress bc1430jx... mit einem UTXO der 0.09471465 BTC gross ist, und geht an die Adress bc1qhc... Die zweite Adresse darunter ist der Change, also das Wechselgeld der Zahlung, weil die Zahlung nur 4 Millionen Sats betrug.

Ein weiteres Beispiel, die Konsolidierung

Hier sehen wir kurz das Flussdiagram einer Konsolidierung:

Die Inputs sind viele kleine UTXOs, die zusammen in einen einzigen gebündelt werden. Rechts oben die Gebühr, links unten, der neue zusammengefasste UTXO. Das spart Gebühren, den die Gebühr erhöht sich mit der Anzahl an Inputs, und Outputs.

Verwendung des eigenen mempools

CLI Variante

Um euren eigenen Mempool im Bitcoin-Netzwerk zu nutzen, müsst ihr mit bitcoind, dem Bitcoin-Daemon, arbeiten. bitcoind ist das Programm, das im Hintergrund auf eurer Fullnode läuft und das Bitcoin-Protokoll implementiert. Es hält eine vollständige Kopie der Blockchain vor und verwaltet den Mempool, eine Sammlung von Transaktionen, die von anderen Knoten im Netzwerk empfangen wurden, aber noch nicht in einem Block enthalten sind.

Wenn ihr bitcoind verwendet, gibt es verschiedene Befehle und Konfigurationsoptionen, die euch helfen, euren eigenen Mempool zu verwalten und zu inspizieren. Hier einige der wichtigsten Befehle, die über die Bitcoin Core RPC-Schnittstelle verfügbar sind:

1. getmempoolinfo: Dieser Befehl gibt euch Basisinformationen über euren Mempool. Er zeigt unter anderem die aktuelle Größe des Mempools, die Anzahl der Transaktionen darin und den Speicherplatz, den sie verbrauchen.

bitcoin-cli getmempoolinfo

getrawmempool: Dieser Befehl liefert eine Liste aller Transaktions-IDs, die derzeit in deinem Mempool sind. Ihr könnt zusätzliche Details zu jeder Transaktion erhalten, indem ihr den Befehl mit dem true-Parameter für detaillierte Informationen ausführt.

bitcoin-cli getrawmempool true

getmempoolentry <txid>: Mit diesem Befehl könnt ihr spezifische Informationen zu einer Transaktion in eurem Mempool abfragen, indem ihr die Transaktions-ID (txid) angebt. Dies ist nützlich, um den Status und die Details einer bestimmten Transaktion zu überprüfen.

bitcoin-cli getmempoolentry <txid>

Mempool-Konfigurationsoptionen: Beim Starten von bitcoind könnt ihr verschiedene Optionen angeben, um das Verhalten eures Mempools anzupassen. Zum Beispiel:

• maxmempool=<n>: Legt die maximale Größe des Mempools in Megabytes fest.
• mempoolexpiry=<n>: Setzt die Zeitdauer (in Stunden), nach der eine Transaktion aus dem Mempool entfernt wird, falls sie nicht in einen Block aufgenommen wird.
• minrelaytxfee=<amt>: Definiert die minimale Gebühr in BTC/kB, die eine Transaktion zahlen muss, um von deinem Knoten angenommen zu werden.

Diese Optionen können in der Konfigurationsdatei bitcoin.conf festgelegt oder direkt beim Start von bitcoind als Befehlszeilenargumente angegeben werden.

1. bitcoind -maxmempool=300 -mempoolexpiry=72 -minrelaytxfee=0.00001

Diese Befehle und Optionen sind zentral, wenn es darum geht, euren eigenen Mempool im Bitcoin-Netzwerk via der Kommandozeile zu verwalten und zu überwachen. Sie können euch helfen, bitcoin besser, auf der ebene des Terminals, zu verstehen.

Visualisierter Mempool

Der mempool auf der eigenen Fullnode kann natürlich auch visualisiert verwendet werden, um Transaktionen zu analysieren oder zu begutachten. Für Anfänger empfiehlt sich deshalb, den visuallsierten Mempool auf der eigenen Fullnode zu installieren. Auf Umbrel und dem Raspiblitz zum Beispiel gibt es dafür Apps. Habt ihr diese installiert, so könnt ihr den internen Mempool der eigenen Fullnode visualisieren, und wie auf der Seite von mempool.space verwenden.

Der Mempool ist auf dem Raspi bei mir bereits installiert, deshalb steht bei mir Open. Bei einem nicht installiertem mempool, wird dort natürlich Install stehen.

Abschließende Gedanken

Ihr habt nun einen tieferen Einblick in die funktionsweise des mempools erhalten. Das macht die Benutzung der Seite doch gleich viel verständlicher. Benutzt ihr euren eigenen Mempool, so werdet ihr sogar noch einen Schritt unabhängiger, den ihr müsst der Seite mempool.space nicht mehr vertrauen, sondern verifziert eure Daten selber! Der Bitcoin Mempool spielt eine wichtige Rolle für die Funktionsweise und dem Verständnis von Bitcoin. Er ist nicht nur ein notwendiger Bestandteil für die Verarbeitung und Bestätigung von Transaktionen, sondern bietet auch Einblicke in die Netzwerkdynamik und -leistung.

The post Was ist der Bitcoin Mempool appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was sind UTXOs?

Bitcoin-Transaktionen funktionieren etwas anders als traditionelle Banktransaktionen. Wenn ihr Bitcoin sendet, nützt ihr im Grunde genommen frühere Transaktionen, die an euch gesendet wurden (also Beträge, die ihr bisher noch nicht ausgegeben habt), um neue Transaktionen zu erstellen. Diese unverbrauchten Eingaben werden als Unspent Transaction Outputs (UTXOs) bezeichnet. Wir hatten dazu bereits ein ausführlichen Artikel geschrieben. Schaut mal hier vorbei falls ihr im Allgemeinen mehr über UTXOs erfahren wollt.

Warum ist UTXO-Management wichtig?

Kostenoptimierung
Bitcoin-Transaktionen benötigen Gebühren, die von der Größe der Transaktion in Kilobyte (KB), nicht vom übertragenen Betrag, abhängen. Eine Transaktion, die viele kleine UTXOs als Eingaben verwendet, ist größer und daher teurer. Durch geschicktes Verwalten deiner UTXOs könnt ihr also Geld sparen.

Privatsphäre
Wenn ihr Transaktionen durchführt, die viele UTXOs zusammenfassen, kann das Muster euer Transaktionen eure Identität preisgeben. Durch das sorgfältige Auswählen von UTXOs für jede Transaktion könnt ihr eure finanzielle Privatsphäre besser schützen.

Tipps für effektives UTXO-Management

• UTXOs Konsolidieren bei niedrigen Gebühren
  Wenn die Netzwerkgebühren niedrig sind, ist es eine gute Strategie, mehrere kleine UTXOs in einer einzigen Transaktion zu konsolidieren. So zahlt ihr einmalig eine niedrigere Gebühr, anstatt später für Transaktionen mit vielen kleinen UTXOs höhere Gebühren zu zahlen.
  
• Nutzung von SegWit-Adressen oder Taproot Adressen
  Segregated Witness (SegWit) und Taproot Adressen reduzieren die Größe von Transaktionen, was wiederum die Gebühren senkt. Indem ihr Bitcoins auf SegWit- oder Taproot Adressen haltet und von dort sendet, optimiert ihr die Gebühren.
  
• Coin Control Features nutzen
  Einige Bitcoin-Wallets bieten Coin Control Features, die es euch ermöglichen, spezifische UTXOs auszuwählen, die du für eine Transaktion verwenden möchtet. Dies ist besonders nützlich, um die Privatsphäre zu erhöhen und Gebühren zu optimieren. Um Coin das Coin Controll Feature soll es hier aber heute nicht gehen.
  
• Achtet auf die Datenschutzaspekte
  Beim Zusammenführen von UTXOs in einer Transaktion können Muster entstehen, die Rückschlüsse auf eure Identität oder euer Verhalten zulässt. Überlegt daher genau, welche UTXOs Ihr zusammenführt, insbesondere wenn diese über verschiedene Quellen und Zeiträume hinweg gesammelt wurden. Zum Beispiel dürft ihr niemals UTXOs aus Coinjoins mit ungemischten Coins zusammen konsolidieren.
  
• Batch-Transaktionen
  Wenn Ihr mehrere Zahlungen gleichzeitig senden müsst, erwäge die Nutzung von Batch-Transaktionen, um mehrere Ausgaben in einer einzigen Transaktion zu bündeln. Dies spart Gebühren und kann auch die Privatsphäre verbessern, indem es die Zuordnung von Ausgaben zu bestimmten Empfängern erschwert.
  
• Gebühren-Tools und -Estimatoren nutzen:
  Es gibt verschiedene Tools und Dienste, die euch helfen können, die optimale Gebühr für eure Transaktion zu bestimmen. Die Nutzung solcher Ressourcen kann euch helfen, unnötig hohe Gebühren zu vermeiden. Hierzu lässt sich sagen, das ein Blick auf https://mempool.space euch eigentlich immer die aktuellsten Gebühren anzeigen. Die Gebührenberechnungen von Wallets, sind teilweise eher ungenau.

Konsolidierungen auf der Bitbox02 durchführen

Wir schauen uns an, wie wir UTXOs auf der Bitbox02 durchführen, wie wir die Gebühren bestimmen und wie wir Konsolidierungs-Transaktion schlussendlich ausführen. Öffnet eure Bitbox App, gebt euren Pin ein. Links findet ihr eure Wallets. Klickt auf eines das ihr konsolidieren möchtet. Das kann z.B eure Pocket Wallet sein, auf dem ein Sparauftrag läuft.

Klickt in eurer Wallet oben zuerst auf Erhalten. Wir benötigen zuerst eine interne Empfangsadresse die wir uns zuerst generieren müssen. Im nächsten Fenster wird euch eine neue Adresse angezeigt. Die müsst ihr kurz auf der Bitbox02 bestätigen, damit ihr diese kopieren könnt.

Überprüft kurz die Adresse, klickt danach einfach auf den kopieren Button neben der Adresse und bestätigt die Adresse auf der Bitbox02, sonst schliess sich das Fenster nicht mehr.

Nun geht ihr in eurer Wallet auf Senden. Fügt die Empfangsadresse ein, die ihr gerade kopiert habt, in das Feld der Empfangsadresse hinzu. Wichtig ist, das ihr unten den Haken bei Alles senden setzt.

Die Gebühren sind am besten immer manuel zu setzen, da die Schätzung für die Voreinstellungen manchmal sehr daneben sein können, vor allem wenn sich die Gebühren plötzlich schnell ändern. Geht dazu auf die Seite https://mempool.space und checkt die Gebühren dort:

Schaut euch den ersten Block an. Ihr seht das die minimale Gebühr um in den ersten Block zu kommen bei 11 sats/vybtebeträgt. Damit ihr im ersten Block landet, würde ich hier 13 Sats/vbyte nehmen. Umso höher ihr die Gebühren ansetzt, umso besser seid ihr gegen plötzliche starke Gebührensteigerungen geschützt.

Geht zurück zum Senden Tab der Bitbox app und gebt bei Gebühren eine eigene Gebühr ein mit dem Wert 13:

Klickt als nächtes unten auf Prüfen. Ihr bekommt ein neues Feld mit den Angaben eurer Transaktion. Hier könnt ihr nochmals eure Einstellungen anschauen, und falls alles gut ist, auf eurer Bitbox bestätigen. Nachdem ihr die Transaktion mit eurer Bitbox signiert habt, wird die abgesetzt und wandert in den Mempool der Miner. Die Transaktion sollte einige wenige Momente nach dem absetzen, in eurer Übersicht wieder auftauchen, aber als Konsolidierung. Nachdem die Transaktion gemint ist, wird sie als Bestätigt angezeigt. Ist diese noch unbestätigt, könnt ihr sie im Mempool sichten, indem ihr auf das Lupensymbol geht, dort dann ganz unten die TransaktionsID kopiert, und diese im Mempool eingebt.

UTXOs auf der Fullnode konsolidieren

Die Konslidierug auf der eigenen Fullnode ergibt natürlich auch Sinn. Habt ihr einige UTXOs angesammelt, die z.B aus Resten von eröffneten Kanälen bestehen, könnt ihr diese kleinen UTXOs bei geringen Gebühren konsolidieren. Damit werden Kanaleröffnungen z.B deutlich günstiger, da die Öffnung da nur aus einem einzigen UTXO besteht.

Die einfachste Möglichkeit ist, die UTXOs via RTL, bzw Ride the Lightning (Metallica lässt Grüssen) zu konsolidieren. Ride the Lightning is eine Managementsoftware für Eure Fullnode. Dafür benötigt Ihr natürlich zuerstmal RTL.

Umbrel

Die Installation von RTL via Umbrel ist schnell und einfach. Geht auf die Apps, und sucht nach Ride the Lightning. Links ist RTL für LND, und rechts für C-Lightning.

Raspiblitz

Die Installation auf dem Raspi ist ähnlich einfach. Loggt euch vial SSH ein, und gebt menu in die Befehlszeile ein. Hier geht ihr auf Services und installiert euch Ride the Lightning für LND:

Setzt den Stern mit Enter und bestätigt mit OK. Beachtet, das die Installation auf dem Blitz einige Zeit in anspruchen nehmen kann.

Die Installation kann auch im Web-GUI des Raspis durchgeführt werden. Geht dazu links auf Apps, und installiert euch unten Ride the Lightning. Der Raspi wählt die korrekte Installation für eure Lightning Implementation aus:

BTCPay Server

RTL ist auf dem BTCPay Server bereits von Haus aus installiert.

Konsolidierung via RTL durchführen

Öffnet dazu als nächstes RTL. Das Passwort für Umbrel findet ihr im Appstore selber wenn Ihr RTL öffnet. Auf dem Raspiblitz müsst Ihr kein Passwort eingeben, auf dem BTCPay Server ebenso nicht.

Geht auf den Tab Onchain links in der Übersichtsleiste, und klickt auf Generate Address:

Kopiert Euch die Adresse in die Zwischenablage. Klickt danach oberhalb Generate Address auf Sweep All, danach links nochmals auf das neue Feld Sweep All, und gebt hier die kopierte Adresse ein:

Wählt aus dem Drop-Down Menu Fee aus, und gebt anschliessend wieder die Fee ein, die Ihr von https://mempool.space entnommen habt, wie beim Beispiel der Bitbox beschrieben. Klickt danach auf Next, und bestätigt den Sweep.

Unter Onchain --> UTXO --> Transaktion --> View Info könnt Ihr Euch die TransaktionsID heraussuchen und diese wieder im Mempool sichten und überprüfen.

Gratulation, ihr habt nun eure UTXOs erfolgreich konsolidiert. Damit lassen sich vor allem bei hohen Onchain Fees einiges an Gebühren sparen, wir reden hier dann nicht nur von ein paar wenigen Cents.

Fazit

Effektives UTXO-Management ist ein wichtiger Aspekt der Nutzung von Bitcoin, der sowohl die Kostenoptimierung als auch den Datenschutz betrifft. Durch die Anwendung der oben genannten Strategien könnt ihr nicht nur Gebühren sparen, sondern auch eure finanzielle Privatsphäre besser schützen. Es erfordert allerdings ein wenig Aufwand und Verständnis für die Funktionsweise von Bitcoin. Mit der Zeit und etwas Übung wird das Management deiner UTXOs jedoch zur zweiten Natur.

The post Mit UTXO Management Bitcoin Onchain Gebühren sparen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist überhaupt ein Fork

Eine Fork, oder auf Deutsch "Gabelung", ist ein Ereignis, bei dem sich die Protokollregeln einer Blockchain-Technologie ändern, was oft zur Entstehung von zwei getrennten Blockchain-Verläufen führt. Dies ist vergleichbar mit einer Weggabelung, an der man sich entscheiden muss, welchen Pfad man einschlagen möchte. In der Blockchain-Welt kann dies allerdings weitreichende technische, soziale und ökonomische Folgen haben.

Hard Fork

Ein Hard Fork ist eine radikale Änderung des Protokolls einer Blockchain, die dazu führt, dass früher gültige Blöcke und Transaktionen ungültig werden (oder umgekehrt). Bei einem Hard Fork teilt sich die Blockchain in zwei separate Ketten: die alte Kette und die neue Kette, die mit dem aktualisierten Protokoll läuft. Das bedeutet, dass Miner und Nodes (die Computer, die Transaktionen validieren und Blöcke zur Blockchain hinzufügen) entscheiden müssen, welche Kette sie unterstützen wollen. Nicht kompatible Nodes werden von der neuen Kette abgeschnitten.

Hard Forks können aus verschiedenen Gründen durchgeführt werden, z.B. zur Behebung von Sicherheitslücken, zur Hinzufügung neuer Funktionen oder zur Umkehrung von Transaktionen, wie im Fall des DAO-Hacks auf der Ethereum-Blockchain.

Beispiel Hardforks

Ein bekanntes Beispiel für einen Hard Fork bei Bitcoin ist die Spaltung in Bitcoin und Bitcoin Cash im August 2017. Diese Spaltung wurde durch Meinungsverschiedenheiten in der Bitcoin-Gemeinschaft über die Größe eines Blocks ausgelöst. Bitcoin Cash erhöhte die Blockgröße, um mehr Transaktionen pro Block zu ermöglichen und somit die Skalierbarkeit der Kette zu verbessern.

Ein weiteres Beispiel eines Hardforks: Bitcoin Satoshi Vision (BSV) ist ein Ergebnis eines Hard Forks, der sich von der Bitcoin Cash (BCH) Blockchain abgespalten hat. Dieser Fork fand am 15. November 2018 statt. Die Spaltung war das Ergebnis tiefer Meinungsverschiedenheiten innerhalb der Bitcoin Cash-Community über die zukünftige Richtung und technische Ausrichtung der Kryptowährung.

Soft Fork

Im Gegensatz dazu ist ein Soft Fork eine rückwärtskompatible Methode zur Aktualisierung der Blockchain. Das bedeutet, dass die neuen Regeln, die durch den Soft Fork eingeführt werden, so gestaltet sind, dass sie mit den alten Regeln übereinstimmen. Blöcke, die unter den neuen Regeln erstellt wurden, werden von Nodes, die noch nicht aktualisiert wurden, als gültig angesehen. Das führt dazu, dass es nicht zu einer dauerhaften Aufspaltung der Blockchain kommt, da die alte und die neue Kette kompatibel sind.

Soft Forks benötigen eine Mehrheit der Miningleistung im Netzwerk, um erfolgreich zu sein, da ohne ausreichende Unterstützung die Gefahr besteht, dass die neue Kette zu kurz bleibt und von der längeren, unter den alten Regeln arbeitenden Kette überschrieben wird. Spielen also nur wenige Miner und Nodes innerhalb einer bestimmten Zeit das Update ein, scheitert der Softfork und die originalle Kette wird weitergeführt.

Beispiel Softfork

Bei SegWit, kurz für Segregated Witness, handelt es sich um ein Update für die Bitcoin-Blockchain, das als eine sanfte Verzweigung, oder Soft Fork, eingeführt wurde. Eine Gruppe innerhalb der Bitcoin-Community plädierte stark für SegWit, da sie überzeugt war, dass es nicht nötig sei, die Größe der Blöcke dauerhaft zu erhöhen. Eine permanente Erhöhung der Blockgröße würde nämlich zu langfristigen Skalierungsproblemen führen und die Anforderungen an die Hardware für das Betreiben einer Node signifikant steigern. Für die Befürworter von SegWit war es zudem entscheidend, die von Bitcoin-Erfinder Satoshi Nakamoto im Jahr 2010 eingeführte Obergrenze für die Blockgröße von einem Megabyte beizubehalten.

Diese Gruppe suchte nach einem Weg, um innerhalb dieser Blockgrößenbegrenzung mehr Transaktionen abwickeln zu können. Ihre Lösung war SegWit. Dieser Ansatz basiert darauf, die Signaturdaten – also jene Daten, die zur Überprüfung, aber nicht für die Durchführung einer Transaktion nötig sind – aus den Transaktionen herauszulösen. Dadurch wird im Block mehr Platz für Transaktionen geschaffen, ohne dass dessen Größe verändert werden muss. SegWit ist demnach eine Anpassung der ursprünglichen Bitcoin-Blockchain, die ohne eine Vergrößerung der Blöcke auskommt.

Auf der anderen Seite gab es eine Fraktion innerhalb der Bitcoin-Community, die eine ganz andere Vision für die Zukunft von Bitcoin hatte. Diese Gruppe wollte Bitcoin für den Massenmarkt skalieren und sah SegWit als eine zu komplexe und unzureichende Lösung an. Ihrer Meinung nach war die Limitierung der Blockgröße ein überholtes Konzept. Sie argumentierten, dass das Netzwerk mit der derzeitigen Kapazität von durchschnittlich sieben Transaktionen pro Sekunde nicht in der Lage sein würde, sich zu einem dominierenden Zahlungsmittel zu entwickeln. Ihr Vorschlag war einfach: Erhöhe die Blockgröße und lasse das Netzwerk mehr Transaktionen verarbeiten.

Da keine Einigung zwischen diesen beiden Lagern erzielt werden konnte, führte dies letztendlich zu einer kontroversen Abspaltung, auch bekannt als „contentious fork“. Diese Spaltung illustriert die Herausforderungen und Debatten innerhalb der Bitcoin-Community hinsichtlich der besten Wege, um Skalierbarkeit und Effizienz des Netzwerks zu verbessern, während gleichzeitig versucht wird, den ursprünglichen Prinzipien von Bitcoin treu zu bleiben.

Temporary Forks

Neben den beiden Haupttypen von Forks gibt es auch kurzfristige Abspaltungen, sogenannte "temporary forks". Diese können auftreten, wenn zwei Miner fast gleichzeitig einen neuen Block finden. Das Netzwerk wird kurzzeitig in zwei Ketten aufgeteilt, bis ein nächster Block gefunden wird. Die Kette, die zuerst den nächsten Block findet, wird als die gültige betrachtet, und die Blöcke der kürzeren Kette werden verworfen. Solche temporären Abspaltungen sind normal und werden durch das Konsensprotokoll der Blockchain automatisch gelöst.

Was passiert bei einem Fork mit Euren Coins

Eine ist eine sehr wichtige Frage, denn was mit deinem Coinbestand bei einem Fork passiert, kann sich je nach Art des Forks und den Umständen unterscheiden. Schauen wir uns doch an, was bei unterschiedlichen Forks passieren kann.

Hard Forks

Bei einem Hard Fork spaltet sich die Blockchain in zwei separate Ketten, und wenn Ihr Coins auf der ursprünglichen Kette vor der Abspaltung besitzt, findet Ihr Euch oft in der Position wieder, dieselbe Menge an Coins auf beiden Ketten zu besitzen. Das liegt daran, dass die Transaktionshistorie bis zum Zeitpunkt des Forks auf beiden Ketten identisch ist. Nach dem Fork existieren jedoch zwei separate und unabhängige Blockchains, und die Coins können auf jeder Kette unabhängig voneinander bewegt werden.

Nehmen wir das Beispiel von Bitcoin und Bitcoin Cash: Wenn Ihr vor dem Fork 10 Bitcoins hattet, würdet Ihr nach dem Fork 10 Bitcoins und zusätzlich 10 Bitcoin Cash besitzen. Um Zugriff auf beide Coinbestände zu haben, müsst Ihr sicherstellen, dass Eure Coins in einer Wallet waren, die beide Ketten unterstützt, oder dass Ihr die privaten Schlüssel kontrolliert, um sie in eine solche neue Wallet zu importieren. Um die Bitcoin Cash beständige zu bewegen, müsste Eurer ursprünglicher Seed auf einer Bitcoin Cash Wallet wiederhergestellt werden. Solche Forks, sollte man dann in der Regel schnell verkaufen, den zu 99% werden die nach einer Abspaltung abgestossen.

Soft Forks

Bei einem Soft Fork bleibt die Blockchain im Wesentlichen intakt und wird nicht in zwei separate Ketten aufgespalten. Da es keine Aufteilung der Kette gibt, ändert sich an Eurem Coinbestand direkt nichts. Die Coins bleiben auf der gleichen Kette, und es gibt keine "Kopie" Eurer Coins auf einer neuen Kette, wie es bei einem Hard Fork der Fall wäre. Stattdessen setzt die Blockchain ihre Existenz fort, allerdings mit aktualisierten Regeln.

Umgang mit neuen Coins nach einem Fork

Wichtig ist nochmals, dass der tatsächliche Wert der Coins auf den neuen Ketten nach einem Hard Fork stark variieren kann. Während nur die wenigsten Forks einen Wert erlangen können, werden die meissten weniger wertvoll oder sogar wertlos. Es hängt von vielen Faktoren ab, einschließlich der Unterstützung durch Miner, Entwickler und Börsen sowie der Nachfrage und Akzeptanz innerhalb der Krypto-Gemeinschaft.

Außerdem ist es wichtig, vorsichtig zu sein, wenn Ihr Zugang zu Coins auf einer neuen Kette beansprucht, besonders wenn dies bedeutet, dass Ihr Eure privaten Schlüssel in eine neue Wallet oder Software importieren müsst. Es besteht immer das Risiko von Betrug oder Diebstahl, daher ist es ratsam, gründliche Recherchen anzustellen und nur vertrauenswürdige Software und Dienste zu nutzen. Eine per Hardware Wallet generierter Seed, sollte niemals in eine Software Wallet eingebeben werden!

Zusammenfassung

Der Hauptunterschied zwischen Hard Forks und Soft Forks liegt in ihrer Kompatibilität: Hard Forks führen zu zwei getrennten Ketten, die nicht mehr miteinander kompatibel sind, während Soft Forks rückwärtskompatibel sind und darauf abzielen, die Einheit der Kette zu bewahren. Hard Forks können als eine Art "Demokratie in Aktion" innerhalb der Blockchain-Gemeinschaft gesehen werden, bei der signifikante Änderungen durch die Schaffung einer neuen Kette vorgenommen werden. Soft Forks hingegen sind subtiler und erfordern weniger drastische Entscheidungen von den Teilnehmern des Netzwerks.

The post Unterschied zwischen Hardfork und Softfork in der Blockchain appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die Phoenix Wallet im Detail

Phoenix ist bewusst einfach gehalten. Ihr müsst kein Lightning-Experte sein, um sie zu nutzen: Die App öffnet und verwaltet die Zahlungskanäle selbst, ihr seht im Alltag nur Guthaben, Empfangen und Senden. Das Setup ist in wenigen Minuten erledigt. Was dahinter passiert, lohnt sich trotzdem zu verstehen, weil es bestimmt, was die Wallet kostet und wem ihr dabei vertraut.

Self-Custodial: die Schlüssel liegen bei euch

Der Begriff "Self-Custodial" bedeutet, dass nur ihr als Nutzer den Zugriff auf eure Coins habt. Beim Anlegen einer Wallet erzeugt Phoenix eine Wiederherstellungsphrase aus zwölf Wörtern; die App bezeichnet sie als "BIP39 seed with standard BIP84 derivation path". Das README des Projekts sagt es unmissverständlich: Nur ihr habt diese Phrase, ihr seid für die Sicherung verantwortlich, und wer sie verliert, verliert das Guthaben. Im Gegensatz zu einer Custodial-Lösung wie der Wallet of Satoshi, bei der der Anbieter die Schlüssel verwaltet, behaltet ihr bei Phoenix die Kontrolle.

Ein einziger Kanal, der mitwächst

Im Lightning Netzwerk braucht es Zahlungskanäle, um Zahlungen senden und empfangen zu können. Phoenix verbindet euch dafür mit einem Kanal direkt zum Knoten von ACINQ, der die Zahlungen weiterleitet. Seit dem Umbau auf Splicing im Juli 2023 hat jeder Nutzer laut ACINQs Ankündigung nur noch einen einzigen Kanal ("each user has only one channel"), der bei Bedarf vergrössert oder verkleinert wird, statt dass neue Kanäle danebengelegt werden. Ihr müsst also keine Kanäle von Hand öffnen oder schliessen.

On-Chain und Lightning in einer App

Phoenix kann sowohl On-Chain-Bitcoin empfangen als auch über Lightning bezahlen. On-Chain-Einzahlungen landen zuerst in einer sogenannten Swap-in-Wallet und werden von dort automatisch in den Lightning-Kanal übertragen, sobald die Gebühr unter der von euch festgelegten Grenze liegt. Ihr müsst also nicht zwischen zwei Wallets wechseln. Ausgehende On-Chain-Zahlungen laufen ohne Tauschdienst direkt aus dem Kanal; ACINQ beschreibt das in der Splicing-Ankündigung als "trustless", die Gebühr setzt ihr selbst und könnt sie nachträglich erhöhen.

Eigener Electrum-Server und Tor

Um die Kanäle abzusichern, beobachtet Phoenix die Bitcoin-Blockchain über Electrum-Server. Ab Werk nimmt die App dafür zufällige öffentliche Server; unter Einstellungen → Electrum-Server lässt sich ein eigener Server eintragen, laut App über den TLS-Port, Vorgabe 50002, oder bei Onion-Adressen über den einfachen TCP-Port. Wer eine eigene Node mit Electrum-Server betreibt, findet im Vergleich ElectRS vs ElectrumX vs Fulcrum die passende Software. Zusätzlich gibt es eine Einstellung für Tor; ist sie aktiv, warnt die App, wenn der eingetragene Electrum-Server keine Onion-Adresse hat.

Installation der Phoenix Wallet

Laut README gibt es Phoenix für iOS im App Store (ab iOS 15) und für Android bei Google Play oder als APK direkt von der Release-Seite auf GitHub (ab Android 8). Wer Google Play ohne Google-Konto nutzt, bekommt dieselbe App über den Aurora Store. Bei Wallets, die echtes Geld verwalten, gilt eine einfache Regel: nur aus diesen Quellen installieren, nie aus einer Spiegelseite oder einem fremden Repository. Wer das APK von GitHub nimmt, prüft es vor der Installation; die Release-Seite liefert dafür eine signierte Prüfsummendatei, wie das geht, steht in der Anleitung Sicher downloaden auf Github mit ASC Verifizierung. Stand 04.10.2026 führt die Release-Seite Phoenix 2.8.1 als jüngste Version.

Einrichtung der Phoenix Wallet

Beim ersten Start erzeugt die App eure Wiederherstellungsphrase aus zwölf Wörtern. Sie ist der Schlüssel zur Wallet und zum Guthaben im Kanal und wird gebraucht, um die Wallet bei Verlust des Telefons wiederherzustellen. Ohne diese Phrase ist das Guthaben verloren, und auch ACINQ kann es nicht wiederherstellen, weil ACINQ die Schlüssel nie hatte. Schreibt die Phrase nach Anleitung der App auf und bewahrt sie an einem sicheren Ort auf. Sie gehört nicht in eine Datei auf dem Rechner und nicht in ein Foto, sondern auf Papier. Die Bildschirmfotos in diesem Artikel stammen vom Februar 2024; Bezeichnungen und Anordnung können in aktuellen Versionen abweichen.

Bestätigt am Schluss, dass ihr eure Wiederherstellungsphrase gesichert habt. Unter Einstellungen → Zugriffskontrolle lässt sich der Zugang zur App zusätzlich mit einer sechsstelligen PIN oder mit der Systemsperre des Telefons schützen, samt automatischer Sperre nach einigen Minuten Inaktivität. Nutzt das.

Anwendung der Phoenix Wallet

Kanal-Verwaltung und Gebühren

Eingehende Zahlungen brauchen manchmal eine On-Chain-Transaktion, nämlich dann, wenn im Kanal nicht genug Platz für den Betrag ist und er vergrössert werden muss. Die App sagt dazu selbst: "Incoming payments sometimes require on-chain transactions. This does not always happen, only when needed." Die Kosten dafür setzen sich laut Zahlungsdetails aus zwei Teilen zusammen: einer Servicegebühr für die Liquidität, die ACINQ bereitstellt, und der Gebühr an die Miner für die On-Chain-Transaktion. Wie hoch die Mining-Gebühr ausfällt, hängt von der aktuellen Auslastung der Blockchain ab; deshalb lohnt es sich, Phoenix eher seltener mit grösseren Beträgen aufzuladen als ständig mit kleinen.

Damit euch keine teure Kanalvergrösserung überrascht, gibt es unter Einstellungen → Kanal-Verwaltung eine Maximale Gebühr. Die App erklärt sie so: "Zahlungen, deren Gebühren diesen Wert überschreiten, werden abgelehnt." Ist die Gebühr gerade zu hoch, wartet Phoenix laut ACINQ und versucht es später erneut. Der Bildschirm zeigt auch, wie hoch die Gebühren aktuell geschätzt werden. Liegt eure Grenze dauerhaft darunter, kommen Zahlungen, die eine Vergrösserung brauchen, nicht an; dann die Grenze anheben oder auf ruhigere Zeiten warten. Lasst das Automatische Kanal-Management eingeschaltet: Ist es aus, werden laut App alle eingehenden Zahlungen abgelehnt, die eine On-Chain-Operation brauchen, und On-Chain-Einzahlungen bleiben On-Chain liegen.

Sats aufladen

Um die Wallet verwenden zu können, gibt es zwei Wege: On-Chain, also direkt über die Bitcoin-Blockchain, oder über das Lightning Netzwerk. Eine Übersicht weiterer Wege bietet der Artikel Die schnellsten Möglichkeiten Bitcoin in Lightning BTC umzuwandeln.

Methode 1: Mit On-Chain-Guthaben aufladen

Ihr sendet euch Sats, zum Beispiel von eurer Hardwarewallet, auf die On-Chain-Adresse von Phoenix. Diese findet ihr, wenn ihr auf der Hauptseite einmal nach links wischt:

Sobald die Einzahlung bestätigt ist, überträgt Phoenix sie automatisch in den Lightning-Kanal. Das geschieht nur, wenn die Gebühr unterhalb der Maximalen Gebühr in der Kanal-Verwaltung liegt; bis dahin zeigt die App die Einzahlung als wartend an. Wichtig: Eine Einzahlung, die nicht übertragen wird, wartet nicht ewig. Die App hält fest, dass sie nach vier Monaten Wartezeit nicht mehr auf Lightning umgetauscht werden kann und dann von Hand On-Chain ausgegeben werden muss. Wer eine Einzahlung lange in der Warteschlange sieht, prüft also die Gebührengrenze.

Methode 2: Direkt via Lightning von einer Börse aufladen

Viele Börsen unterstützen Lightning, zum Beispiel Bitfinex oder Kraken. Dort lassen sich gekaufte Bitcoin über die internen Umwandlungswerkzeuge in Lightning-Guthaben umwandeln und dann an eine Lightning-Rechnung auszahlen. Die folgenden Bildschirmfotos zeigen das bei beiden Börsen im Februar 2024; die Oberflächen der Börsen ändern sich häufig.

Am Beispiel Bitfinex, wie es im Februar 2024 ablief: Auf dem Börsenkonto lagen 100'000 Lightning-Sats. In Phoenix erstellt ihr unter Empfangen eine Rechnung, ändert dort den Betrag und tragt die Menge ein, die ihr auszahlen wollt. Bitfinex zog damals eine eigene Lightning-Gebühr von 100 Sats ab und akzeptierte deshalb nur eine Rechnung, die um diese Gebühr kleiner war als das Guthaben. Wie hoch die Gebühr heute ist, zeigt die Börse beim Auszahlen an; rechnet sie bei der Rechnung ab, sonst lehnt die Börse ab.

Die Rechnung fügt ihr bei Bitfinex unter der Auszahlung per Lightning ein:

Anschliessend werden die Sats auf eurer Phoenix Wallet gutgeschrieben. Braucht die Zahlung eine Vergrösserung des Kanals, gehen davon die Servicegebühr und die Mining-Gebühr ab:

Methode 3: Guthaben via RoboSats aufladen

Diese Methode ist die privateste der vier vorgestellten, aber auch mit Abstand die aufwändigste. RoboSats verlangt keine Identifizierung, und ihr könnt eure Lightning Wallet direkt dort aufladen. Absolut anonym ist das trotzdem nicht automatisch: Die Zahlung in Franken oder Euro hinterlässt auf der anderen Seite des Handels Spuren, und wie viel davon übrig bleibt, hängt von eurem Vorgehen ab. Warum der Verzicht auf KYC keine Garantie für Anonymität ist, steht im Artikel Ist no-KYC wirklich eine Garantie für Anonymität. Die Anleitung zu RoboSats selbst wäre hier zu lang; sie steht im Artikel Mit RoboSats anonym Bitcoin kaufen und verkaufen.

Methode 4: Auftrag bei Pocket

Bei Pocket kauft ihr Bitcoin per Banküberweisung und lasst sie über Lightning direkt an Phoenix auszahlen. Laut Pockets eigener Anleitung wählt ihr dafür beim Einrichten Phoenix als Wallet und bestätigt die Auszahlung später in der App; nach der ersten Auszahlung ist eure Phoenix Wallet dauerhaft mit eurer Zahlungsreferenz verknüpft. Wie der Kauf bei Pocket abläuft, steht in unserer Anleitung Bitcoin mit Light KYC bei Pocketbitcoin kaufen.

Sats ausgeben

Ihr habt nun Sats auf eurer self-custodial Phoenix Wallet und könnt sie überall dort ausgeben, wo Bitcoin über Lightning akzeptiert wird. Auch kleine Beträge lassen sich so bezahlen, ohne jedes Mal eine On-Chain-Gebühr zu zahlen. Mit dem Senden-Knopf scannt ihr eine Rechnung und bezahlt sie mit einem Klick auf Bezahlen.

Scannt ihr mit Phoenix eine On-Chain-Bitcoinadresse, führt die App eine normale On-Chain-Transaktion durch. Hier gilt: Achtet auf die On-Chain-Gebühren!

Zum Empfangen bietet Phoenix inzwischen auch eine Lightning-Adresse im Format ₿name@domain nach dem Standard BIP-353, die mit Bolt12-Zahlungsanforderungen arbeitet. Die App beschreibt sie als privater als LNURL-basierte Lightning-Adressen, warnt aber zugleich, das sei "bleeding edge tech": Manche Wallets und Dienste verstehen sie noch nicht und können darauf nicht zahlen. Was LNURL ist, erklärt der Artikel Was versteht man unter LNURL bei Lightning.

Was passiert, falls ACINQ von der Bildfläche verschwindet

Wer eine Wallet nutzt, deren Gegenstelle eine einzelne Firma ist, sollte wissen, was passiert, wenn diese Firma plötzlich nicht mehr da ist. Die Antwort unterscheidet sich zwischen self-custodial Wallets wie Phoenix und Custodial-Wallets wie der Wallet of Satoshi grundlegend.

Self-custodial Wallets wie Phoenix

Bei Phoenix behaltet ihr die Kontrolle über eure Schlüssel. Verschwindet ACINQ, ist das Geld im Kanal nicht weg, aber es ist zunächst blockiert: Der Kanal führt zu ACINQ, und ohne Gegenstelle lässt sich darüber nicht mehr bezahlen. Für diesen Fall gibt es unter Einstellungen → Kanäle force-closen einen Notausgang. Er läuft nicht von selbst ab, ihr müsst ihn auslösen. Die App erklärt den Bildschirm ausdrücklich zum Werkzeug für den äussersten Notfall, "for example, if your peer (ACINQ) disappears permanently, preventing you from spending your money". In allen anderen Fällen verweist sie auf den Support.

Force-Closes im Lightning Netzwerk

• Was ein Force-Close ist: Ist die Gegenpartei nicht erreichbar, könnt ihr den Kanal einseitig schliessen. Dabei wird der letzte Stand des Kanals auf die Bitcoin-Blockchain geschrieben, und euer Anteil geht an eine On-Chain-Adresse, die die App vorher anzeigt.
• Was es kostet: Laut App kostet ein Force-Close Geld für die On-Chain-Gebühren, und das Guthaben ist danach für Tage gesperrt, bevor ihr darüber verfügen könnt.
• Was ihr nicht tun dürft: Die App warnt in Fettschrift: "Do not uninstall the app until your channels are fully closed, or you will lose money." Phoenix bleibt also installiert, bis der Kanal vollständig geschlossen ist.
• Der normale Weg: Solange ACINQ erreichbar ist, gibt es keinen Grund für einen Force-Close. Wer Phoenix verlassen will, nutzt Kanäle schliessen oder überweist das Guthaben einfach an eine andere Wallet.

Custodial Wallets wie die Wallet of Satoshi

Bei Custodial-Wallets wie der Wallet of Satoshi verwaltet der Betreiber die Schlüssel. Verschwindet er, gibt es keinen Notausgang, weil ihr nie eigene Schlüssel hattet. Es gibt dann keine Möglichkeit, selbstständig an das Guthaben zu kommen. Also wie immer: Not your Keys, not your Coins!

Warum Phoenix in diesem Fall besser dasteht

• Kontrolle: Mit Phoenix habt ihr die Schlüssel. Für den Alltag braucht ihr ACINQ als Gegenstelle, für den Notausgang nicht.
• Notausgang: Der Force-Close führt das Guthaben auch ohne Mitwirkung von ACINQ auf die Blockchain zurück, kostet aber Gebühren und Wartezeit und setzt voraus, dass die App noch installiert ist.
• Nachprüfbarkeit: Der Quelltext von Phoenix ist offen. Bei einer Custodial-Lösung bleibt euch nur, dem Anbieter und seinen Sicherheitsvorkehrungen zu vertrauen.

Phoenix bietet damit deutlich mehr Kontrolle als eine Custodial-Wallet. Ein Notausgang ist aber kein Komfortausgang: Wer ihn braucht, zahlt Gebühren, wartet Tage und darf in der Zwischenzeit das Telefon nicht neu aufsetzen.

Was ACINQ über eure Zahlungen weiss

Self-custodial heisst: ACINQ kann nicht über euer Geld verfügen. Es heisst nicht, dass ACINQ nichts sieht. Phoenix hat genau einen Kanal, und der führt zu ACINQ. Ausgehende Zahlungen laufen über sogenanntes Trampoline-Routing: Nicht die App berechnet den Weg durchs Netz, sondern der Trampoline-Knoten von ACINQ. Im eigenen Blogbeitrag zur Einführung hat ACINQ im Dezember 2019 offen geschrieben, was das bedeutet: "ACINQ learns both the payer and recipient of those trampoline payments (just like custodial wallets)", und es selbst als "a liability" bezeichnet (Phoenix Wallet Part 4: Trampoline payments). Die Lösung, mehrere Trampoline-Knoten verschiedener Betreiber hintereinanderzuschalten, hing nach demselben Beitrag davon ab, dass andere solche Knoten betreiben. Dass die aktuelle App weiterhin über Trampoline sendet, zeigt ihr Quelltext; ob ACINQ dabei heute weniger erfährt als 2019, dokumentiert ACINQ nicht an einer Stelle, die sich prüfen liess.

Dazu kommt die Blockchain-Seite: Ab Werk fragt Phoenix zufällige öffentliche Electrum-Server ab, und die erfahren, welche Adressen euch interessieren. Mit einem eigenen Electrum-Server und Tor lässt sich das schliessen, siehe oben. Für eine Wallet im Portemonnaie-Format ist das ein vertretbarer Tausch. Wer aber Lightning nutzt, gerade weil er Zahlungen privat halten will, sollte wissen, dass Phoenix die Bequemlichkeit mit einem Gegenüber erkauft, das viel sieht.

Sicherheitshinweise im Umgang mit Lightning und Phoenix

Eine self-custodial Wallet wie Phoenix bietet viele Vorteile, vor allem bei Kontrolle und Sicherheit. Sie bringt aber auch Verantwortung mit sich. Diese Punkte solltet ihr beachten:

1. Sichere Aufbewahrung der Wiederherstellungsphrase

Die zwölf Wörter sind der Schlüssel zu euren Coins. Verliert ihr sie, könnt ihr den Zugriff auf eure Wallet verlieren. Bewahrt sie an einem Ort auf, zu dem nur ihr Zugang habt. Schreibt sie auf Papier und vermeidet digitale Kopien, die gehackt werden könnten.

2. Phishing-Angriffe vermeiden

Seid immer auf der Hut vor Phishing. Kriminelle versuchen, euch die Wiederherstellungsphrase zu entlocken, indem sie sich als Support, als Wallet-Anbieter oder als Börse ausgeben. Kein seriöser Dienst fragt jemals nach diesen Wörtern. Prüft die Adresse jeder Website und seid vorsichtig bei E-Mails oder Nachrichten, die nach sensiblen Informationen fragen.

3. Haltet die Wallet-Software aktuell

Entwickler aktualisieren Wallet-Software regelmässig, um Sicherheitslücken zu schliessen und neue Funktionen hinzuzufügen. Haltet eure Wallet-App deshalb immer auf dem neuesten Stand.

4. Nutzt starke und einzigartige Passwörter

Für die Börsen und Dienste, über die ihr Phoenix aufladet, gilt: starke und einzigartige Passwörter, nie dasselbe Passwort für mehrere Konten. Ein Passwortmanager hilft, sie sicher zu speichern und zu verwalten.

5. Nutzt Zwei-Faktor-Authentifizierung und die App-Sperre

Wo verfügbar, aktiviert bei Börsen die Zwei-Faktor-Authentifizierung (2FA). In Phoenix selbst schützt die Zugriffskontrolle mit PIN oder Systemsperre die App vor jemandem, der euer entsperrtes Telefon in die Hand bekommt. Schaltet sie ein.

6. Seid vorsichtig mit öffentlichen WLANs

Öffentliche WLANs können unsicher sein. Wer dort Transaktionen durchführt oder sich bei einer Börse anmeldet, achtet auf HTTPS-Verschlüsselung oder nutzt zusätzlich eine sichere Verbindung, zum Beispiel ein VPN.

7. Vermeidet es, grosse Mengen in Hot Wallets zu speichern

Phoenix ist für den täglichen Gebrauch gemacht. Bewahrt darin nur kleinere Beträge für den Alltag auf. Grössere Beträge gehören in eine Cold Wallet, die nicht ständig mit dem Internet verbunden ist. Handhabt das wie euer Portemonnaie: nehmt nur so viel mit, wie ihr unbedingt benötigt!

8. Behaltet wartende Einzahlungen im Blick

Eine On-Chain-Einzahlung, die wegen der Gebührengrenze nicht in den Kanal übertragen wird, verfällt nach vier Monaten für den Umtausch und muss dann von Hand ausgegeben werden. Schaut also nach, wenn die App eine Einzahlung länger als wartend anzeigt.

Fazit: Phoenix ist eure Lightning-Geldbörse, nicht euer Tresor

Die Phoenix Wallet ist eine hervorragende Option für alle, die Lightning nutzen wollen, ohne eine eigene Node zu betreiben und ohne die Schlüssel abzugeben. Ein einziger Kanal, automatische Verwaltung und ein echter Notausgang über den Force-Close machen sie für Einsteiger und erfahrene Nutzer gleichermassen brauchbar. Der Preis dafür ist ein Gegenüber, das eure Zahlungen weiterleitet und dabei viel sieht, und ein Notausgang, der Tage dauert und Gebühren kostet. Wer das weiss, nutzt Phoenix für das, wofür sie gebaut ist: als Geldbörse für den Alltag. Für das Ersparte bleibt die Cold Wallet zuständig; ACINQ mag freundlich sein, ein Tresor ist ACINQ nicht.

Quellen und weiterführende Links

• ACINQ/phoenix auf GitHub: README mit Bezugsquellen, Mindestversionen und Lizenz
• Phoenix-Releases auf GitHub: APK und signierte Prüfsummen
• Phoenix-Quelltext, Texte der Android-App: Kanal-Verwaltung, maximale Gebühr, Force-Close-Warnungen, Ablauf von Einzahlungen nach vier Monaten
• Phoenix-Quelltext, weitere Texte der Android-App: Wiederherstellungsphrase, Electrum-Server, Tor, Zugriffskontrolle, BIP-353-Adresse, Trampoline-Gebühr
• ACINQ: Phoenix Splicing Update (Juli 2023, ergänzt Dezember 2023)
• ACINQ: Phoenix Wallet Part 4, Trampoline payments (Dezember 2019)
• Pocket: Lightning top-up service tutorial

The post Lightning ohne Fullnode mit der Phoenix Wallet appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Das coole an Robotsats ist auch, dass ihr die Webseite auch über eine Onionadresse erreichen könnt. Das heisst also, dass hier dem ISP und weiteren Beobachtern es verunmöglicht zu wissen, dass ihr die Seite Robotsats aufgerufen habt.

Welche Vorteile habe ich bei Robosats

1. Anonymität: RoboSats legt großen Wert auf die Anonymität seiner Nutzer. Die Plattform benötigt keine persönlichen Informationen oder KYC (Know Your Customer)-Daten. Ihr könnt Transaktionen durchführen, ohne eure Identität preiszugeben.
2. Lightning Network: Die Plattform nutzt das Bitcoin Lightning Network für schnelle und kostengünstige Transaktionen. Das Lightning Network ist eine "Layer 2"-Lösung, die auf der Bitcoin-Blockchain aufbaut und es ermöglicht, kleine Transaktionen schnell und mit minimalen Gebühren abzuwickeln.
3. Dezentralisierung: Im Gegensatz zu herkömmlichen Börsen, die zentralisiert sind, bietet RoboSats eine dezentralisierte Handelsumgebung. Das bedeutet, es gibt keinen zentralen Punkt, der ausfallen oder Ziel eines Angriffs werden könnte. Ähnliche Plattformen sind Bisq und Hodlhodl
4. Einfache Benutzeroberfläche: Trotz der Fokussierung auf Datenschutz und Dezentralisierung, ist die Plattform so gestaltet, dass sie benutzerfreundlich ist und auch von Anfängern leicht bedient werden kann.
5. Sicherheit: Sicherheit ist ein wesentlicher Aspekt bei RoboSats. Die Plattform verwendet verschiedene Sicherheitsmaßnahmen, um die Transaktionen sicher und vertraulich zu halten.
6. Gemeinschaftsbasiert: RoboSats legt Wert auf die Bildung einer aktiven Gemeinschaft von Nutzern, die sich gegenseitig unterstützen und zur Verbesserung der Plattform beitragen.
7. Flexible Handelsoptionen: Ihr könnt wure eigenen Handelsbedingungen festlegen, was es ermöglicht, maßgeschneiderte Handelserfahrungen zu schaffen.

RoboSats ist also eine interessante Option für diejenigen unter wuch, die Wert auf Privatsphäre und Dezentralisierung legen, besonders im Kontext von Bitcoin-Transaktionen. Es ist eine Plattform, die versucht, die ursprünglichen Ideale von Bitcoin als dezentrales, sicheres und anonymes digitales Geld zu bewahren und weiterzuentwickeln.

Vorausetzungen um Robosats verwenden zu können

Lightning Node oder Lightning Wallet

Ihr benötigt eine Lightning Wallet, das kann eine Custodial Wallet, wie die Wallet of Satoshi sein, eine Non-Custodial Wallet wie die Phoenix Wallet, oder eure eigene Lightning Node mit genügend Outbound und Inbound Liquidität. Falls ihr eure eigene Lightning Node verwendet, müsst ihr also entsprechend Inbound Kapazität haben, um via Lightning Sats erhalten zu können. Ausserem benötigt ihr mindestens 3% des Kaufbetrags als Lightning Guthaben, falls ihr vorhabt, Sats via Robosats kaufen zu wollen. Diese 3% werden als Sicherheit hinterlegt, und um eure Echtheit zu verifzieren.

Hinweise zu den Zahlungsmethoden

Bitte lest euch die Hinweise zu den Zahlungsmethoden gut durch, damit ihr euch bestmöglichst gegen betrügerisches Verhalten schützen könnt. Der Kauf und Verkauf via Robosats selber findet Peer-to-Peer statt, jedoch kommen Verfahren zur Anwendung die sicherstellen dass ihr eure Sats auch wirklich bekommt, indem der Verkäufer zum Beispiel, bevor ihr zahlt, die Sats an eine Multi-Sig Wallet in gesperrter Form zuvor senden muss. Trotzdem solltet ihr vorher die Zahlungsmethoden und deren Eigeschaften kennen lernen, um keine unnötigen Fehler zu begehen. Bei Revolut gibt es ein Rückgabe-Erzwingen nicht wie zum Beispiel auf PayPal. Überwiesen ist überwiesen.

Amazon Gift eCards

Amazon eGift-Karten gehören zu den privateren Zahlungsmethoden auf RoboSats. Sie sind in der Regel schnell und praktisch, allerdings müssen die Mittel auf Amazon ausgegeben werden.

Es ist wichtig, einen Geschenkkartencode nicht direkt im Robosats-Chat zu teilen, da dies zu schwer lösbaren Streitigkeiten im Falle von Betrug führen kann. Als Verkäufer solltet ihr keinen Geschenkkartencode im Chat selber akzeptieren. Stattdessen sollte der Verkäufer eine E-Mail-Adresse im Chat angeben. Der Käufer sollte eine neue Geschenkkarte ausdrücklich für den Handel kaufen und sie an die E-Mail-Adresse des Verkäufers senden. Auf diese Weise weiß der Verkäufer, dass er der Einzige ist, der Zugang zum einlösbaren Code hat. Dieser Ansatz erzeugt auch verifizierbare Beweise dafür, dass die Geschenkkarte für den RoboSats-Handel gekauft wurde, falls es zu einem Streit kommt.

Falls der Käufer bereits über einen vorhandenen Amazon-Geschenkkartencode verfügt, muss der Käufer den Code zunächst auf seinem eigenen Konto anwenden. Anschließend kauft er die Artikel auf der Wunschliste des Verkäufers mit dem Kontostand. Amazon akzeptiert keine Geschenkkarten mehr als Zahlungsmittel für den Kauf von Geschenkkarten.

Weitere Details zu den Richtlinien für Amazon eGift-Karten auf Bisq findet Ihr hier.

PayPal

Paypal ist eine der am häufigsten verwendeten Fiat-Zahlungsmethoden. Allerdings kann aufgrund der Käuferschutzrichtlinie von PayPal betrügerisches Handeln stattfinden, indem der Käufer nach Abschluss des Handelsprozesses auf RoboSats einen Rückerstattungsantrag bei PayPal stellt und somit sowohl das Fiat-Geld als auch die Bitcoins allein erhält.

Dieser Betrug kann verhindert werden, indem man sich mit dem Käufer darauf einigt, dass dieser das Geld über die Option „Geld an einen Freund oder ein Familienmitglied senden“ überweist. Dadurch wird der Käufer für die Transaktionsgebühr verantwortlich und es ist weniger wahrscheinlich, dass er eine Rückerstattung anfordert.

Wenn ihr Verkäufer seid und ihr und eurer Handelspartner euch darauf geeinigt haben, die Option „Geld an einen Freund oder ein Familienmitglied senden“ zu verwenden, aber Euer Handelspartner die Option „Geld für Waren oder Dienstleistungen senden“ verwendet hat, solltet ihr die Fiat-Zahlung zurücksenden und euren Handelspartner bitten, die vereinbarte Methode zu verwenden. Wenn Er darauf besteht und es sei ja nicht so schlimm, sendet das Geld zurück, und brecht den Trade besser ab.

Anwendung und Nutzung von Robosats

Für diejenigen die nicht über das Clearnet auf Robosats zugreifen wollen, nutzen einfach die Onion Adresse von Robosats. Diese könnt ihr einfach in euren Tor Browser aufrufen und seid anonym mit der Seite verbunden. Wichtig ist, dass ihr später dann nicht über das Clearnet die Seite aufruft, ansonsten ist die Anonymität schnell dahin.

Die Onion Adresse von Robosats lautet:

robosats6tkf3eva7x2voqso3a5wcorsnw34jveyxfqi2fu7oyheasid.onion/

Beim ersten Zugriff müsst ihr euch einen Session Token erstellen. Dieser stellt sicher dass nur ihr Zugriff auf die aktuelle Sitzung habt. Mit diesem Token könnt Ihr eure Sessions auch jederzeit wieder herstellen.

Klickt hier einfach auf Start und danach auf Generate Token und eure Sitzung wird erstellt. Sichert euren Token im nächsten Fenster und klickt danach auf Continue. Robosats erstellt euch danach eine anonyme Identität welche dann verwendet wird, um Trades zu verwalten. Auf dem letzten Anmeldefeld wird euch gleich vorgeschlagen vorhanden Offers anzuschauen, oder einen Verkauf via Create zu erstellen. Ihr könnt auch zuerst einmal auf euer Profil und Euch etwas umschauen.

Auf Robosats Bitcoin kaufen

Kaufen könnt ihr unter dem Tab Offers. Hier werden alle Käufe und Verkäufe angezeigt.

Links seht ihr die Identitäten, danach ob der Order ein Kauf oder Verkauf ist, die zu handelnde Menge, Währung in der gehandelt wird, wichtig: die Zahlungsausführung und danach noch wie lange die Angebote gültig sind und die Währungsmenge in Sats umgerechnet. Weiter rechts findet ihr noch wichtige Informationen zum Preis. Wichtig ist, dass ihr auf den Aufschlag achtet, bevor ihr euch einen Trade heraussucht. Als Käufer seid ihr daran interessiert dass der Aufschlag zum Marktpreis nicht zu hoch ist.

Order auswählen

Ihr könnt euch die Offers auch nach bestimmten Filter anzeigen lassen. Klickt oben auf den Tab Kaufen/Buy um euch nur Verkäufer anzeigen zu lassen, und sortiert euch mit einem Klick auf Aufschlag die entsprechenden Angebote:

Klickt danach zum Beispiel auf das erste Angebot, danach öffnet sich auch schon direkt ein Übersicht des Angebots. Studiert dieses nochmals genau, und gebt den Betrag in der ausgewählten Währung an, und danach auf Take Order/Order Annehmen.

Der Kaufprozess

Als erstes müsst ihr eine kleine Kaution hinterlegen (nur 3% des Handelsbetrags), damit der Verkäufer weiß, dass ihr vertrauenswürdig und echt seid. Die versendeten Sats werden in eurer Wallet gelockt bzw. gesperrt. Wenn ihr versucht zu betrügen oder einseitig zu kündigen, sind die Sats weg. Haltet euch also an die vorgaben des Kaufprozesses. Dies dient unter anderem dazu, die Sicherheit auf der Plattform zu erhöhen, und Tradingbots oder einfach nur Spammerbots von der Plattform fernzuhalten.

Scanne oder kopiere die Invoice in eurer Lightning Wallet. Der Betrag wird euch vorher angezeigt, Überprüft diesem vorher bevor ihr die Invoice abschickt bzw. bezahlt. Sobald diese Zahlung eingetroffen ist, wird dieser Betrag gesperrt, bis der Kauf erfolgreich abgelaufen ist.

Sobald wuew Kaution gesperrt ist, wird RoboSats euch bitten, eine neue Lightning-Invoice zu erstellen, um wuch die Sats zu schicken. Erstellt eine Invoice mit dem genauen Kaufbetrag des Trades in eurer Lightning Wallet und schickt sie ab. Den Kaufbetrag seht ihr oben im Formular.

Nachdem ihr die Invoice eingereicht habt, wird der Verkäufer aufgefordert, die Invoice für den Handelskredit zu bezahlen und zu sperren. Nachdem der Verkäufer bestätigt habt, könnt ihr auch mit desem chatten, um euch entsprechend zu informieren oder zu koordinieren.

Es gibt vom Verkäufer ein festgelegtes Zeitlimit um die Invoice einzureichen (Käufer) und das Treuhandkonto zu bezahlen und zu sperren (Verkäufer). Läuft die Zeit ab, verfällt die Bestellung und der Teilnehmer, der sich nicht an die Vertragsverpflichtungen gehalten hat, verliert die Kaution. Dies ist ein Mechanismus, der dazu beiträgt, das Spammen von gefälschten Aufträgen, die Zeitverschwendung der Gegenparteien und das DDoSing des Auftragsbuchs zu verhindern.

Sobald der Verkäufer die Satoshis hinterlegt hat, könnt ihr beruhigt den Betrag überweisen! Als Käufer solltet ihr den Verkäufer nach den nötigen Angaben für die Fiat-Überweisung fragen. Achte darauf, nur die wirklich erforderlichen persönlichen Informationen preiszugeben, um eure Privatsphäre zu schützen. Beachtet, dass in RoboSats v0.1.0 der Chat ohne Datenspeicherung funktioniert, was bedeutet, dass eure Konversation verloren geht, wenn ihr euren Browser neu ladet. Zur Sicherheit kopiert ihr den Chat für Beweiszwecke in ein neues Textformular auf eurem Computer.

Es besteht eine Standard Frist von 24 Stunden für die Durchführung des Fiat-Tauschs. Läuft diese Frist ab, verfällt die Bestellung und es wird automatisch ein Streitfall eingeleitet. Um ein Verfallen der Bestellung zu verhindern, sollten ihr vorzugsweise stets Methoden für sofortige Fiat-Überweisungen nutzen. Das Versenden von Bargeld per Post beispielsweise ist langsam und führt in der Version v0.1.0 zwangsläufig zu einem Disput. In Zukunft sind längere Gültigkeitszeiten der Bestellungen denkbar.

Nachdem ihr die Fiat-Zahlung getätigt habt, solltet ihr die Option „Confirm fiat sent“ (Bestätige gesendete Fiat-Zahlung) anklicken. Anschließend muss der Verkäufer den Erhalt der Fiat-Zahlung bestätigen. Nach seiner Bestätigung ist der Handel abgeschlossen, und ihr erhaltet eine Gutschrift auf eure Lightning Wallet. Es kann vorkommen, dass ihr die Meldung „Satoshis wurden an den Käufer gesendet“ seht, aber in der Regel erfolgt die Transaktion so schnell, dass ihr nur diesen Bildschirm zu Gesicht bekommt.

Auf Robosats Bitcoin verkaufen mit eigenem Ordner

Kommen wir nun zum Verkauf von Sats auf Robotsats. Entweder ihr sucht euch einen Käufer im Orderbuch von Robosats, oder ihr verkäuft eure Sats selber mit einem eigenen Angebot. Mit dem Tab Create könnte ihr einen eigenen Verkauf erstellen.

Öffnet im Fenster des Verkaufs ganz oben im Formular das Advanced Menu. Dort könnt ihr den Trade genauer definieren:

Ihr macht Angaben zur Menge (Minimalbetrag/Gesamtbetrag) legt eine Zahlungsmethode fest, und definiert Aufreis und Dauer des Angebots. Zuletzt könnt ihr noch die höhe der Kaution festlegen. Stellt sicher, dass ihr den Escro/Invoice Timer auf 8hr stellt. Ansonsten kann es sein, dass in der Nacht jemand kauft, und ihr nicht bestätigen könnt! Habt ihr euer Angebot erstellt, könnt ihr diesem mit Create Order finalisieren.

Im nächsten Fenster wird euch nochmals eurer Sitzungstoken präsentiert. Stellt sicher, das Ihr diesen abgespeichert habt!

Es öffnet sich ein neues Fenster, in dem ihr den Verkauf verifzieren müsst. Ihr zahlt jetzt also auch 3% des Betrags. Dieser wird gesperrt bis ein Verkauf zustande kommt. Läuft die Zeit eures Angebots ab, werden die Sats wieder freigegeben.

Nachdem ihr die Invoice bezahlt habt, wird euer Angebot auf den Markplatz eingestellt. Ihr solltet euer Angebot nun regelmässig überprüfen. Das geht indem ihr den Browsertab einfach offen behaltet, oder auf dem Smartphone mit eurem Token unterwegs eurer Profil öffnet und checkt. Bei mir ist der Einzahlungstimer dummerweise auf 3h gesetzt. Heisst ich habe 3 Stunden Zeit, um auf einen Käufer zu reagieren. Wie im Absatz weiter oben beschrieben, bitte auf 8 Stunden setzen.

Der Verkaufsprozess

Sobald ein Käufer am Start ist, werdet ihr auf im Tab Order darüber informiert. Nach wenigen Stunden hat sich bereits ein Käufer gemeldet:

Wir müssen die Sats die wir verkaufen jetzt an die gesperrte Wallet Adresse des Käufers senden. Dieser kann nichts damit anfangen, bis wir nicht den erhalt des Geldes bestätigt haben. Im nächsten Fenser eröffnet sich ein Chat, mit dem ihr mit dem Käufer in Kontakt treten könnt:

Tauscht euch über die Zahlungsdetail aus, verwendet bitte keine persönlichen Information, sendet nur die nötigsten Information z.B den Revolut Tag, oder falls ihr euch für eine andere Zahlungsmethode geeinigt habt, diese Daten. Sobald der Käufer das Geld gesendet hat, wird er dies von seiner Seite aus bestätigen. Ihr erhaltet dann eine Benachrichtigung, und ein neuer Button taucht auf:

Bitte bestätigt erst, wenn ihr das Geld auch wirklich erhalten habt, nutzt ihr PayPal, benutzt die Familien und Freunde Option! Bestätigt ihr den erhalt des Geldes, wird eure Collateral freigegeben. Sobald das gemacht ist, könnt ihr auch nicht mehr mit der Person chatten.

Ihr bekommt anschliessend natürlich auch die 3% Gebühr, die ihr anfänglich bezahlt habt, ebenfalls zurück. Der Trade wurde erfolgreich abgeschlossen.

Eine schönes Ende nach einem Missgeschick

Dazu noch eine sehr spannendes Detail der Geschichte: Ich habe den Revolut Tag meiner Freundin angegeben, da meiner aktuell irgendwie nicht funktioniert. Der Käufer hat also auf ihren Account überwiesen. Ich informierte sie nur kurz dass ich etwas ausprobiere, und durch ein Missverständnis, schickte sie das Geld zurück an den Käufer da sie dachte Ich sei es. Der Käufer meldete sich anschliessend auf Revolut und fragte sie ob es ein Missgeschick war, und meine Freundin bestätigte dies. Der Käufer zahlte umgehend das Geld zurück!

Ich hätte keine Möglichkeit gehabt, die Rückgabe zu forcieren, da ich die Sats auf Robosats bereits freigegeben hatte. Er hätte garnichts zurückgeben müssen. Ausser seinen Revoluttag, kannten wir nichts von ihm.

Dies zeigt dochmal wieder Eindrücklich, das Bitcoiner das Herz am rechten Fleck haben. Ein grosses Dankeschön an den Käufer der mir das Geld zurückschickte, während ich dieses Tutorial schrieb!!

The post Mit Robotsats anonym Bitcoin kaufen und verkaufen appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was ist Balance of Satoshis

Balance of Satoshis (BoS) ist ein Tool, das speziell für die Verwaltung von Lightning Network Nodes entwickelt wurde. Das Lightning Network ist eine sogenannte "Layer-2"-Lösung für Bitcoin, die schnelle und kostengünstige Transaktionen ermöglicht, indem sie Transaktionen außerhalb der Haupt-Blockchain abwickelt.

Mit Balance of Satoshis könnt ihr verschiedene Aufgaben ausführen, die für das effiziente Management eurer Lightning Full-Node wichtig sind. Hier sind einige Hauptfunktionen:

1. Anzeigen von Salden: BoS ermöglicht es euch, einen schnellen Überblick über eure verschiedenen Salden auf der Node zu bekommen. Das umfasst eure gesamten Bitcoin-Bestände, sowohl in eurer On-Chain-Wallet als auch in euren Lightning-Kanälen.
2. Kanalverwaltung: Mit BoS könnt ihr Eure Lightning-Kanäle effektiver verwalten. Ihr könnt Kanäle öffnen und schließen, die Kapazitäten von Kanälen anpassen und die Verteilung Eurer Mittel in den Kanälen überwachen. Dies ist wichtig, um sicherzustellen, dass eure Node effizient und gewinnbringend arbeitet.
3. Routing und Gebühren: BoS hilft euch dabei, das Routing von Transaktionen durch eure Kanäle zu optimieren. Ihr könnt Gebühren für das Durchleiten von Zahlungen auf eurer Node festlegen und anpassen. Das Ziel ist es, ein Gleichgewicht zu finden, das genug Anreiz für andere bietet, eure Kanäle zu nutzen, ohne um Beispiel zu teuer zu sein.
4. Automatisierung: Einige Funktionen von BoS können automatisiert werden, wie zum Beispiel das Balancing eurer Kanäle. Dies bedeutet, dass uhr Eure Kanäle so einrichten könnt, dass sie automatisch Mittel hin und her verschieben, um die Effizienz des Netzwerks zu maximieren.
5. Analyse und Berichterstattung: BoS bietet auch Analyse-Tools, die euch helfen, die Leistung eurer Nodes zu verstehen. Ihr könnt Berichte über eure Einnahmen, Ausgaben und allgemeine Netzwerkaktivitäten erstellen.

Balance of Satoshis also ein nützliches Tool für jeden, der einen Lightning Network Node betreibt. Es bietet eine Reihe von Funktionen, die dabei helfen, den Node effizient zu verwalten, das Einkommen zu optimieren und einen reibungslosen Betrieb zu gewährleisten.

Installation von Balance of Satoshis

Wir schauen uns nun die Installation auf den 3 System Umbrel, BTCPay Docker und auf dem Raspiblitz an. Hier sei gesagt, das nur Umbrel über eine GUI für BOS verfügt, für BTCPay Server in der Docker Variante und den Raspiblitz gibt es dies noch nicht. Der BTCPay Server lässt sich ebenfalls eine GUI austatten, jedoch benötigt dies einige Anpassungen in der dockercompose.yml die wir uns gegebenfalls mal ein anderes mal anschauen können.

Umbrel BoS Installation

Umbrel hält eine Reihe von Apps im App Store, die eigentlich ganz nützlich sind für den Betrieb einer Full-Node. Solche Apps darf man sich gerne installieren, im Gegensatz zu beispielweise einer Nextcloud oder anderen Tools, welche nichts mit einer Full Node und deren Verwaltung zu tun hat. Geht also in den AppStore von Umbrel und sucht nacht LndBoss:

LndBoss ist eine Eigenentwicklung niteshbalusu11 der auf Github fleissig zum Lightning Netzwerk beiträgt. Die App setzt auf Balance Of Satoshis von Alex Bosworth auf und verpackt dies in einer übersichtlichen und einfachen GUI. Nachdem ihr LndBoss installiert habt, könnt ihr ein Login festlegen um die App zu sichern, und danach direkt loslegen.

Weitere Information zur App findet Ihr hier.

RaspiBlitz BoS Installation

Die Installation auf dem Blitz ist auch relativ einfach. Im RaspiBlitz CLI Menu findet ihr eine Auswahl zusätzlich Apps die ihr installieren könnt, darunter zum Beispiel auch das Tool Balance of Satoshis. Loggt euch zuerst via SSH auf Eurem Blitz ein. Der Login User ist immer admin. Gebt euer Passwort A ein. Habt ihr eine bereits fertig synchronisierten Blitz, landet ihr beim SSH Login automatisch direkt im CLI Menü. Solltet ihr nicht im CLI Menü sein, könnt ihr das tun indem ihr als Admin einfach menu in die Konsole eingebt, und mit Enter bestätigt.

Danach könnt ihr auf Additional Apps & Services:

Anschliessend findet ihr unten die Applikation BoS:

Markiert BoS mit der Leertaste und bestätigt mit OK, die Installation beginnt anschliessend und kann einige Minuten dauern.

Eine GUI wie auf Umbrel gibt es hier aber nicht. Die Befehle werden in der Konsole eingegeben. Um BoS Befehle abzusetzen, müsst ihr als User bos agieren. Dies geschieht in dem ihr einfach zuerst nur bos in die Konsole eingebt. Der Blitz switcht dann zum User bos, danach könnt ihr BoS Befehle einfach mit dem bos befehl abgeben zum Beispiel bos --help

Mit bos --help seht ihr erstmal nur eine Reihe von Befehlen die ihr verwenden könnt. Hier auf der Github Seite findet ihr mehr Beschreibungen und Hilfestellungen um mit BoS arbeiten zu können.

BTCPay Server Docker BoS Installation

Wie bereits angesprochen ist die Installation auf dem BTCPay Server etwas komplizierter, da wir BoS als Docker Container installieren, und die Konfiguration etwas anpassen müssen. Starten wir mit den Vorbereitungen:

Damit der BoS Docker Container korrekt mit LND kommunzieren kann, müssen wir zuerst eine bestimmte "Anmelde-Datei" erstellen, welche dem Container erklärt, wo im LND Container wichtige Dateien wie die tls.cert und die admin.macaroon zu finden sind.

Erstellt deshalb zuerst im Benutzerornder root den neuen Ordner .bos, danach einen Ordner mit dem Namen unserer Node, mit einer neuen leeren Datei die credentials.json heissen muss.

sudo mkdir /root/.bos
sudo mkdir /root/.bos/nodename
touch /root/.bos/nodename/credentials.json

Öffnet die credentials mit:

nano /root/.bos/nodename/credentials.json

und tragt folgenden Inhalt ein:

{
 "cert_path": "/root/.lnd/tls.cert",
 "macaroon_path": "/root/.lnd/admin.macaroon",
 "socket": "lnd_bitcoin:10009"
}

Speichert die Datei mit strg+o und beendet mit strg+x

Um Bos Befehle zu starten, benötigen wir einen ziemlich langen Befehl gefolgt vom BoS Befehl, dies ist jedoch etwas umständlich, deshalb verpacken wir das ganze in einen Script, den wir einfach ausführen können, gefolgt von BoS Befehlen aus der Dokumentation. Etwa ähnlich wie wir Befehle auf dem BTCPay Server ausführen.

Erstellt einen neue Datei mit dem Namen run_bos.sh an einem Ort eurer Wahl, z.B mit:

nano /root/run_bos.sh

Gebt folgenden Inhalt ein:

#!/bin/bash

COMMAND="$@"

docker run --user root:root -it --rm --network=generated_default -v $HOME/.bos:/root/.bos -v /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data:
/root/.lnd:ro alexbosworth/balanceofsatoshis --node nodename $COMMAND

Bitte ersetzt hier nodename fett markiert mit dem Namen eurer Node im .bos Ordner!

Speichert und beendet nano. Macht die Datei ausführbar mit chmod +x run_bos.sh

Danach könnt ihr einfach BoS Befehle ausführen mit ./run_bos.sh <bos-befehl> z.B:

./run_bos.sh report

Da der Befehl den Docker Container kurz startet, und danach wieder beendet, dauern die Outputs der Befehle etwas länger als gewohnt. Ihr habt nun aber BoS auch erfolgreich auf eurem BTCPay Server installiert und könnt BoS Befehle nutzen wie ihr wollt.

Abschluss

Da dieser Beitrag dazu diente, euch die Installation zu vereinfachen, verzichten wir hier die Vorstellung der Befehle von BoS selbst. Wie z.B mit BoS rebalancing betreibt, erfahrt ehr auf dem Youtube Video von Einundzwanzig z.B hier! Dies würde sonst die Betragslänge deutlich sprengen.

Weitere BoS Anleitungen gibts z.B hier bei Voltage.

Interessiert ihr euch für eine Eigene Full-Node? Dann schaut mal in unserem Shop vorbei, wir setzen euch auch für einen guten Preis einen eigenen BTCPay Server auf.

Ich hoffe das Tutorial konnte euch etwas weiterhelfen und die Arbeit mit eurer Node verbessern. Falls ihr Fragen habt, schreibt sie in die Kommentare.

The post Balance of Satoshis auf dem Raspi Blitz, Umbrel und BTCPay Server installieren appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Betreiber mit einer Lightning Node kommen ab einer bestimmten Anzahl an Kanälen zwangsläufig zur Frage, wie man sich am besten , beziehungsweise die Node und die Kanäle darauf, bestmöglichst absichert, und die Kanäle nach einem Ausfall wieder herstellen kann. Das Thema ist etwas komplex, aber wir schauen uns heute an, wie wir eine Lightning Node am besten absichern können, und wie wir Kanäle bei einem Totalausfall wiederherstellen können. Hier gibt es nämlich ein paar Dinge, die sehr wichtig sind, und auch ein Paar Dinge, die man auf keinen Fall machen darf, wie ich es selber schmerzlichst lernen musste. Damit euch keine Fehler passieren, besprechen wir in diesem Artikel die wichtigsten Schritte.

Wir schauen uns die besten Strategie für die Systeme Raspiblitz, Umbrel und BTCPay Docker an. Ziel ist es eine möglichst sichere Umgebung für unsere Fullnode herzustellen, um in Falle eines Platten- oder Systemausfalls schnell wieder Online zu sein und gegebenfalls alle Kanäle wiederherzustellen. Wichtig zu verstehen ist, das aktuell noch keine reinen Datenbackups aktuell nicht möglich sind. Ihr könnt also nicht eure komplette Platte klonen oder backupen, und einen Server wieder herstellen falls es zu einem Ausfall kommt.

Hintergründe und wichtiges zuerst bei Single Disk Deployments

Es gibt einige Verwirrung und Mythen darüber, wie man Off Chain Funds der eigenen Nodes am besten sichert. Ein Fehler hierbei stellt immer noch das größte Risiko dar, diese Gelder zu verlieren, obwohl alles getan wird, um diese Risiken zu minimieren. Es gibt nur ein Szenario, bei dem man das Guthaben sichert, und auf einer neuen Node wieder komplett wieder herstellen kann, inklusive allen Kanälen, und zwar dann, wenn der Server noch nicht abgeschmiert ist. In den meissten Fälle ist es aber eher umgekehrt: Der Server beziehungsweise die Node ist tot, und ihr steht da wie vom Blitz getroffen.

Welche Daten dürfen in regelmässigen backups gesichert werden

Die wichtigste Datei, die immer gesichert werden muss, ist die Datei <lnddir>/data/chain/bitcoin/mainnet/channel.backup. Diese Datei enthält die Statischen Kanal-Backups (SCBs). Sie wird nur aktualisiert, wenn die Node gestartet wird und wenn ein Kanal geöffnet oder geschlossen wird. Alle anderen Dateien auf der Node sind mehr oder weniger egal.

Die meisten Lightning-Wallet-Apps wie die WalletofSatoshi oder Phoenix laden diese Datei automatisch in die Cloud hoch.

Wie wir diese Datei sichern, und bei einem Ausfall der Node verwenden, um unsere Kanäle wiederherzustellen, schaue wir uns weiter unten dann genau an.

Welche Dateien sollte man nicht in regelmässigen Backups sichern

Das ist eine etwas trickreiche Frage, denn das Anfertigen des Backups ist nicht das Problem. Das Wiederherstellen/Verwenden einer alten Version der channel.db zu finden unter <lnddir>/data/graph/mainnet/ ist sehr riskant und sollte niemals gemacht werden!

Das erfordert etwas Erklärung:

Die Art und Weise, wie LN-Kanäle derzeit eingerichtet sind (bis eltoo/SQL) implementiert wird), ist, dass beide Parteien immer einem aktuellen Saldo zustimmen. Um sicherzustellen, dass keiner der beiden Peers in einem Kanal jemals versucht, einen alten Zustand dieses Saldos zu veröffentlichen, geben sie beide ihre Schlüssel an den anderen Peer weiter. Dies gibt ihm die Möglichkeit, alle Gelder (nicht nur ihren vereinbarten Anteil) aus einem Kanal zu nehmen, wenn ein falscher oder veralteter des Channelstates veröffentlicht wird. Daher bedeutet das Vorhandensein eines alten Kanalzustands im Grunde, dass man den Saldo an die andere Partei verlieren kann.

Da Zahlungen in LND mehrmals pro Sekunde getätigt werden können, ist es sehr schwierig, jedes Mal ein Backup der Kanaldatenbank zu machen, wenn sie aktualisiert wird. Und selbst wenn es technisch möglich ist, kann das Vertrauen, dass ein bestimmter Zustand sicher der aktuellste ist, nie absolut sein. Deshalb sollte der Fokus darauf liegen, sicherzustellen, dass die Kanaldatenbank (also die channel.db) nicht beschädigt wird, die Zombie-Kanäle zu schließen und die SCBs sicher aufzubewahren.

Ausnahmefall noch laufende Node

Kommen wir zur Ausnahme, wann eine Node doch von einem kompletten Backup wiederhergestellt werden darf: Im Ausnahmefall, und nur wirklich in diesem speziellen Fall darf man den kompletten /.lnd Ordner (in der sich die channel.db befindet) sichern, und zwar genau dann, wenn die Node noch nicht den Geist aufgegeben hat. Das komplett Backup darf also nur erzeugt werden, wenn die Node direkt nachher offline genommen wird. Raspiblitz bietet dazu die Funktion LNDRESCUE, oder die komplette Migration an. Die Scripte erstellen Backups welche beim aufsetzen einer neuen Node später verwendet werden, um alle Guthaben inklusive aller Kanäle, wieder herzustellen.

LNDRESCUE sichert nur die Lightning Node, während das Migrationsbackup vom Rapspiblitz beispielsweise eure komplette Node sichert, inklusive installierter Anwendungen und Einstellungen der Node.

Die Node wird direkt nach dem erstellen des Backups vom System selber offline genommen und heruntergefahren. BTCPay bietet ein ähnliche funktion, Umbrels OS bietet dagegen keine vollständige Sicherung von LND an. Bereitet euch also immer auf euer jeweiliges System gut vor!

Die mit Abstand beste Sicherung eurer Node

Die einfachste Methode, eure Lightning Node, beziehungsweise eure Kanäle zu sichern, ist ein einfaches RAID1 Setup. Damit sichert ihr euch gegen ein Plattenausfall ab, und könnt bei einem Plattenausfall die Node ganz normal weiterlaufen lassen, bis ihr einen Ersatz für die ausgefallene Platte habt. Das bietet sich aber leider nicht auf dem Pi4 an, da das Netzteil zu schwach ist, 2 SSDs über das Standard Netzteil zu betreiben. Habt ihr Umbrel, den RaspiBlitz oder BTCPay Docker aber auf einem Linux Server System auf dem ein Hypervisor wie Proxmox läuft, empfiehlt es sich hier unbedingt eine zweite Platte zu nutzen. Dabei empfiehlt es sich, das komplette Betriebssystem ebenfalls auf dem RAID Verbund zu haben, damit das System auch gesichert wird.

Ist es bei einem Single Disk Setup zu einem Crash eurer Node gekommen, schauen wir uns jetzt die wichtigsten Methoden an, um unsere Onchain sowie auch Kanalguthaben, falls vorhanden, wiederherzustellen. Fangen wir doch gleich mit dem Ausnahmefällen an, und zwar dann, wenn die Node noch nicht gecrasht ist.

Wiederherstellung aus Backups

Raspiblitz Backup & Restore mit LNDRESCUE

Der Raspiblitz kommt mit einer äusserst nützlichen komplett Backup & Restore namens LNDRESCUE. Dabei wird eine komplette Sicherung des kompletten .lnd Ordners durchgeführt. Heisst also, ihr könnt diese Funktion nutzen, wenn die Node noch nicht komplett abgestürzt ist, eure Festplatte bald voll ist, oder andere Dinge passiert sind die eine Neuinstallation bzw. ein Transfer voraussetzen. LNDRESCUE fährt auch eure Node nach dem Backup automatisch herunter nachdem ihr das Backup heruntergeladen habt. Dabei kann beinahe fast nichts schiefgehen

Wichtig ist, dass möglichst zur selben Raspi Version migriert wird, und es keine grossen Versionsunterschiede zwischen dem alten, und dem neuen gibt. Falls auf dem alten System noch eine 1.90 läuft, und ihr das neuste Image flasht, wie zum Beispiel 1.11, dann stehlt sicher, dass die alte Node vorher auch noch geupdated wird!

Backup Starten

Geht in das CLI Menü des Raspiblitzes mit menu und geht in die Repair Options, danach Backup / Repair LND und wählt danach Backup your LND data (Rescue-File) aus:

Der Raspi startet danach eine umfassende Sicherung der Lightning Node und stellt euch am Schluss einen Befehl zur Verfügung, der euch die Datei von einem Windows- oder Linux Rechner herunterladen lässt. Autocompact Channels könnt ihr aktivieren, um die Grösse etwas zu reduzieren. Danach ladet ihr euch mit den entsprechenden Links die Backups herunter:

Ladet die Datei herunter, bestätigt danach mit Enter, da die Node anschliessend heruntergefahren wird.

LNDRescue Backup Wiederherstellen

Nachdem ihr eine frisch installierte Node habt, könnt ihr nun die alte Node mit LNDRESCUE komplett wiederherstellen. Heisst auch den LND Seed, die Kanäle und eure komplette Transaktionshystorie. Damit ihr schnellstmöglich wieder online seid, empfielt es sich wie bereits erwähnt die Blockchain vom alten Pi zu übernehmen.

Startet den Pi mit einem frischen Image auf einem synchnronisertem, oder nicht synchronisiertem Hardwaresetup. Die LNDRESCUE Datei habt ihr optimalerweise bereits auf einem USB Stick gespeichert. Diesen benötigen wir für den LNDRESCUE Restore:

Wählt hier Restore from a rescue file aus. Im nächsten Fenster könnt ihr das Backup eurer frischen Raspiblitz Installation getrost überspringen. Folgt den Anweisungen der Konsole, und gebt den Pfad zu eurem LNDRESCUE Backup an. Das Backup wird eingespielt, die Node anschliessend neugestartet. Ihr könnt, falls ihr bereits synchronisiert seid, danach direkt eure Kanäle wieder verwenden. Habt ihr keine Kopie der Blockchain, dann müsst ihr warten, bis sich der neue Blitz synchronisiert hat, danach gehen die Kanäle wieder online.

Seid ihr zu lange offline, da ihr kein Blockchain Backup habt, kann es sein dass Kanäle aufgrund von pending htlc's geschlossen werden. Es empfiehlt sich also in diesem Fall den Raspiblitz übers Clearnet zu synchronisieren.

Raspiblitz komplete Migration auf ein neues Gerät

Wie bereits erwähnt, haben wir dazu ein eigenes Tutorial geschrieben. Dies könnt ihr nutzen, falls eure Node noch funktioniert, und ihr sie auf ein komplett neues Gerät übertragen wollt:

BTCPay Server Backup & Restore Funktion benutzen

Der BTCPay Server in der eigenständigen Docker Variante kommt mit einen eigenen Backup and Restore Script welches ihr im Home Verzeichnis von vom BTCPay Server also unter btcpayserver-docker/btcpay-backup.sh findet. Wollte ihr eure Blockchain Daten sichern, müsst ihr das separate tun z.B rsync oder direkt auf eine Sicherungsplatte.

Skript Sicherung durchführen

Loggt euch als root user ein gebt folgendenden Befehl ein:

cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
./btcpay-backup.sh

Das Skript wird folgende Schritte durchführen:

1. Sicherstellen, dass der Datenbank-Container läuft.
2. Ein Backup (Dump) der Datenbank erstellen.
3. Den BTCPay Server stoppen.
4. Die Docker-Volumes und das Datenbank-Backup archivieren.
5. Die Blockchain-Blöcke und Chainstate-Verzeichnisse ausschließen.
6. Optional: Das Archiv verschlüsseln.
7. Den BTCPay Server neu starten.
8. Aufräumen: Temporäre Dateien wie das Datenbank-Backup entfernen.

Falls alles klappt, seht Ihr folgendes: ✅ Backup done => /var/lib/docker/volumes/backup_datadir/_data/backup.tar.gz

Die Datei backup.tar.gz könnt ihr auf einem USB Stick oder auf einem anderen Medium speichern um später wieder herzustellen falls der Server die komische Anzeichen macht oder ihr auch beispielsweise einfach das System migrieren möchtet. Ihr könnt auch das Backup mit rsync z.B auf ein anderes Netzwerkgerät syncen und sichern. Fahrt den Server nach Sicherung der Datei auf ein Medium, oder auf einen Netzwerkspeicher herunter.

Skript Wiederherstellung

Ähnlich zum Skript btcpay-backup.sh aber umgekehrt: der btcpay-restore.sh Skript muss mit der Pfadangabe ausgeführt werden. also z.B

./btcpay-restore.sh /mnt/usb/backup.tar.gz

Bei einem erfolgreichem Restore bekommt Ihr: ✅ Restore done

Bedenkt dabei, dass bei einem Restore die Kanäle ebenfalls wiederhergestellt werden, und deshalb der Server direkt nach dem erstellen des Backups unbedingt heruntergefahren werden muss!

On Chain Guthaben wiederherstellen

Dies ist der einfachste und unproblematischste Schritt auf allen 3 System. Um eure Onchain-Guthaben zu sichern, braucht ihr nur den Seed bzw. die 24 Wörter für eure Bitcoin-Core Wallet oder eure Lightning On-Chain Wallet. Sollte ein System ausfallen, müsst ihr nichts anderes tun, als die Seedphrase eingeben und ihr habt eurer Guthaben zurück. Das betrifft nochmals gesagt, nur Guthaben, die nicht in Lightning Kanälen sind!

Umbrel Node

Beim Aufsetzen einer neuen Node kann beim ersten Zugriff auf die Lightning Node eine neue Wallet erstellt werden, oder eine Wallet aus einer Seedphrase wiederhergestellt werden. Um euer Onchain Guthaben wieder herzustellen, müsst ihr eure Seedphrase eingeben, die ihr beim erstellen eurer Lightning Wallet erstmalig aufgeschrieben habt.

Wählt also RECOVER YOUR PREVIOUS NODE aus, und gebt danach eure 24 Wörter ein. Damit habt ihr die Onchain Funds eurer Node wiederhergestellt. Hattet ihr vorher diverse Lightningkanäle, springt zur Umbrel Kanal Wiederherstellung um die Kanäle wieder her zu stellen.

BTCPay Server Docker

BTCPay Docker verfügt über mehrere Wallets, eine Shop Wallet, welches eine reine Onchain Wallet ist, und die Lightning Wallet auf der Lightning Node. Beide müssen separate wiederhergestellt werden.

Die Bitcoin Shop Wallet wiederherstellen

Um die Bitcoinn Shop Wallet wiederherzustellen, klickt einfach auf den Bitcoin Button links in der Menüspalte und klickt danach auf connect an exisiting Wallet

Auf der nächsten Seite habt Ihr die Möglichkeit, die Art der Wiederherstellung auszuwählen:

Habt ihr keine Wallet File, müsst ihr eure Wallet Adresse manuell eingeben. Macht das am besten auf einem frischen System bei dem ihr wisst, dass ihr womöglich keine bösartige Software oder Viren drauf habt. Ihr könnt die Guthaben natürlich auch auf einer Software Wallet wie Sparrow wiederherstellen. Diese könnt ihr dann auf ein frisch erstellte Wallet auf dem BTCPay Server senden.

LND Wallet von BTCPay Docker wiederherstellen

Die oben vorgestellte Backup Methode vom BTCPay Server stellt auch eure LND Wallet wieder her, solltet ihr also ein Backup erstellt haben, könnt ihr damit eure Wallet wiederherstellen. Falls ihr kein Backup habt, und nur eure 24 Wörter für die LND Wallet, folgt dem folgendem Leitfaden:

Das Wiederherstellen der Lightning Wallet beim reinem BTC-Pay Server ist etwas umständlich. Die Wiederherstellung der LND Wallet geschieht auf der Kommandozeile.

Der anfängliche Ausgangspunkt, um die Wiederherstellung von On-Chain-Geldern über die Kommandozeile auszulösen, ist der Befehl lncli create. Dieser funktioniert auf dem BTCPay Server etwas anders. Zuerst müsst ihr den Stack komplett herunterfahren indem ihr auf der Kommandozeile folgenden Befehl ausführt:

btcpay-down.sh

Danach müsst ihr den Unlockscript von BTCPay kurz deaktivieren, indem ihr folgendermassen vorgeht:

Sucht zuerst den docker-initunlocklnd.sh Script mit dem folgendem Befehl:

find /var/lib/docker/overlay2/ -name "docker-initunlocklnd.sh" 2>/dev/null

Kopiert euch dem Pfad der den Ordner merged beeinhaltet:

Ändert den namen des docker-initunlocklnd.sh Scripts kurzfristig ab:

mv /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh.bak

Löscht den kompletten Inhalt des LND Ordners auf dem BTCPay Server:

rm -r /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/*

Startet den BTCPay Server mit:

btcpay-up.sh

Führt den folgenden Befehl aus:

docker exec -it btcpayserver_lnd_bitcoin lncli --tlscertpath /root/.lnd/tls.cert.tmp create

Jetzt kommt ihr in den interaktiven Modus um die Wallet wiederherzustellen. Als Nächstes kann man ein neues Wallet-Passwort eingeben, um alle neu abgeleiteten Schlüssel als Ergebnis des Wiederherstellungsprozesses zu verschlüsseln. Diesen Schritt könnt ihr mit Enter überspringen.

Input wallet password:
Confirm wallet password:

ACHTUNG, das Walletpasswort auf dem BTCPAY Server muss hellorockstar sein! Verwendet hier also hellorockstar als Wallet Passwort!

Sobald ein neues Wallet-Passwort erstellt wurde, werdet ihr aufgefordert, die vorhandenen Chiffrierschlüssel (Cipher Seed) einzugeben:

Input your 24-word mnemonic separated by spaces: ability noise lift document certain month shoot perfect matrix mango excess turkey river pitch fluid rack drill text buddy pool soul fatal ship jelly

Wenn beim Erstellen des Seeds ein Passwort für den Chiffrierschlüssel verwendet wurde, MUSS es jetzt eingegeben werden, das ist auf dem BTCPAY Server beim Standardsetup aber nicht der Fall, also ENTER:

Input your cipher seed passphrase (press enter if your seed doesn't have a passphrase):

Schließlich habt ihr die Möglichkeit, ein Wiederherstellungsfenster zu wählen:

Input an optional address look-ahead used to scan for used keys (default 2500):2500

Das Wiederherstellungsfenster ist ein Maß, das der On-Chain-Scanner verwendet, um zu bestimmen, wann alle "benutzten" Adressen gefunden wurden. Wenn das Wiederherstellungsfenster zu niedrig ist, wird LND keine Gelder in Adressen finden, die nach dem Punkt erzeugt wurden, an dem zwei aufeinanderfolgende Adressen generiert, aber nie verwendet wurden. Wurde eine LND On-Chain-Wallet umfangreich genutzt, möchtet ihr möglicherweise den Standardwert erhöhen.

Sollten alle bereitgestellten Informationen gültig sein, wird euch der Seed erneut präsentiert:

!!!YOU MUST WRITE DOWN THIS SEED TO BE ABLE TO RESTORE THE WALLET!!!

---------------BEGIN LND CIPHER SEED---------------
 1. ability   2. noise   3. lift     4. document
 5. certain   6. month   7. shoot    8. perfect
 9. matrix   10. mango  11. excess  12. turkey
13. river    14. pitch  15. fluid   16. rack
17. drill    18. text   19. buddy   20. pool
21. soul     22. fatal  23. ship    24. jelly
---------------END LND CIPHER SEED-----------------

!!!YOU MUST WRITE DOWN THIS SEED TO BE ABLE TO RESTORE THE WALLET!!!

lnd successfully initialized!

Ist die Wiederherstellung durch, muss der docker-initunlocklnd.sh Script wieder unbenannt werden:

mv /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh.bak /var/lib/docker/overlay2/0aa693d5ccdd43768d11c7bf053a9eb3068d3ebc3fb330a20f604d94b90903fa/merged/docker-initunlocklnd.sh

Startet den BTCPay Server neu mit:

btcpay-restart.sh

Danach habt ihr eure Onchain Funds der LND Wallet erfolgreich auf dem BTCPay Server wiederhergestellt. Wie hier die Kanäle wiederherstellt erfahrt ihr weiter unten.

Raspiblitz Fullnode

Der Raspiblitz hat nur eine LND Wallet mit Onchain Funds. Deshalb gehts gleich weiter, wie die LND Wallet wieder hergestellt werden kann. Vorausetzung dafür ist ein frisch installiertes Blitzimage, und ein synchronisierter Bitcoincore Client. Die Node muss also vollständig synchronisiert sein, damit die Funds wieder auftauchen.

LND Onchain Wallet wiederherstellen

Achtung: diese Option ist nur auszuwählen, falls ihr keine Kanäle hattet! Weiter unten findet ihr die Anleitung um Kanäle wiederherzustellen. Das Raspiblitzmenu bietet im Menu eine extra Option an, um nur die Onchain Funds der LND Wallet wiederherzustellen. Loggt euch per SSH auf dem wiederhergestellten RaspiBlitz ein und begebt euch mit dem Befehl menu ins CLI Menü des Blitzes, dort wählt ihr dann Repair Options und danach Repair/Backup LND:

Im nächsten Fenster wählt Ihr dann Restore from a seed (onchain funds only)

Im nächsten Fenster fragt euch der Blitz ob ihr LND vorher sichern wollt, da ihr neu aufgesetzt habt, müsst ihr nichts sichern, könnt also einfach mit <skip> fortfahren. Anschliessend startet der Blitz die entsprechende Konfiguration. Ihr könnt dann in den folgenden Schritten euren alten LND Azeed eingeben. Folgt einfach den Anweisungen.

Offchain Guthaben oder Lightning Kanäle sichern

Wir kommen nun zu dem Teil des Tutorials, der euch zeigt, wie ihr eure Kanäle mit der wichtigen, euch nun bereits bekannten SCB Datei channel.backup, sichert.

Die SCB-Datei in LND (Lightning Network Daemon) steht für "Static Channel Backup". Sie ist quasi die Lebensversicherung bei einem Totalausfall des Lightning Knotens. Die grösste Konzentration liegt darauf, dass diese Datei unter allen Umständen regelmässig gesichert werden muss.

Hier wichtige Details zur SCB-Datei:

1. Zweck der SCB-Datei: Die SCB-Datei ist dazu gedacht, Informationen über eure Lightning-Kanäle zu speichern, allerdings in einer statischen Form. Das bedeutet, sie speichert die grundlegenden Infos zu den Kanälen, wie die Kanal-IDs und die Knoten, mit denen ihr verbunden seid.
2. Nutzung im Notfall: Die Hauptfunktion der SCB-Datei ist die Wiederherstellung eurer Kanäle im Falle eines Totalausfalls eures Knotens, wie z.B. bei einem Hardwarefehler oder Datenverlust. Wenn ihr also einen neue LND Node aufsetzt, könnt ihr die SCB-Datei verwenden, um eure Kanäle wiederherzustellen.
3. Limitationen: Es ist wichtig zu verstehen, dass die SCB-Datei nicht dazu dient, Kanäle "am Leben zu erhalten" oder den aktuellen Zustand eurer Kanäle zu sichern. Sie hilft nur bei der Wiederherstellung der Existenz der Kanäle, nicht aber bei der Wiederherstellung des Kanalzustandes oder der Transaktionshistorie. Nach der Verwendung der SCB Datei, werden also alle ehemaligen Kanäle zwangsgeschlossen, und ihr bekommt eure Lightning Guthaben nach eineriger Zeit zurück. Das heißt, sie ist eine Art Sicherheitsnetz, aber keine umfassende Backup-Lösung.
4. Vorsichtsmaßnahmen: Es ist entscheidend, dass ihr die SCB-Datei sicher und getrennt von eurem Knoten aufbewahrt. Sollte jemand unbefugt Zugriff darauf erhalten, könnte dies ein Sicherheitsrisiko darstellen. Zusammen mit dem Seed kann eurer gesammtes Lightning Guthaben abgegriffen werden.

Zusammenfassend ist die SCB-Datei in LND also das wichtigste Werkzeug für die Notfallwiederherstellung eurer Lightning-Kanäle bei einem Ausfall eurer Node. Sie ist jedoch kein Allheilmittel und kann nicht den laufenden Betrieb oder den aktuellen Zustand Eurer Kanäle sichern. Es ist also wichtig, zusätzlich zu den SCB-Backups auch andere Vorsichtsmaßnahmen zu treffen, um die Sicherheit eurer Lightning-Kanäle zu gewährleisten.

Umbrel SCB Datei sichern

die SCB Datei findet ihr auf der Umbrel Lightning Node oben rechts unter den 3 Strichen:

Die Datei könnt ihr direkt downloaden und an einem Ort eurer Wahl speichern. Eine Automatische Sicherung gibt es nicht, wie die Einstellung Automatic backups suggeriert! Zumindest finde ich nirgends eine Option aus einem Online Backup von Umbrel wiederherzustellen.

BTCPay Server Docker SCB Datei sichern

Auf dem BTCPay Server gibt es keine automatische SCB Backup Funktion, deshab machen wir uns einen eigenen Script, der die channel.backup regelmässig bei Änderungen sichert, ähnlich bzw gleich der SCB Backup Funktion des Blitzes.

LND backup script für die channel.backup mit inotify

Installiert euch zuerst das Tool inotify auf dem Host.

sudo apt install inotify-tools

Skript erstellen

Erstellt einen Script der die channel.backup Datei überwacht mit nano /pfad/copy-channel-backup-on-change.sh mit folgendem Inhalt:

#!/bin/bash

# Pfade und Einstellungen
SOURCE_FILE="/var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/chain/bitcoin/mainnet/channel.backup"
BACKUP_PATH="/backuppfad/channel.backup"
DELAY=10  # Verzögerung in Sekunden nach Erkennung von Änderungen

while true; do
    # Warte auf eine Änderung (modify) an der Datei
    inotifywait -e modify $SOURCE_FILE
    
    # Warte nach der Erkennung einer Änderung
    echo "$(date): Modification detected. Waiting for $DELAY seconds before copying..."
    sleep $DELAY

    # Kopiere die Datei zum Backup-Pfad
    cp $SOURCE_FILE $BACKUP_PATH

    echo "$(date): File copied to $BACKUP_PATH"
done

Bitte passt den BACKUP_PATH an einen enstsprechenden Pfad an (z.B an einen gemounteten USB Stick oder einen Netzwerkspeicher)

Macht die Datei ausführbar mit:

chmod +x /pfad/copy-channel-backup-on-change.sh

als Service hinzufügen

Erstellt eine neue Service Datei mit sudo nano /etc/systemd/system/backup-channels.service mit folgenden Inhalt:

[Service] 
ExecStart=/pfad/copy-channel-backup-on-change.sh 
Restart=always 
RestartSec=1 
StandardOutput=syslog 
StandardError=syslog 
SyslogIdentifier=backup-channels 
User=ubuntu 
Group=ubuntu 
[Install] 
WantedBy=multi-user.target

Den Dienst startet ihr mit:

sudo systemctl start backup-channels

Überwachen könnt ihr in mit:

journalctl -fu backup-channels

Beim booten des Servers den Service automatisch mit starten:

sudo systemctl enable backup-channels

rsync backup mit crontab

Eine einfache Variante ist auch das sichern dern SCB Datei mit einem einfach rsync cronjob. Dafür braucht ihr keine Scripte und keinen extra Service, ist aber nicht ganz so sauber wie die inotify methode.

Erstellt einen crontab mit sudo crontab -e mit folgendem Inhalt:

15 * * * * rsync -avz /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/chain/bitcoin/mainnet/channel.backup /mnt/usbstick/

Damit wird die SCB Datei alle 15 Minuten auf den Stick gesichert. Ihr könnt natürlich auch das besagte NFS Share benutzen oder einen externen ftp/sftp Host verwenden.

Raspiblitz SCB Datei sichern

Lokale Sicherung

Für den Raspiblitz gibt es eine automtische Backup Funktion der SCB Datei (channel.backup) unter Funktion im Raspiblitz Menu. Dies findet ihr unter Node Settings & Options:

Hier könnt ihr die SCB über auf ein USB Speicher speichern. Habt ihr eine Nextcloud, wäre dies natürlich auch eine Option.

Ihr könnt einen UBS Stick an der Node lassen, oder auf einen nfs Share sichern, zb. einem Netzwerkspeicher. Wie sowas funktioniert, erfahrt ihr z.B hier. Der Raspi oder der ist dann einfach der NFS Client. Am einfachsten wäre aber für den Heimgebrauch die USB Stick Methode die an einen entsprechenden Ort gemountet wird.

Ihr müsste dafür ein USB Stick an euren Raspiblitz anstecken, welcher als Speicherort für das Backup dient. Nach der Ausführung des Dienstes SCB/Emergency Backup führt der Blitz die Sicherung regelmässig bei der Änderung der SCB Datei durch.

Fügt den Stick nach Ausführung des SCB/Emergency Backup tools noch unbedingt in die Datei fstab mit ein, damit der Stick automatisch beim erneuten starten der Node, an den richtigen Ort gemounted wird. Schaut mit lsblk, nach dem ausführen des Services bitte nach, wo der Stick gemounted wurde ist. Der Stick muss in der Datei fstab unter /mnt/backup gemounted werden. Benutzt dazu am besten die UUID. Wie das funktioniert, erfahrt ihr am Ende des nächsten Abschnittes.

Der nächste Abschnitt aktiviert die Auto Backup Funktion über die Kommandozeile, und fügt den Stick mit in die Datei /etc/fstab mit hinzu:

Manuelle Konfiguration Auto-SCB Backup

Für die manuelle Konfiguration des Autobackup der SCB Datei via USB Stick, geht ihr am besten so vor:

Stick am PI einstecken

Am Blitz via SSH anmelden und mit CTRL+C auf die Shell wechseln.
Prüfen, ob er einen verwendbaren Stick erkannt hat:

sudo ./config.scripts/blitz.backupdevice.sh status

ungefähre Ausgabe wäre

blitz.backupdevice.sh
backupdevice=0
backupCandidate[0]='sdb 7 GB JetFlash'
backupCandidates=1

Backup aktivieren:

sudo ./config.scripts/blitz.backupdevice.sh on

Im erscheinenden Dialog FORMAT wählen

Prüfen, ob der Stick unter /mnt/backup eingehengt wurden ist: