Bitcoin Lightning oder On-Chain: Gebühren, Bestätigung und Kanäle

Beide Wege übertragen Werte in Bitcoin, verwenden die Basisschicht aber unterschiedlich. Eine On-Chain-Zahlung erzeugt eine Transaktion, die Bitcoin-Knoten weiterleiten und Miner in einen Block aufnehmen können. Eine Lightning-Zahlung läuft über eine Route aus Zahlungskanälen; sie wird nicht als eigene Bitcoin-Transaktion in die Blockchain geschrieben.

Das wirkt sich auf Gebühren, Verfügbarkeit, Privatsphäre und die Statusanzeige im Wallet aus. Lightning ist keine andere Münze. „Off-Chain“ bedeutet auch nicht, dass eine Zahlung ohne Regeln oder Risiken abläuft. Die Kanalteilnehmer verwenden Bitcoin-Transaktionen, um den Kanal einzurichten und Guthaben bei Bedarf abzurechnen.

Ein Wallet wählt verfügbare Ausgaben, erstellt und signiert eine Transaktion und sendet sie an Bitcoin-Knoten. Knoten können die Transaktion weiterleiten und in ihren jeweiligen Mempools halten, bis ein Miner sie in einen Block aufnimmt. Die Netzwerkgebühr hängt von Transaktionsgröße und Gebührensatz ab, nicht einfach vom gesendeten Bitcoin-Betrag. Der Bitcoin Developer Guide zur Zahlungsabwicklung beschreibt den Ablauf.

Mit einer Transaktions-ID lässt sich die gesendete Transaktion prüfen; das allein bedeutet noch keine Bestätigung. Eine Bestätigung heißt, dass ein Block die Transaktion enthält. Weitere Blöcke erhöhen die Zahl der Bestätigungen. Wie viele der Empfänger abwartet, richtet sich nach seinem Dienst oder seiner Risikoeinschätzung. Weder Blockzeit noch Bestätigungsziel versprechen, dass das Geld zu einer bestimmten Minute verfügbar ist.

Der Empfänger kann eine Lightning-Rechnung mit Zahlungsanfrage, Betrag, Ziel, Beschreibung und Ablaufzeit bereitstellen. Das Wallet des Zahlers liest sie und sucht eine Route mit passender Kanalkapazität und zulässigen Limits. Die BOLT-11-Spezifikation für Rechnungen beschreibt die Felder; BOLT 7 behandelt Kanalankündigungen und Routing-Updates.

Weitergeleitete Zahlungen verwenden bedingte Übertragungen, die oft als Hash Time-Locked Contracts (HTLCs) beschrieben werden. Jeder Zwischenknoten erhält Betrag und Zeitbedingungen für den nächsten Abschnitt; der Empfänger gibt das Geheimnis frei, das die Zahlung abschließt. Eine gültige Rechnung kann trotzdem scheitern, wenn in einer Richtung Liquidität fehlt, ein Update veraltet ist, ein Limit erreicht wird oder ein Knoten nicht verfügbar ist. Eine erfolgreiche Zahlung muss nicht auf einen neuen Block warten, aber jede Lightning-Rechnung ist damit nicht garantiert erfolgreich.

Ein Zahlungskanal beginnt mit einer On-Chain-Funding-Transaktion und hat eine Gesamtkapazität. Bei Zahlungen zwischen den Teilnehmern verschiebt sich der aktuelle Saldo, ohne jede einzelne Zahlung als Bitcoin-Transaktion zu veröffentlichen. Was eine Seite gerade senden kann, hängt vom Guthaben in dieser Richtung, Reserven, Zahlungslimits und der gewählten Route ab. Das BOLT-2-Peer-Protokoll erläutert Kanalparameter und HTLC-Limits.

Ein Kanal mit ausreichender Gesamtkapazität kann trotzdem zu wenig ausgehende Liquidität für eine bestimmte Zahlung haben. Auch dem Empfänger kann ein nutzbarer eingehender Pfad für diesen Betrag fehlen. Das Öffnen, Verschieben von Liquidität oder Schließen eines Kanals kann On-Chain-Transaktionen und Gebühren erfordern. BOLT 5 zur On-Chain-Abwicklung beschreibt gemeinsames und einseitiges Schließen. Die Abbildung trennt wiederholte Kanalzahlungen von Funding und Schließen auf Bitcoin.

Eine On-Chain-Gebühr bezahlt Blockplatz. Der Gesamtbetrag hängt von der Transaktionsgröße und dem für die aktuellen Bedingungen gewählten Gebührensatz ab. Eine größere Transaktion kann mehr kosten, obwohl sie weniger Bitcoin sendet. Eine Schätzung des Wallets ist eine Momentaufnahme, keine Reservierung in einem künftigen Block.

Weiterleitungsgebühren bei Lightning werden von Kanalbetreibern festgelegt und können aus einem Grundbetrag und einem proportionalen Betrag bestehen. Routenlänge, Kanalregeln, Liquidität und Wallet-Verhalten beeinflussen die Kosten. Manche Wallets können zusätzlich eigene Gebühren oder Liquiditätskosten anzeigen. Lightning kann in einem bestimmten Fall günstiger sein, ist aber nicht immer kostenlos oder billiger als On-Chain. Prüfe vor der Freigabe den Endbetrag, die Gebühren und die Routenanforderungen.

Ein On-Chain-Wallet kann Status wie gesendet, ausstehend oder bestätigt anzeigen. Transaktionen und Blöcke sind in der Blockchain öffentlich abrufbar; der Empfänger kann eine zur Situation passende Bestätigungsschwelle festlegen. Eine Transaktion kann länger als erwartet unbestätigt bleiben. Eine Gebührenschätzung bestimmt nicht, was Miner auswählen.

Bei Lightning gilt die Rechnung als bezahlt, wenn die Route abgeschlossen ist und das Wallet eine Erfolgsmeldung erhält. Diese einzelne Zahlung wird nicht jeweils in einem Bitcoin-Block bestätigt. Ein fehlgeschlagener Versuch ist keine Bestätigung. Wenn der Status unklar ist, beweist das nicht, dass eine zweite Zahlung sicher ist. Prüfe vor einem erneuten Versuch den endgültigen Status des sendenden Wallets und die Rechnung oder Quittung des Empfängers.

On-Chain-Daten sind öffentlich und analysierbar, auch wenn eine Adresse nicht automatisch den Namen einer Person verrät. Lightning-Onion-Routing soll begrenzen, was ein weiterleitender Knoten über die gesamte Route erfährt; es macht Zahlungen aber nicht vollständig anonym. Die BOLT-4-Spezifikation zum Onion-Routing und öffentliche Kanal-Updates in BOLT 7 beschreiben Teile dieses Modells.

Wallets unterscheiden sich darin, wer Schlüssel kontrolliert und wie Kanäle überwacht, gesichert und wiederhergestellt werden. Ein selbstverwahrtes Wallet und ein verwahrtes Lightning-Konto haben unterschiedliche Aufgaben und Ausfallrisiken. Internetzugang, Erreichbarkeit von Peers, Kanalzustand, Wiederherstellung und Anbieterbedingungen können wichtig sein. Der Begriff „Lightning“ sagt allein nichts über Verwahrung oder Backup-Schutz aus.

On-Chain kann passen, wenn der Empfänger eine Bitcoin-Adresse bereitstellt und eine in der Blockchain prüfbare Transaktion benötigt. Lightning kann bei einer kompatiblen Rechnung und verfügbarer Routenliquidität passen. Wiederholte kleinere Zahlungen können einen bestehenden Kanal nutzen; Eröffnung, Betrieb und Schließung haben aber eigene Kosten und Grenzen.

Prüfe Zahlungsart, Netzwerk, Betrag, Ablaufzeit der Rechnung, Empfänger, angezeigte Gebühr und Limits. Füge eine Lightning-Rechnung nicht in ein On-Chain-Adressfeld ein und nutze nicht einen Weg, den der Empfänger nicht angefordert hat. Einen On-Chain-Fallback solltest du nur verwenden, wenn Rechnung und Wallet ihn ausdrücklich unterstützen. Weiterführend: Bitcoin-Transaktionsgebühren, Einzahlungsbestätigungen und Krypto-Transfer-Checkliste.

Technische Primärquellen: Bitcoin Developer Guide: Zahlungsabwicklung; BOLT 2: Peer-Protokoll; BOLT 4: Onion-Routing; BOLT 5: On-Chain-Transaktionen; BOLT 7: Routing-Gossip; BOLT 11: Rechnungsformat.