Einführung in das Lightning Netzwerk E-Book

Andreas M. Antonopoulos

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Serie: Animals
• Sprache: Deutsch
• Veröffentlichungsjahr: 2023

Seitenzahl: 618

Beschreibung

Lightning-Netwerk als schnell wachsendes Second-Layer-Protokoll für Bitcoin-Zahlungen verstehen

• von international anerkannten Experten verfasstes Grundlagenwerk
• zu einer Technologie, die das kritische Problem der Skalierung von Bitcoin zu lösen verspricht
• für Entwickler, Systemarchitekten, Investoren, Unternehmen und alle, die sich für Krypto-Währungen interessieren

Das Lightning-Netzwerk (LN) ist ein schnell wachsendes Second-Layer-Zahlungsprotokoll, das auf Bitcoin aufsetzt, um nahezu sofortige Transaktionen zwischen zwei Parteien zu ermöglichen. In diesem Praxisbuch erklären die Autoren Andreas M. Antonopoulos, Olaoluwa Osuntokun und René Pickhardt, wie diese Weiterentwicklung die nächste Stufe der Skalierung von Bitcoin ermöglicht, die Geschwindigkeit und den Datenschutz erhöht und gleichzeitig die Gebühren reduziert.
Dieses Buch ist ideal für Entwickler, Systemarchitekten, Investoren und Unternehmer, die ein besseres Verständnis von LN anstreben. Es zeigt, warum Expertinnen und Experten LN als entscheidende Lösung für das Skalierbarkeitsproblem von Bitcoin sehen. Nach der Lektüre werden Sie verstehen, warum LN in der Lage ist, weit mehr Transaktionen zu verarbeiten als die heutigen Finanznetzwerke.

Leseprobe

Copyright und Urheberrechte:

Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Einführung in das Lightning-Netzwerk

Das Second-Layer-Blockchain-Protokoll für effiziente Bitcoin-Zahlungen verstehen und nutzen

Andreas M. Antonopoulos, Olaoluwa Osuntokun und René Pickhardt

Deutsche Übersetzung vonPeter Klicman

Andreas M. Antonopoulos, Olaoluwa Osuntokun, René Pickhardt

Lektorat: Ariane Hesse

Übersetzung: Peter Klicman

Fachliche Unterstützung: René Pickhardt

Korrektorat: Sibylle Feldmann, www.richtiger-text.de

Satz: Jörg Liedtke, Flensburg

Herstellung: Stefanie Weidner

Umschlaggestaltung: Michael Oréal, www.oreal.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-96009-201-8

PDF

978-3-96010-736-1

ePub

978-3-96010-737-8

mobi

978-3-96010-738-5

1. Auflage 2023

Translation Copyright © 2023 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«.O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

Authorized German translation of the English edition of Mastering the Lightning Network ISBN 9781492054863 © 2022 aantonop Books LLC, René Pickhardt, and uuddlrlrbas LLC. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen.

5 4 3 2 1 0

Inhalt

Vorwort

Vorwort zur deutschen Ausgabe

Teil IDas Lightning-Netzwerk verstehen

1Einführung

Grundlegende Konzepte des Lightning-Netzwerks

Vertrauen in dezentralisierten Netzwerken

Fairness ohne zentrale Autorität

Vertrauenswürdige Protokolle ohne Intermediäre

Ein Fairness-Protokoll in Aktion

Sicherheits-Primitive als Grundbausteine

Beispiel für Fairness-Protokolle

Motivation für das Lightning-Netzwerk

Blockchains skalieren

Die das Lightning-Netzwerk definierenden Eigenschaften

Anwendungsfälle, Nutzer und ihre Geschichten

Fazit

2Erste Schritte

Alice’ erste Lightning-Wallet

Lightning-Nodes

Lightning-Explorer

Lightning-Wallets

Testnet-Bitcoin

Balance zwischen Komplexität und Kontrolle

Download und Installation einer Lightning-Wallet

Eine neue Wallet anlegen

Verantwortung für die Schlüsselverwahrung

Mnemonische Wörter

Die mnemonische Phrase sichern

Bitcoin auf die Wallet laden

Bitcoin beschaffen

Bitcoin empfangen

Von Bitcoin zum Lightning-Netzwerk

Lightning-Netzwerk-Kanäle

Einen Lightning-Kanal öffnen

Eine Tasse Kaffee über das Lightning-Netzwerk kaufen

Bobs Café

Eine Lightning-Rechnung

Fazit

3Wie das Lightning-Netzwerk funktioniert

Was ist ein Zahlungskanal?

Grundlagen eines Zahlungskanals

Zahlungen über Kanäle routen

Zahlungskanäle

Multisignaturadressen

Funding-Transaktion

Commitment-Transaktionen

Betrug mit vorherigem Zustand

Ankündigung des Kanals

Den Kanal schließen

Rechnungen

Zahlungshash und Preimage

Zusätzliche Metadaten

Zustellung der Zahlung

Das Peer-to-Peer-Gossip-Protokoll

Wegfindung und Routing

Quellbasierte Wegfindung

Onion-Routing

Algorithmus zur Zahlungsweiterleitung

Verschlüsselung der Peer-to-Peer-Kommunikation

Überlegungen zum Vertrauen

Vergleich mit Bitcoin

Adressen versus Rechnungen, Transaktionen versus Zahlungen

Outputs wählen versus Pfad finden

Change-Output bei Bitcoin versus kein Wechselgeld bei Lightning

Mining-Gebühren versus Routing-Gebühren

Gebühren basierend auf Traffic versus angekündigte Gebühren

Öffentliche Bitcoin-Transaktionen versus private Lightning-Zahlungen

Warten auf Bestätigungen versus sofortiger Zahlungseingang

Senden beliebiger Summen versus Kapazitätsbeschränkungen

Anreize für Großbeträge versus Kleinbeträge

Blockchain als Kassenbuch versus Blockchain als Gerichtssystem

Offline versus online, asynchron versus synchron

Satoshis versus Millisatoshis

Gemeinsamkeiten von Bitcoin und Lightning

Monetäre Einheit

Unumkehrbarkeit und Finalität von Zahlungen

Vertrauen und Gegenparteirisiko

Genehmigungsfreier Betrieb

Open Source und Open System

Fazit

4Lightning-Node-Software

Die Lightning-Entwicklungsumgebung

Die Kommandozeile nutzen

Das Buch-Repository herunterladen

Docker-Container

Bitcoin Core und Regtest

Den Bitcoin-Core-Container erzeugen

Das c-lightning-Lightning-Node-Projekt

c-lightning als Docker-Container

Ein Docker-Netzwerk einrichten

Ausführen der bitcoind- und c-lightning-Container

c-lightning aus dem Quellcode installieren

Vorab benötigte Bibliotheken und Pakete installieren

Den c-lightning-Quellcode kopieren

Den c-lightning-Quellcode kompilieren

Das Lightning-Netzwerk-Daemon-Node-Projekt

Der LND-Docker-Container

Die bitcoind- und LND-Container ausführen

LND aus dem Quellcode installieren

Den LND-Quellcode kopieren

Den LND-Quellcode kompilieren

Das Eclair-Lightning-Node-Projekt

Der Eclair-Docker-Container

Die bitcoind- und Eclair-Container ausführen

Eclair aus dem Quellcode installieren

Den Eclair-Quellcode installieren

Den Eclair-Quellcode kompilieren

Ein Netzwerk diverser Lightning-Nodes aufbauen

docker-compose zur Orchestrierung von Docker-Containern nutzen

docker-compose-Konfiguration

Das Demo-Lightning-Netzwerk starten

Kanäle öffnen und eine Zahlung routen

Fazit

5Eine Lightning-Netzwerk-Node betreiben

Eine Plattform wählen

Warum ist Zuverlässigkeit für den Betrieb einer Lightning-Node wichtig?

Hardware für Lightning-Nodes

Betrieb in der Cloud

Eine Node zu Hause betreiben

Welche Hardware wird zum Betrieb einer Lightning-Node benötigt?

Serverkonfiguration in der Cloud wechseln

Einen Installer oder Helfer nutzen

RaspiBlitz

Mynode

Umbrel

BTCPay Server

Bitcoin-Node oder leichtgewichtige Lightning-Node

Wahl des Betriebssystems

Wahl der Lightning-Node-Implementierung

Eine Bitcoin- oder Lightning-Node installieren

Hintergrunddienste

Prozessisolation

Node starten

Node-Konfiguration

Netzwerkkonfiguration

Die Sicherheit Ihrer Node

Betriebssystemsicherheit

Node-Zugriff

Node- und Kanal-Backups

Hot-Wallet-Risiko

Sweeping von Guthaben

Uptime und Verfügbarkeit einer Lightning-Node

Fehler tolerieren und die Dinge automatisieren

Die Node-Verfügbarkeit überwachen

Watchtower

Kanalmanagement

Ausgehende Kanäle öffnen

Eingehende Liquidität beschaffen

Kanäle schließen

Kanäle wieder ausgleichen

Routing-Gebühren

Node-Management

Ride The Lightning

lndmon

ThunderHub

Fazit

Teil IIDas Lightning-Netzwerk im Detail

6Architektur des Lightning-Netzwerks

Die Lightning-Netzwerk-Protokoll-Suite

Lightning im Detail

7Zahlungskanäle

Eine andere Art, das Bitcoin-System zu nutzen

Bitcoin-Eigentümerschaft und -Kontrolle

Diversität der (unabhängigen) Eigentümerschaft und Multisig

Gemeinsamer Besitz ohne unabhängige Kontrolle

»Gesperrte« und nicht einzulösende Bitcoin verhindern

Einen Zahlungskanal aufbauen

Private und öffentliche Node-Schlüssel

Node-Netzwerkadresse

Node-Kennungen

Nodes als direkte Peers verbinden

Den Kanal aufbauen

Peer-Protokoll für das Kanalmanagement

Nachrichtenfluss beim Aufbau des Kanals

Die Funding-Transaktion

Eine Multisignaturadresse generieren

Die Funding-Transaktion konstruieren

Signierte Transaktionen halten, aber nicht veröffentlichen

Refunding vor Funding

Die vorsignierte Refund-Transaktion konstruieren

Transaktionen ohne Veröffentlichung verketten

(Ver-)Formbarkeit von Transaktionen (Segregated Witness)

Die Funding-Transaktion veröffentlichen

Zahlungen über den Kanal senden

Das Guthaben aufteilen

Konkurrierende Commitments

Mit alten Commitment-Transaktionen betrügen

Alte Commitment-Transaktionen widerrufen

Asymmetrische Commitment-Transaktionen

Verzögerte Auszahlung von to_self (Timelock)

Widerrufsschlüssel

Die Commitment-Transaktion

Den Kanalzustand verändern

Die commitment_signed-Nachricht

Die revoke_and_ack-Nachricht

Widerruf und neuer Commit

Betrug und Sanktionierung in der Praxis

Die Kanalreserve: das Spiel am Laufen halten

Den Kanal schließen (kooperatives Schließen)

Die shutdown-Nachricht

Die closing_signed-Nachricht

Die Kooperatives-Schließen-Transaktion

Fazit

8Routing in einem Netzwerk aus Zahlungskanälen

Routing einer Zahlung

Routing versus Wegfindung

Ein Netzwerk von Zahlungskanälen aufbauen

Ein reales Beispiel für das Routing

Fairness-Protokoll

Implementierung atomarer vertrauensfreier Multihop-Zahlungen

Ein erneuter Blick auf das Spenden-Beispiel

On-Chain- versus Off-Chain-Abwicklung von HTLCs

Hash Time-Locked Contracts

HTLCs in Bitcoin-Skript

Zahlungs-Preimage und Hashverifikation

HTLCs von Alice zu Dina propagieren

Rückpropagation des Secrets

Signaturbindung: Diebstahl von HTLCs verhindern

Hashoptimierung

Kooperations- und Timeout-Fehler

Kürzere Timelocks

Fazit

9Kanalbetrieb und Zahlungsweiterleitung

Lokal (einzelner Kanal) versus geroutet (mehrere Kanäle)

Zahlungen weiterleiten und Commitments aktualisieren mit HTLCs

Nachrichtenfluss für HTLC und Commitment

Zahlungen mit HTLCs weiterleiten

Einen HTLC hinzufügen

Die update_add_HTLC-Nachricht

HTLC in Commitment-Transaktionen

Neues Commitment mit HTLC-Output

Alice’ Commit

Bob bestätigt das neue Commitment und widerruft das alte

Bobs Commit

Mehrere HTLCs

Den HTLC einhalten

HTLC-Propagation

Dina erfüllt den HTLC mit Chan

Bob verrechnet den HTLC mit Alice

Einen HTLC aufgrund eines Fehlers oder Verfallsdatums entfernen

Eine lokale Zahlung vornehmen

Fazit

10Onion-Routing

Ein anschauliches Beispiel des Onion-Routings

Einen Pfad wählen

Die Schichten aufbauen

Die Schichten abschälen

Einführung in das Onion-Routing von HTLCs

Alice wählt den Pfad

Alice konstruiert die Nutzdaten

Schlüsselgenerierung

Die Onion-Schichten verpacken

Onions fester Länge

Die Onion verpacken (Zusammenfassung)

Dinas Hop-Nutzdaten verpacken

Chans Hop-Nutzdaten verpacken

Bobs Hop-Nutzdaten verpacken

Das finale Onion-Paket

Die Onion senden

Die update_add_htlc-Nachricht

Alice sendet die Onion an Bob

Bob überprüft die Onion

Bob generiert Füllbytes

Bob »entschleiert« seine Hop-Nutzdaten

Bob extrahiert den äußeren HMAC für den nächsten Hop

Bob entfernt seine Nutzdaten und verschiebt die Onion-Daten nach links

Bob konstruiert das neue Onion-Paket

Bob verifiziert die HTLC-Details

Bob sendet update_add_htlc an Chan

Chan leitet die Onion weiter

Dina empfängt die finalen Nutzdaten

Fehler zurückgeben

Fehlermeldungen

Spontane Zahlungen per keysend

Benutzerdefinierte Onion-TLV-Records

keysend-Zahlungen senden und empfangen

Keysend und benutzerdefinierte Records in Lightning-Anwendungen

Fazit

11Gossip und der Kanal-Graph

Peers entdecken

P2P-Bootstrapping

DNS-Bootstrapping

SRV-Query-Optionen

Der Kanal-Graph

Ein gerichteter Graph

Gossip-Protokoll-Nachrichten

Die node_announcement-Nachricht

Die channel_announcement-Nachricht

Die channel_update-Nachricht

Fortlaufende Pflege des Kanal-Graphen

Fazit

12Wegfindung und Zustellung der Zahlung

Wegfindung in der Lightning-Protokoll-Suite

Wo ist das BOLT?

Wegfindung: Welches Problem lösen wir?

Wahl des besten Pfads

Wegfindung in Mathematik und Informatik

Kapazität, Guthaben, Liquidität

Unsicherheit der Guthaben

Komplexität der Wegfindung

Die Dinge einfach halten

Wegfindung und Zahlungszustellung

Aufbau des Kanal-Graphen

Liquidität: Unsicherheit und Wahrscheinlichkeit

Gebühren und andere Kanalmetriken

Pfadkandidaten finden

Zustellung der Zahlung (Versuch-und-Irrtum-Schleife)

Erster Versuch (Pfad #1)

Zweiter Versuch (Pfad #4)

Multipart-Zahlungen

MPP nutzen

Versuch und Irrtum über mehrere »Runden«

Fazit

13Wire-Protokoll: Framing und Erweiterbarkeit

Messaging-Schicht in der Lightning-Protokoll-Suite

Wire-Framing

High-Level-Wire-Framing

Typcodierung

Type-Length-Value-Nachrichtenerweiterungen

Das Protocol-Buffers-Nachrichtenformat

Vor- und Rückwärtskompatibilität

Type-Length-Value-Format

BigSize-Integercodierung

Beschränkungen der TLV-Codierung

Kanonische TLV-Codierung

Feature-Bits und Erweiterbarkeit des Protokolls

Feature-Bits als Mechanismus zur Erkennung von Upgrades

TLV für Vor- und Rückwärtskompatibilität

Taxonomie des Upgrade-Mechanismus

Updates auf Ebene der Kanalkonstruktion

Fazit

14Lightnings verschlüsselter Nachrichtentransport

Verschlüsselter Transport in der Lightning-Protokoll-Suite

Einführung

Der Kanal-Graph als dezentralisierte Public-Key-Infrastruktur

Warum nicht TLS?

The Noise-Protokoll-Framework

Lightnings verschlüsselter Transport im Detail

Noise_XK: Noise-Handshake des Lightning-Netzwerks

Handshake-Notation und Protokollfluss

Übersicht auf hohem Niveau

Handshake in drei Akten

Fazit

15Lightning-Zahlungsanforderungen

Rechnungen in der Lightning-Protokoll-Suite

Einführung

Lightning-Rechnungen versus Bitcoin-Adressen

BOLT #11: Serialisierung und Interpretation von Lightning-Rechnungen

Rechnungscodierung in der Praxis

Das visuell lesbare Präfix

bech32 und das Datensegment

Fazit

16Sicherheit und Privatsphäre im Lightning-Netzwerk

Warum ist Privatsphäre wichtig?

Privatsphäre definieren

Evaluierung der Privatsphäre

Anonyme Menge

Privatsphäre: Unterschiede zwischen Lightning-Netzwerk und Bitcoin

Angriffe auf Lightning

Zahlungsbeträge beobachten

Sender und Empfänger verknüpfen

Kanalguthaben aufdecken (Probing)

Denial of Service

Commitment-Jamming

Einfrieren der Kanalliquidität

Schichtenübergreifende Deanonymisierung

Clustering von On-Chain-Bitcoin-Entitäten

Clustering von Off-Chain-Lightning-Nodes

Schichtenübergreifende Verknüpfung: Lightning-Nodes und Bitcoin-Entitäten

Lightning-Graph

Wie sieht der Lightning-Graph wirklich aus?

Zentralisierung im Lightning-Netzwerk

Ökonomische Anreize und Graph-Struktur

Praktischer Rat zum Schutz der Privatsphäre

Unangekündigte Kanäle

Routing-Erwägungen

Kanäle akzeptieren

Fazit

Quellenangaben und Literaturhinweise

17Fazit

Dezentralisierte und asynchrone Innovation

Innovationen im Bitcoin-Protokoll und bei Bitcoin-Skript

Innovationen des Lightning-Protokolls

TLV-Erweiterbarkeit

Konstruktion von Zahlungskanälen

Opt-in-Ende-zu-Ende-Features

Lightning-Anwendungen (LApps)

Auf die Plätze, fertig, los!

Anhang ABitcoin-Grundlagen

Anhang BDocker: Grundlegende Installation und Nutzung

Anhang CNachrichten des Wire-Protokolls

Anhang DQuellen und Lizenzinformationen

Glossar

Index

Vorwort

Das Lightning-Netzwerk (engl. Lightning Network, kurz auch LN) ist ein Second-Layer-Peer-to-Peer-Netzwerk, das es uns erlaubt, Bitcoin-Zahlungen »Off-Chain« abzuwickeln, d.h., ohne sie als Transaktionen auf der Bitcoin-Blockchain bestätigen zu müssen.

Das Lightning-Netzwerk bietet uns sichere, günstige, schnelle und deutlich vertraulichere Bitcoin-Zahlungen, und das auch bei sehr kleinen Beträgen.

Basierend auf der Idee von Zahlungskanälen, die erstmals von Bitcoin-Erfinder Satoshi Nakamoto vorgeschlagen wurden, ist das Lightning-Netzwerk ein geroutetes Netzwerk, bei dem Zahlungen über einen Pfad von Zahlungskanälen vom Sender zum Empfänger geleitet werden.

Die ursprüngliche Idee des Lightning-Netzwerks wurde 2015 in der wegweisenden Arbeit »The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments« von Joseph Poon und Thaddeus Dryja vorgeschlagen. Im Jahr 2017 lief im Internet ein Lightning-»Test«-Netzwerk, in dem unterschiedliche Gruppen kompatible Implementierungen entwickelten und einige Kompatibilitätsstandards festlegten. 2018 ging das Lightning-Netzwerk »live«, und die Zahlungen begannen zu fließen.

Im Jahr 2019 vereinbarten Andreas M. Antonopoulos, Olaoluwa Osuntokun und René Pickhardt, beim Schreiben dieses Buchs zusammenzuarbeiten. Wie es scheint, mit Erfolg!

Leserkreis

Dieses Buch richtet sich hauptsächlich an ein technisches Publikum, das die Grundlagen von Bitcoin und anderen Blockchains versteht.

Verwendete Konventionen

Im Buch folgen wir diesen typografischen Konventionen:

Kursivschrift

Wird für neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen verwendet.

Nichtproportionalschrift

Wird für Programmlistings verwendet. Im normalen Fließtext werden damit Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hervorgehoben.

Nichtproportionalschrift fett

Wird für Befehle oder andere Eingaben eingesetzt, die Sie wortwörtlich eingeben müssen.

Nichtproportionalschrift kursiv

Wird für Text verwendet, der durch benutzereigene oder durch den Kontext bestimmte Werte ersetzt wird.

Mit diesem Symbol wird ein Tipp oder ein Vorschlag angezeigt.

Mit diesem Symbol wird ein allgemeiner Hinweis angezeigt.

Mit diesem Symbol wird eine Warnung angezeigt.

Codebeispiele

Die Beispiele sind in Go, C++ und Python geschrieben und verwenden die Kommandozeilen unixoider Betriebssysteme. Alle Code-Snippets finden Sie im GitHub-Repository im code-Unterverzeichnis. Laden Sie den Buchcode herunter, probieren Sie die Codebeispiele aus und senden Sie Korrekturen an: GitHub (https://github.com/lnbook/lnbook).

Alle Code-Snippets können für die meisten Betriebssysteme mit einer minimalen Installation der Compiler, Interpreter und Bibliotheken für die entsprechenden Sprachen repliziert werden. Wenn nötig, stellen wir grundlegende Installationsanweisungen und schrittweise Beispiele für die Ausgaben bereit.

Einige der Code-Snippets wurden für den Druck aufbereitet. In diesen Fällen wurden die Zeilen mit einem Backslash-Zeichen (\) gefolgt von einem Newline-Zeichen getrennt. Wenn Sie mit diesen Beispielen arbeiten, müssen Sie die beiden Zeichen entfernen und die Zeilen wieder zusammenfassen. Die Ergebnisse sollten dann denen der Beispiele entsprechen.

Alle Code-Snippets verwenden wann immer möglich reale Werte und Berechnungen. Sie können sich also von Beispiel zu Beispiel vorarbeiten und kommen immer zu den gleichen Ergebnissen wie das Buch. So sind beispielsweise die privaten Schlüssel und die dazugehörigen öffentlichen Schlüssel und Adressen alle echt.

Verwendung der Codebeispiele

Bei technischen Fragen oder Problemen mit den Codebeispielen senden Sie bitte eine E-Mail an [email protected].

Dieses Buch ist dazu gedacht, Ihnen bei der Erledigung Ihrer Arbeit zu helfen. Im Allgemeinen dürfen Sie den Code in diesem Buch in Ihren eigenen Programmen oder Dokumentationen verwenden. Solange Sie den Code nicht in großem Umfang reproduzieren, brauchen Sie uns nicht um Erlaubnis zu bitten. Der Verkauf oder Vertrieb von Beispielen aus O’Reilly-Büchern ist dagegen genehmigungspflichtig. Signifikante Teile von Beispielcode aus diesem Buch für die eigene Produktdokumentation zu verwenden, ist genehmigungspflichtig.

Wir freuen uns über eine Quellenangabe, verlangen sie aber nicht unbedingt. Zu einer Quellenangabe gehören normalerweise Autor, Titel, Verlagsangabe, Veröffentlichungsjahr und ISBN, hier also: »Mastering the Lightning Network by Andreas M. Antonopoulos, Olaoluwa Osuntokun, and René Pickhardt (O’Reilly). Copyright 2022 aantonop Books LLC, René Pickhardt, and uuddlrlrbas LLC, ISBN 978-1-492-05486-3«.

Mastering the Lightning Network wird unter der Creative Commons Attribution-Noncommercial-No Derivative Works 4.0 International License (CC BY-NC-ND 4.0) angeboten.

Sollten Sie befürchten, dass Ihre Verwendung der Codebeispiele gegen das Fairnessprinzip oder die Genehmigungspflicht verstoßen könnte, nehmen Sie bitte unter [email protected] Kontakt mit uns auf.

Hinweise auf Unternehmen und Produkte

Alle Hinweise auf Unternehmen oder Produkte dienen der Information, Demonstration oder Referenz. Die Autoren unterstützen keines der genannten Unternehmen oder Produkte. Der Einsatz und die Sicherheit der in diesem Buch vorgestellten Produkte, Projekte oder Codefragmente wurden nicht getestet. Deren Nutzung erfolgt auf eigene Gefahr!

Adressen und Transaktionen in diesem Buch

Die Bitcoin-Adressen, Transaktionen, Schlüssel, QR-Codes und Blockchain-Daten in diesem Buch sind größtenteils echt. Sie können also die Blockchain durchgehen, sich die in den Beispielen enthaltenen Transaktionen genau ansehen und sie mit Ihren eigenen Skripten/Programmen abrufen.

Beachten Sie aber, dass die in diesem Buch zur Generierung von Adressen verwendeten privaten Schlüssel »verbrannt« wurden. Wenn Sie also Geld an diese Adressen senden, ist es für immer verloren, oder es kann von jedem abgeschöpft werden, der die hier abgedruckten privaten Schlüssel kennt.

Bitte senden Sie keinesfalls Geld an irgendeine der in diesem Buch verwendeten Adressen! Ihr Geld landet bei einem anderen Leser oder ist für immer verloren.

Andreas kontaktieren

Sie erreichen Andreas M. Antonopoulos über seine persönliche Website:

https://aantonop.com

Folgen Sie Andreas’ Kanal auf YouTube:

https://www.youtube.com/aantonop

Folgen Sie Andreas’ Seite auf Facebook:

https://www.facebook.com/AndreasMAntonopoulos

Folgen Sie Andreas auf Twitter:

https://twitter.com/aantonop

Folgen Sie Andreas auf LinkedIn:

https://linkedin.com/company/aantonop

Andreas möchte sich auch bei allen Förderern bedanken, die seine Arbeit durch monatliche Spenden unterstützen. Sie können Andreas auf Patreon unterstützen unter https://patreon.com/aantonop.

René kontaktieren

Sie erreichen René Pickhardt über seine persönliche Website:

https://ln.rene-pickhardt.de

Folgen Sie Renés Kanal auf YouTube:

https://www.youtube.com/user/RenePickhardt

Folgen Sie René auf Twitter:

https://twitter.com/renepickhardt

Folgen Sie René auf LinkedIn:

https://www.linkedin.com/in/rene-pickhardt-80313744

René möchte sich ebenfalls bei allen Förderern bedanken, die seine Arbeit durch eine monatliche Spende unterstützen. Sie können René auf Patreon unterstützen unter https://patreon.com/renepickhardt.

Sie können seine Arbeit aber auch direkt unter https://donate.ln.rene-pickhardt.de über das Lightning-Netzwerk in Bitcoin unterstützen. Dafür ist René ebenso dankbar wie seinen Förderern bei Patreon.

Olaoluwa Osuntokun kontaktieren

Sie erreichen Olaoluwa Osuntokun über seine berufliche E-Mail-Adresse:

[email protected]

Folgen Sie Olaoluwa auf Twitter:

https://twitter.com/roasbeef

Danksagungen von Andreas

Meine Liebe zu Wörtern und Büchern verdanke ich meiner Mutter Theresa, die mich in einem Haus aufzog, in dem Bücher jede Wand mit Beschlag belegten. Meine Mutter kaufte mir 1982 auch meinen ersten Computer, obwohl sie sich selbst als »technophob« beschrieb. Mein Vater Menelaos, ein Bauingenieur, der sein erstes Buch mit 80 veröffentlichte, lehrte mich logisches und analytisches Denken und weckte meine Leidenschaft zu Wissenschaft und Technik.

Ich danke euch allen für eure Unterstützung während meiner Reise.

Danksagungen von René

Ich möchte dem deutschen Bildungssystem danken, dem ich das Wissen verdanke, auf dem meine Arbeit aufbaut. Es ist eines der größten mir gemachten Geschenke. Ebenso möchte ich dem deutschen Gesundheitswesen danken und allen Menschen, die in diesem Bereich arbeiten. Ihr Einsatz und ihr Durchhaltevermögen machen sie zu meinen persönlichen Helden, und ich werde nie die Hilfe, Aufmerksamkeit und Unterstützung vergessen, die mir zuteilwurde, als ich sie benötigte. Mein Dank geht an all die Studenten, denen ich etwas lehren durfte und die sich in interessanten Diskussionen und Fragen engagierten. Von ihnen habe ich das meiste gelernt. Ich bin auch der Bitcoin- und Lightning-Netzwerk-Community dankbar, die mich freundlich willkommen hieß, sowie den Enthusiasten und Privatpersonen, die meine Arbeit finanziell unterstützten und das auch weiterhin tun. Ich danke ganz besonders allen Open-Source-Entwicklern (nicht nur Bitcoin und dem Lightning-Netzwerk) und den Menschen, die sie finanzieren, um diese Technik möglich zu machen. Ein besonderer Dank an meine Mitautoren, die den Weg mit mir gegangen sind. Und nicht zuletzt danke ich meinen Liebsten.

Danksagungen von Olaoluwa Osuntokun

Ich möchte dem großartigen Team von Lightning Labs danken, ohne die es kein LND gäbe. Ich möchte auch der ursprünglichen Gruppe von Autoren der BOLT-Spezifikation danken: Rusty Russell, Fabrice Drouin, Conner Fromnkchet, Pierre-Marie Padiou, Lisa Neigut und Christian Decker. Nicht zuletzt möchte ich Joseph Poon und Tadge Dryja danken, den Autoren des ursprünglichen Lightning-Netzwerk-Papers, ohne die es kein Lightning-Netzwerk gäbe, über das man ein Buch schreiben kann.

Beitragende

Viele Beitragende lieferten Kommentare, Korrekturen und Ergänzungen zu diesem Buch, als es gemeinschaftlich auf GitHub geschrieben wurde.

Nachfolgend eine alphabetisch sortierte Liste aller GitHub-Beitragenden mit deren GitHub-IDs in Klammern:

8go (@8go)

Aaqil Aziz (@batmanscode)

Alexander Gnip (@quantumcthulhu)

Alpha Q. Smith (@alpha_github_id)

Ben Skee (@benskee)

Brian L. McMichael (@brianmcmichael)

CandleHater (@CandleHater)

Daniel Gockel (@dancodery)

Dapeng Li (@luislee818)

Darius E. Parvin (@DariusParvin)

Doru Muntean (@chriton)

Eduardo Lima III (@elima-iii)

Emilio Norrmann (@enorrmann)

Francisco Calderón (@grunch)

Francisco Requena (@FrankyFFV)

François Degros (@fdegros)

Giovanni Zotta (@GiovanniZotta)

Gustavo Silva (@GustavoRSSilva)

Guy Thayakorn (@saguywalker)

Haoyu Lin (@HAOYUatHZ)

Hatim Boufnichel (@boufni95)

Imran Lorgat (@ImranLorgat)

Jeffrey McLarty (@jnmclarty)

John Davies (@tigeryant)

Julien Wendling (@trigger67)

Jussi Tiira (@juhi24)

Kory Newton (@korynewton)

Lawrence Webber (@lwebbz)

Luigi (@gin)

Maximilian Karasz (@mknoszlig)

Omega X. Last (@omega_github_id)

Owen Gunden (@ogunden)

Patrick Lemke (@PatrickLemke)

Paul Wackerow (@wackerow)

Randy McMillan (@RandyMcMillan)

René Köhnke (@rene78)

Ricardo Marques (@RicardoM17)

Sebastian Falbesoner (@theStack)

Sergei Tikhomirov (@s-tikhomirov)

Severin Alexander Bühler (@SeverinAlexB)

Simone Bovi (@SimoneBovi)

Srijan Bhushan (@srijanb)

Taylor Masterson (@tjmasterson)

Umar Bolatov (@bolatovumar)

Warren Wan (@wlwanpan)

Yibin Zhang (@z4y1b2)

Zachary Haddenham (@senf42)

Ohne die Hilfe der oben aufgeführten Personen wäre dieses Buch nicht möglich gewesen. Eure Beiträge demonstrieren die Kraft von Open Source und einer offenen Kultur, und wir sind euch unendlich dankbar.

Vielen Dank.

Quellen

Ein Teil des Materials in diesem Buch stammt aus unterschiedlichen Public-Domain- bzw. Open-License-Quellen. Für andere Teile wurden Genehmigungen erteilt. Details zu Quellen, Lizenzen und Quellenzuordnungen finden Sie in Anhang D.

Vorwort zur deutschen Ausgabe

Als Satoshi Nakamoto Bitcoin 2009 veröffentlichte, dauerte es nicht lange, bis sich eine kleine Gruppe technisch Begeisterter zusammenfand, um die Vor- und Nachteile des neuen Systems zu diskutieren und damit herumzuspielen. Ich gehöre selbst auch zu den Leuten, die eher zufällig auf Bitcoin gestoßen sind, aber seitdem ich Bitcoin entdeckt habe, lässt es mich nicht mehr los.

Das Ziel, das sich Satoshi gesetzt hatte, war, dass Bitcoin ein globales Wertetransfer-Netzwerk werden sollte, ohne Mittelsmänner. In diesem Netzwerk sollten Werte in Form von Bitcoins beliebig hin und her verschoben werden können. Das Ganze durch pseudonyme Adressen ergänzt, um die Privatsphäre der Teilnehmer zu schützen.

Anfangs waren es noch wenige, die eher aus technischem Interesse mitmachten, denn damals wurden Bitcoins noch kein Wert zugeschrieben. Bereits zu diesem Zeitpunkt war aber schon klar, dass, sollte Bitcoin erfolgreich sein, wir schnell an die Grenzen des damaligen Systems stoßen würden. Deshalb mussten neue Ideen her.

Die wahrscheinlich schwierigste Frage war, wie Bitcoin denn skalieren könnte. Wie sollte Bitcoin sich also bei steigender Nachfrage anpassen, um allen Menschen die Möglichkeit zu geben, Bitcoin zu nutzen. Das Problem dabei war nämlich, dass die Blockchain, die von Satoshi für Bitcoin erfundene Technologie, ein geteiltes Medium darstellt, allerdings mit begrenzter Kapazität für das Bearbeiten von Transaktionen. Diese Frage stellten wir uns schon sehr früh, und 2012 war mir klar, dass ich meine Forschung im Rahmen meines Doktorats diesem Thema widmen würde.

Eine potenzielle Lösung waren sogenannte Micropayment Channels. Bei Micropayment Channels, auch Off-Chain-Protokolle genannt, handelt es sich um Systeme, die auf einer Blockchain aufbauen, um deren Nutzen zu erweitern. Bei Off-Chain-Protokollen werden Änderungen nicht mehr dem gesamten Netzwerk mitgeteilt, sondern zunächst nur den Teilnehmern, die an einer Transaktion beteiligt sind. Das gesamte Netzwerk wird erst später informiert. Die Saldierung aller stattfindenden Off-Chain-Transfers hat den Vorteil, dass am Ende nur eine einzige Transaktion bestätigt werden muss. Und da für diese Bestätigung immer On-Chain-Gebühren anfallen, ist es viel kostengünstiger, wenn eine On-Chain-Gebühr auf beliebig viele Off-Chain-Transfers verteilt werden kann.

Was anfangs noch sehr abstrakt war, wurde durch Experimente in dieser Richtung immer konkreter: angefangen mit den einfachen unidirektionalen Channels von Matt Corallo und Jeremy Spillmann bis hin zu dem Lightning Network Paper von Joseph Poon und Tadge Dryja.

Als Joseph und Tadge 2015 das Lightning Network Paper publizierten, stieß es auf großes Interesse, gerade bei denjenigen von uns, denen der Mangel einer plausiblen Lösung für die Skalierung von Bitcoin unter den Nägeln brannte. Aber Skalierbarkeit sollte nicht der einzige Vorteil des Lightning Network sein, hinzu kommt auch, dass es in Echtzeit Zahlungen ermöglicht und die Privatsphäre potenziell besser schützen kann, weil nicht mehr alles bis in alle Ewigkeit auf der Blockchain gespeichert wird.

Doch die Vorteile brachten wiederum einiges an Komplexität und neuen Konzepten mit sich, die die Nutzer der Technologie erst einmal kennenlernen und verstehen müssen. Beim Lightning-Netzwerk muss man sowohl Bitcoin als auch die Konzepte hinter Lightning verstehen, wodurch der Einstieg alles andere als einfach ist.

Hinzu kommt, dass das Paper an sich sehr komplex ist und eher ein abstraktes Bild als ein voll funktionsfähiges System beschreibt. Es fehlten alle technischen Details, bis auf das Grundgerüst in Form der Bitcoin-Transaktionen.

So passierte erst mal nichts, bis Rusty Russell von Blockstream sich des Problems annahm und anfing, die fehlenden Stellen auszuschmücken, denn eines war uns klar, dieses System musste unbedingt real werden. Kurz darauf fingen dann auch die Kollegen von Acinq und Lightning Labs an, eine Implementierung zu bauen. Im Herbst 2016 entschieden die drei Teams dann zusammenzuarbeiten, um ein einziges großes Netz zu bauen, in dem jeder jedem anderen Teilnehmer Bitcoins senden konnte: schnell und anonym. Und so fing die Lightning Network Specification an, ein Prozess, der bis heute anhält.

Dieses Buch wendet sich an alle, die die Hintergründe hinter dem Lightning Netzwerk interessieren, ob das nun ein Nutzer ist, eine Entwicklerin, die auf Lightning aufbauen will, oder vielleicht sogar ein zukünftiger Protokollentwickler. Es bildet das fehlende Bindeglied zwischen dem Paper von 2015 und dem Protokoll, so wie es heute aktiv im Netzwerk genutzt wird, und die Leserinnen und Leser werden langsam und schrittweise an das komplexe Thema herangeführt.

Bei den Autoren handelt es sich um echte Heavyweights der Bitcoin Community. Andreas Antonopoulos ist langjähriger Speaker und hat die unglaublich wertvolle Fähigkeit, komplexe Themen anschaulich zu vermitteln. Olaoluwa Osuntokun, Entwickler der ersten Stunde, bringt die praktische Erfahrung und das notwendige Detailwissen mit und René Pickhardt den theoretischen Hintergrund, um das Protokoll abstrakt zu behandeln.

Ein solches Buch zu schreiben, ist nicht einfach, denn es handelt sich beim Lightning-Netzwerk um ein bewegliches Ziel, und so beleuchtet das Buch sowohl Konzepte als auch deren konkrete Umsetzungen.

Es handelt sich bei diesem Buch also um ein Nachschlagewerk, über das ich mich damals, als wir das Protokoll entwickelt haben, sehr gefreut hätte.

Dr. Christian Decker

Researcher, Blockstream

TEIL I

Das Lightning-Netzwerk verstehen

Eine Übersicht über das Lightning-Netzwerk für jeden, der die grundlegenden Konzepte und die Nutzung des Lightning-Netzwerks verstehen will.

KAPITEL 1

Einführung

Willkommen zu Einführung in das Lightning-Netzwerk.

Das Lightning-Netzwerk (kurz LN) verändert die Art und Weise, wie Menschen online Werte tauschen, und ist eine der spannendsten (Weiter-)Entwicklungen der Bitcoin-Geschichte. 2021 steckte das Lightning-Netzwerk immer noch in den Kinderschuhen. Es handelt sich beim Lightning-Netzwerk um ein Protokoll, das Bitcoin auf clevere und innovative Weise nutzt. Es basiert auf einer sogenannten Second-Layer-Technik, die in einer zweiten Schicht auf Bitcoin aufsetzt.

Das Konzept des Lightning-Netzwerks wurde 2015 vorgeschlagen, und die erste Implementierung wurde 2018 in Betrieb genommen. 2021 begannen wir gerade erst, zu erkennen, welche Möglichkeiten das Lightning-Netzwerk Bitcoin bietet, einschließlich eines besseren Datenschutzes sowie besserer Geschwindigkeit und Skalierbarkeit. Mit dem Kernwissen über das Lightning-Netzwerk können Sie die Zukunft des Netzwerks mitgestalten und gleichzeitig eigene Möglichkeiten nutzen.

Wir gehen davon aus, dass Sie bereits über grundlegende Bitcoin-Kenntnisse verfügen. Ist das nicht der Fall, müssen Sie sich aber keine Sorgen machen – wir erklären die wichtigsten Bitcoin-Konzepte, die zum Verständnis des Lightning-Netzwerks nötig sind, in Anhang A. Wenn Sie mehr über Bitcoin erfahren wollen, können Sie Mastering Bitcoin, 2nd edition, von Andreas M. Antonopoulos (O’Reilly) lesen, das online (https://github.com/bitcoinbook/bitcoinbook) frei verfügbar ist. Die deutsche Übersetzung mit dem Titel Bitcoin & Blockchain – Grundlagen und Programmierung hat O’Reilly herausgebracht (ISBN 978-3-96009-071-7).

Zwar richtet sich dieses Buch größtenteils an Programmierer, doch die ersten Kapitel wurden so geschrieben, dass sie für jedermann, unabhängig vom technischen Hintergrund, lesbar sind. In diesem Kapitel beginnen wir mit einigen Fachbegriffen, wenden uns dann dem Thema Vertrauen zu und wie es in diesen Systemen angewandt wird und diskutieren abschließend die Geschichte und die Zukunft des Lightning-Netzwerks. Los geht’s.

Grundlegende Konzepte des Lightning-Netzwerks

Bei der Betrachtung, wie das Lightning-Netzwerk tatsächlich funktioniert, stoßen wir auf einige technische Begriffe, die zunächst etwas verwirrend sein können. All diese Konzepte und Begriffe werden im Verlauf des Buchs ausführlich erläutert und im Glossar definiert. An dieser Stelle einige der grundlegenden Definitionen bereits einzuführen, wird es Ihnen erleichtern, die Konzepte in den nächsten beiden Kapiteln zu verstehen. Falls Sie noch nicht jede dieser Definitionen verstehen, ist das okay. Es wird besser, je tiefer Sie in den Text einsteigen.

Blockchain

Ein verteiltes Kassenbuch mit Transaktionen, das von einem Netzwerk von Computern erzeugt wird. Bitcoin ist beispielsweise ein System, das eine Blockchain erzeugt. Das Lightning-Netzwerk selbst ist keine Blockchain und erzeugt auch keine. Es ist ein Netzwerk, das für seine Sicherheit eine externe Blockchain benötigt.

Digitale Signatur

Eine digitale Signatur ist ein mathematisches Verfahren zur Verifikation der Authentizität digitaler Nachrichten oder Dokumente. Eine gültige Signatur gibt dem Empfänger berechtigten Grund, zu glauben, dass die Nachricht von einem bekannten Absender stammt, dass dieser Absender nicht leugnen kann, die Nachricht gesendet zu haben, und dass die Nachricht während der Übertragung nicht verändert wurde.

Hashfunktion

Eine kryptografische Hashfunktion ist ein mathematischer Algorithmus, der Daten beliebiger Größe auf einen Bitstring fester Größe (einen Hash) abbildet. Sie ist als sogenannte Einwegfunktion entworfen, d.h., die Funktion lässt sich nicht umkehren.

Node

Ein Computer, der an einem Netzwerk teilnimmt. Eine Lightning-Node ist ein Computer, der am Lightning-Netzwerk teilnimmt. Eine Bitcoin-Node ist ein Computer, der am Bitcoin-Netzwerk teilnimmt. Üblicherweise betreibt ein LN-Nutzer eine Lightning- und eine Bitcoin-Node.

On-Chain oder Off-Chain

Eine Zahlung ist On-Chain, wenn sie als Transaktion in der Bitcoin-Blockchain (oder einer anderen zugrunde liegenden Blockchain) festgehalten wird. Zahlungen, die über Zahlungskanäle zwischen Lightning-Nodes gesendet werden und in der Blockchain nicht sichtbar sind, werden als Off-Chain-Zahlungen bezeichnet. Im Lightning-Netzwerk sind die einzigen On-Chain-Transaktionen üblicherweise diejenigen, die einen Lightning-Zahlungskanal öffnen und schließen. Es gibt einen dritten Typ kanalmodifizierender Transaktionen, das sogenannte Splicing, mit dem im Kanal gebundene (Geld-)Mittel hinzugefügt/entfernt werden können.

Zahlung

Werden Werte im Lightning-Netzwerk ausgetauscht, sprechen wir von einer »Zahlung« und nicht von einer »Transaktion« auf der Bitcoin-Blockchain.

Zahlungskanal

Eine finanzielle Beziehung zwischen zwei Nodes im Lightning-Netzwerk. Wird üblicherweise über Multisignatur-Bitcoin-Transaktionen implementiert, die sich die Kontrolle über die Bitcoins zwischen zwei Lightning-Nodes teilen.

Routen oder Senden

Im Gegensatz zum Bitcoin, wo Transaktionen »gesendet« werden, indem sie an jeden übertragen werden, ist Lightning ein geroutetes Netzwerk, in dem Zahlungen über ein oder mehrere Zahlungskanäle »geroutet« werden und einem Pfad vom Sender zum Empfänger folgen.

Transaktion

Eine Datenstruktur, die die Übertragung der Kontrolle über bestimmte Mittel (d.h. Bitcoin) aufzeichnet. Das Lightning-Netzwerk nutzt Bitcoin-Transaktionen (oder Transaktionen einer anderen Blockchain), um die Kontrolle über die Mittel festzuhalten.

Detailliertere Definitionen dieser und vieler weiterer Begriffe finden Sie im »Glossar« auf Seite 439. Im Verlauf des Buchs erläutern wir, was diese Konzepte bedeuten und wie die Techniken funktionieren.

Nachdem Sie mit diesen grundlegenden Begriffen vertraut sind, wollen wir uns einem Konzept zuwenden, das Sie bereits kennen: Vertrauen.

Vertrauen in dezentralisierten Netzwerken

Sie werden häufig hören, dass die Menschen Bitcoin und das Lightning-Netzwerk als »vertrauensfrei« bezeichnen. Im ersten Moment ist das verwirrend. Vertrauen ist doch eine gute Sache? Banken werben damit! Ist ein »vertrauensfreies« System, also ein System ohne Vertrauen, nicht eher etwas Schlechtes?

Der Begriff »vertrauensfrei« beschreibt die Fähigkeit, arbeiten zu können, ohne anderen Teilnehmenden des Systems vertrauen zu müssen. Bei einem dezentralisierten System wie Bitcoin können Sie natürlich immer eine Transaktion mit jemandem durchzuführen, dem Sie vertrauen. Das System stellt aber sicher, dass Sie nicht betrogen werden können, auch wenn Sie der Gegenpartei einer Transaktion nicht vertrauen. Vertrauen ist eine nette Option und kein absolutes Muss des Systems.

Vergleichen Sie das mit traditionellen Systemen wie Banken, wo Sie einer dritten Partei vertrauen müssen, weil diese Ihr Geld kontrolliert. Missbraucht eine Bank Ihr Vertrauen, können Sie vielleicht Regress über eine Regulierungsbehörde oder ein Gericht einfordern, doch kostet Sie das viel Zeit, Geld und Mühe.

Vertrauensfrei bedeutet nicht frei von Vertrauen. Es bedeutet, dass Vertrauen keine Grundvoraussetzung für Transaktionen ist und dass Transaktionen sogar mit Leuten möglich sind, denen Sie nicht vertrauen, weil das System Betrug verhindert.

Bevor wir darauf eingehen, wie das Lightning-Netzwerk funktioniert, ist es wichtig, ein Grundkonzept zu verstehen, das Bitcoin, dem Lightning-Netzwerk und vielen anderen dieser Systeme zugrunde liegt: etwas, das wir als Fairness-Protokoll bezeichnen. Ein Fairness-Protokoll erzielt ein faires Ergebnis zwischen den Teilnehmenden (die einander nicht vertrauen müssen) ohne die Notwendigkeit einer zentralen Autorität. Es bildet das Rückgrat dezentraler Systeme wie Bitcoin.

Fairness ohne zentrale Autorität

Wie kann man genug Vertrauen herstellen, um kooperative oder geschäftliche Tätigkeiten aufzunehmen, wenn die Leute gegensätzliche Interessen haben? Die Antwort auf diese Frage bildet den Kern unterschiedlicher wissenschaftlicher Disziplinen wie Wirtschaftswissenschaften, Soziologie, Verhaltenspsychologie und Mathematik. Einige dieser Fachrichtungen liefern uns »weiche« Antworten, die auf Konzepten wie Reputation, Fairness, Moral und sogar Religion basieren. Andere geben konkrete Antworten, die nur von der Annahme ausgehen, dass die Teilnehmer dieser Transaktionen rational handeln und ihr Eigeninteresse der wesentliche Antrieb ist.

Im Allgemeinen gibt es eine Handvoll Möglichkeiten, faire Ergebnisse bei der Interaktion zwischen Individuen zu erzielen, die gegensätzliche Interessen verfolgen:

Vertrauen

Sie interagieren nur mit Menschen, denen Sie bereits vertrauen, sei es aufgrund früherer Interaktionen, ihrer Reputation oder familiärer Beziehungen. Das funktioniert im kleinen Rahmen ganz gut, besonders innerhalb von Familien oder kleinen Gruppen, und ist daher die häufigste Basis kooperativen Verhaltens. Leider skaliert diese Lösung nicht gut und leidet unter (gruppenorientiertem) »Stammesdenken«.

Rechtsnormen

Legen Sie Regeln für Interaktionen fest, die durch eine Institution durchgesetzt werden. Diese Lösung skaliert besser, aufgrund unterschiedlicher Bräuche und Traditionen aber nicht global. Auch ist die Skalierung der entsprechenden Institutionen unmöglich. Ein unangenehmer Nebeneffekt dieser Lösung ist, dass die Institutionen immer mächtiger werden, je größer sie werden, was Korruption begünstigt.

Vertrauenswürdige Dritte

Binden Sie einen Intermediär in jede Interaktion ein, um Fairness zu erzwingen. In Kombination mit den »Rechtsnormen«, die die Aufsicht über die Intermediäre sicherstellen, skaliert diese Lösung besser, doch auch hier bleibt eine Unausgewogenheit der Macht bestehen: Die Intermediäre werden sehr mächtig und können der Korruption erliegen. Die Konzentration von Macht führt zu systemischen Risiken und systemischen Fehlern (Systemrelevanz, »zu groß, um zu scheitern«).

Spieltheoretische Fairness-Protokolle

Die letzte Kategorie entstammt der Kombination aus Internet und Kryptografie und ist Gegenstand dieses Abschnitts. Sehen wir uns an, wie Fairness-Protokolle funktionieren und welche Vor- und Nachteile sie bieten.

Vertrauenswürdige Protokolle ohne Intermediäre

Kryptografische Systeme wie Bitcoin und das Lightning-Netzwerk sind Systeme, in denen Sie mit Menschen (und Computern) Geschäfte abwickeln können, denen Sie nicht vertrauen. Das wird häufig als »vertrauensfrei« bezeichnet, obwohl es tatsächlich nicht frei von Vertrauen ist. Sie müssen der eingesetzten Software vertrauen, und Sie müssen darauf vertrauen, dass das von der Software implementierte Protokoll zu fairen Ergebnissen führt.

Der große Unterschied zwischen einem kryptografischen System wie diesem und einem traditionellen Finanzsystem besteht darin, dass im traditionellen Finanzsystem ein vertrauenswürdiger Dritter (zum Beispiel eine Bank) sicherstellt, dass die Ergebnisse fair sind. Ein wesentliches Problem solcher Systeme besteht darin, dass sie der dritten Partei zu viel Macht geben und gleichzeitig eine einzelne Schwachstelle (einen Single Point of Failure) bilden. Verletzt der vertrauenswürdige Dritte selbst das Vertrauen oder versucht er zu betrügen, ist die Basis des Vertrauens dahin.

Wenn Sie sich mit kryptografischen Systemen beschäftigen, werden Sie ein bestimmtes Muster erkennen: Statt auf vertrauenswürdige Dritte zu setzen, versuchen diese Systeme, unfaire Ergebnisse zu verhindern, indem sie positive und negative Anreize nutzen. Bei kryptografischen Systemen platzieren Sie das Vertrauen in das Protokoll, d.h. ein System mit einer Reihe von Regeln, die, richtig konzipiert, die gewünschten positiven und negativen Anreize korrekt anwenden. Dieser Ansatz hat zwei Vorteile: Sie müssen nicht nur keinem Dritten vertrauen, sondern müssen faire Ergebnisse auch nicht explizit durchsetzen. Solange die Teilnehmer dem vereinbarten Protokoll folgen, sorgt der Anreizmechanismus im Protokoll für faire Ergebnisse, ohne sich weiter um die Durchsetzung kümmern zu müssen.

Der Einsatz positiver und negativer Anreize zum Erreichen fairer Ergebnisse ist ein Aspekt eines Teilgebiets der Mathematik, das als Spieltheorie bezeichnet wird. Es modelliert Entscheidungssituationen, »in denen mehrere Beteiligte miteinander interagieren«.1 Kryptografische Systeme, die Finanztransaktionen zwischen Teilnehmern kontrollieren, wie z.B. Bitcoin und das Lightning-Netzwerk, bauen stark auf der Spieltheorie auf, um zu verhindern, dass Teilnehmer betrügen können, und um es einander nicht vertrauenden Teilnehmern zu ermöglichen, faire Ergebnisse zu erzielen.

Zwar mögen die Spieltheorie und ihr Einsatz in kryptografischen Systemen auf den ersten Blick verwirrend und ungewohnt wirken, doch es ist sehr wahrscheinlich, dass Sie solche Systeme bereits aus Ihrem Alltag kennen. Sie erkennen sie nur noch nicht als solche. Im folgenden Abschnitt wollen wir ein einfaches Beispiel aus der Kindheit nutzen, um das grundlegende Muster aufzuzeigen. Sobald Sie das Grundmuster verstanden haben, werden Sie es überall in der Blockchain-Welt sehen und es schnell und intuitiv erkennen.

In diesem Buch nennen wir dieses Muster Fairness-Protokoll und definieren es als Prozess, das ein System positiver und negativer Anreize nutzt, um faire Ergebnisse für die Teilnehmenden zu erzielen, die einander nicht vertrauen. Die Durchsetzung des Fairness-Protokolls ist nur notwendig, um sicherzustellen, dass die Teilnehmer die positiven bzw. negativen Anreize nicht umgehen können.

Ein Fairness-Protokoll in Aktion

Sehen wir uns ein Beispiel für ein Fairness-Protokoll an, das Ihnen möglicherweise vertraut ist.

Stellen Sie sich eine Familie mit zwei Kindern beim Mittagessen vor. Die Kinder sind schwierige Esser: Das Einzige, was sie zu sich nehmen, sind Pommes frites. Die Eltern habe eine Schüssel mit »Fritten« zubereitet, die sich die beiden Geschwister teilen müssen. Die Eltern müssen eine faire Verteilung der Fritten sicherstellen, andernfalls werden sie sich (möglicherweise den ganzen Tag) das Gemaule anhören müssen. Außerdem ist es immer möglich, dass eine unfaire Situation in Gewalt umschlägt. Was können die Eltern tun?

Es gibt verschiedene Möglichkeiten, in dieser Situation strategische Fairness zwischen den beiden Geschwistern zu erreichen, die einander nicht vertrauen und gegensätzliche Interessen haben. Die naive, aber übliche Methode ist, dass die Eltern ihre Autorität als vertrauenswürdige dritte Partei nutzen: Sie teilen die Schüssel in zwei Portionen auf. Das entspricht der traditionellen Finanzwelt, in der eine Bank, ein Buchhalter oder ein Anwalt als vertrauenswürdige dritte Partei fungiert, um jedwede Schummelei zwischen den beiden Parteien zu verhindern.

Das Problem bei diesem Szenario besteht darin, dass sehr viel Macht und Verantwortung in den Händen der vertrauenswürdigen dritten Partei liegt. In unserem Beispiel liegt die volle Verantwortung für das gleichmäßige Verteilen der Pommes frites bei den Eltern, und die Kinder können nur warten, schauen und meckern. Die Kinder beschuldigen die Eltern, parteiisch zu sein und das Essen nicht fair zu verteilen. Während sie sich um die Fritten streiten, schreien sie: »Diese Pommes-Portion ist größer!« und ziehen ihre Eltern in den Kampf hinein. Klingt furchtbar, nicht wahr? Sollen die Eltern lauter schreien? Alle Pommes frites wegnehmen? Damit drohen, nie wieder Pommes frites zu machen, und die undankbaren Kinder hungrig ins Bett schicken?

Es gibt eine wesentlich bessere Lösung: Die Geschwister lernen das Spiel »teile und wähle« kennen. Bei jedem Essen teilt eines der Geschwister die Schüssel in zwei Portionen auf, und das andere Geschwisterteil darf wählen, welche Portion es will.

Sofort erkennen die Geschwister die Dynamik dieses Spiels. Macht eines der Kinder beim Verteilen einen Fehler oder versucht zu betrügen, kann das andere Kind es »bestrafen«, indem es die größere Portion nimmt. Es ist in beiderseitigem Interesse der Geschwister, doch insbesondere im Interesse desjenigen, der die Pommes verteilt, fair zu bleiben. Nur der Betrüger verliert in diesem Szenario. Die Eltern müssen weder ihre Autorität einsetzen noch die Fairness in irgendeiner Form durchsetzen, sie müssen nur das Protokoll durchsetzen. Solange die Geschwister den ihnen zugedachten Rollen als »Verteiler« und »Wähler« nicht entgehen können, stellt das Protokoll selbst sicher, dass es ein faires Ergebnis gibt, ohne dass weiter eingegriffen werden muss. Die Eltern können niemanden bevorzugen oder das Ergebnis verfälschen.

Während die berüchtigten Pommes-Schlachten der 1980er den wesentlichen Punkt schön verdeutlichen, sind jedwede Ähnlichkeiten des obigen Szenarios mit den Kindheitserinnerungen der Autoren und seinen Cousins reiner Zufall …?

Sicherheits-Primitive als Grundbausteine

Damit ein Fairness-Protokoll wie dieses funktionieren kann, sind bestimmte Garantien, oder Sicherheits-Primitive, notwendig, die man kombinieren kann, um die Durchsetzung sicherzustellen. Die erste Sicherheits-Primitive ist eine strikte Zeiteinteilung/-sequenzierung: Die Aktion »Teilen« muss vor der Aktion »Wählen« erfolgen. Es ist zwar nicht offensichtlich, doch solange Sie nicht garantieren können, dass Aktion A vor Aktion B erfolgt, ist das Protokoll hinfällig. Die zweite Sicherheits-Primitive ist die Verpflichtung ohne Ablehnung. Jedes Kind muss sich zu seiner Rolle verpflichten: entweder »Teiler« oder »Wähler«. Und sobald das Verteilen abgeschlossen ist, muss der Teiler das Ergebnis akzeptieren – er kann keinen Rückzieher machen und es noch einmal versuchen.

Kryptografische Systeme bieten eine Reihe von Sicherheits-Primitiven an, die auf unterschiedliche Art und Weise kombiniert werden können, um ein Fairness-Protokoll aufzubauen. Neben Sequenzierung und Verpflichtung können wir weitere Werkzeuge nutzen:

Hashfunktionen zum Fingerprinting von Daten als Form der Verpflichtung oder als Basis einer digitalen Signatur.

Digitale Signaturen zur Authentifizierung, Nichtablehnung oder als Beweis für den Besitz eines Secrets.

Verschlüsselung/Entschlüsselung, um den Zugriff auf Informationen auf autorisierte Teilnehmer zu beschränken.

Das ist nur ein kleiner Teil einer ganzen »Menagerie« genutzter Sicherheits- und kryptografischer Primitive. Weitere grundlegende Primitive und Kombinationen werden fortlaufend entwickelt.

In unserem Beispiel haben wir eine Form des Fairness-Protokolls namens »teile und wähle« kennengelernt. Das ist nur eines einer Vielzahl von Fairness-Protokollen, die sich aufbauen lassen, indem man die Grundbausteine aus Sicherheits-Primitiven auf unterschiedliche Weise kombiniert. Doch das grundlegende Muster ist immer gleich: Zwei oder mehr Teilnehmer interagieren, ohne einander vertrauen zu müssen, indem sie einer Reihe von Schritten eines vereinbarten Protokolls folgen. Die Schritte des Protokolls legen positive und negative Anreize fest, durch die sich ein Betrug nicht lohnt und die automatisch zu einem fairen Ergebnis führen, wenn die Teilnehmer rational handeln. Die Durchsetzung ist für ein faires Ergebnis nicht nötig – sie sorgt nur dafür, dass die Teilnehmer das vereinbarte Protokoll nicht verletzen.

Da Sie nun das grundlegende Muster verstehen, werden Sie es überall bei Bitcoin, dem Lightning-Netzwerk und in vielen anderen Systemen erkennen. Sehen wir uns einige konkrete Beispiele an.

Beispiel für Fairness-Protokolle

Das wohl bekannteste Beispiel eines Fairness-Protokolls ist Bitcoins Konsensalgorithmus Proof of Work (PoW). Bei Bitcoin konkurrieren Miner um die Verifikation von Transaktionen und deren Zusammenfassung in Blöcken. Damit die Miner nicht schummeln, verwendet Bitcoin ein System positiver und negativer Anreize, ohne sie einer Autorität zu unterstellen. Miner müssen Elektrizität und Hardware aufwenden, um Arbeit (engl. Work) zu erledigen, die als Beweis (engl. Proof) in jeden Block eingebettet wird. Das wird durch eine Eigenschaft der Hashfunktionen erreicht, bei der der Ausgabewert über alle möglichen Werte gleichmäßig verteilt ist. Kann ein Miner schnell genug einen gültigen Block erzeugen, erhält er die Belohnung für diesen Block. Da die Miner gezwungen sind, viel Elektrizität aufzuwenden, bevor das Netzwerk ihren Block aufnimmt, haben sie einen positiven Anreiz, die Transaktionen im Block korrekt zu validieren. Wenn sie schummeln oder irgendeinen Fehler begehen, wird ihr Block abgelehnt, und die zum »Beweis« aufgewandte Elektrizität ist verschwendet. Niemand muss Miner zur Erzeugung gültiger Blöcke zwingen. Die Belohnung bzw. Strafe ist Anreiz genug. Das Protokoll muss dabei einfach sicherstellen, dass nur gültige Blöcke mit Proof of Work akzeptiert werden.

Das Fairness-Protokoll-Muster findet sich auch bei vielen verschiedenen Aspekten des Lightning-Netzwerks:

Diejenigen, die Kanäle finanzieren, stellen sicher, dass eine Rückerstattungstransaktion signiert wird, bevor sie die Transaktion veröffentlichen.

Sobald ein Kanal in einen neuen Zustand übergeht, wird der alte Zustand »widerrufen«. Versucht jemand, diesen alten Zustand zu veröffentlichen, wird er bestraft, indem er den gesamten Betrag verliert.

Wer Zahlungen weiterleitet, weiß, dass er entweder eine Rückerstattung erhält oder von der vorherigen Node bezahlt wird.

Dieses Muster sehen wir immer und immer wieder. Faire Ergebnisse werden nicht durch irgendeine Autorität erzwungen. Sie entstehen als natürliche Konsequenz eines Protokolls, das Fairness belohnt und Schummelei bestraft – ein Fairness-Protokoll, das das Eigeninteresse nutzt, um faire Ergebnisse zu erzielen.

Bitcoin und das Lightning-Netzwerk sind beides Implementierungen von Fairness-Protokollen. Warum brauchen wir dann überhaupt das Lightning-Netzwerk? Reicht Bitcoin nicht?

Motivation für das Lightning-Netzwerk

Bitcoin ist ein System, das Transaktionen in einem global replizierten, öffentlichen Kassenbuch festhält. Jede Transaktion wird von jedem teilnehmenden Computer gesehen, validiert und gespeichert. Wie Sie sich vorstellen können, generiert das sehr viele Daten und ist schwer zu skalieren.

Als Bitcoin und der Bedarf an Transaktionen größer wurden, stieg die Anzahl der Transaktionen pro Block an, bis schließlich die Grenze der Blockgröße erreicht wurde. Sobald ein Block »voll« ist, müssen überschüssige Transaktionen in einer Queue warten. Viele Nutzer erhöhen die Gebühren, die sie zu zahlen bereit sind, um sich im nächsten Block Platz für ihre Transaktion zu erkaufen.

Wenn der Bedarf die Kapazität des Netzwerks ständig übersteigt, bleibt eine steigende Zahl von Nutzertransaktionen unbestätigt. Der Gebührenwettstreit erhöht auch die Kosten jeder Transaktion, was Transaktionen kleiner Beträge (sogenannte Mikrotransaktionen) in Zeiten hoher Nachfrage völlig unrentabel macht.

Um dieses Problem zu lösen, können Sie die Blockgröße erhöhen, um Raum für mehr Transaktionen zu schaffen. Eine »Versorgung« mit mehr Platz pro Block führt zu niedrigeren Preisen bei den Transaktionsgebühren.

Allerdings wälzt die Erhöhung der Blockgröße die Kosten auf die Node-Betreiber ab, die mehr Ressourcen bereitstellen müssen, um die Blockchain zu validieren und zu speichern. Da Blockchains geschwätzige Protokolle sind, muss jede Node jede einzelne Transaktion im Netzwerk kennen und validieren. Einmal validiert, muss jede Transaktion und jeder Block an die »Nachbarn« der Node weitergeleitet (propagiert) werden, wodurch sich die Anforderungen an die Bandbreite vervielfachen. Je größer ein Block, desto mehr Bandbreite, Datenverarbeitung und Speicherplatz muss jede einzelne Node aufwenden. Auf diese Weise die Transaktionskapazität zu erhöhen, hat den unerwünschten Effekt der Zentralisierung des Systems, weil die Anzahl der Nodes und Node-Betreiber reduziert wird. Da die Node-Betreiber für den Betrieb von Nodes nicht entschädigt werden, werden nur wenige finanziell gut ausgestattete Betreiber ihre Nodes weiterhin laufen lassen, wenn deren Betrieb teuer ist.

Blockchains skalieren

Die Nebeneffekte der Erhöhung der Blockgröße bzw. der Reduzierung der Blockzeit in Bezug auf die Zentralisierung des Netzwerks sind vielfältig, wie ein paar Berechnungen zeigen.

Nehmen wir an, dass die Nutzung von Bitcoin so weit ansteigt, dass das Netzwerk 40.000 Transaktionen pro Sekunde verarbeiten muss. Das entspricht in etwa dem, was das Visa-Netzwerk zu Spitzenzeiten verarbeiten muss.

Gehen wir von durchschnittlich 250 Bytes pro Transaktion aus, wäre das ein Datenstrom von 10 Megabyte (MByte) bzw. 80 Megabit (MBit) pro Sekunde allein für das Empfangen aller Transaktionen. Der Traffic-Overhead für die Weiterleitung der Transaktionsinformationen an andere Peers ist dabei noch nicht berücksichtigt. Mit Blick auf die Geschwindigkeiten von Fiberglas- und mobilen 5G-Verbindungen scheint das nicht besonders viel zu sein, würde aber dennoch jeden daran hindern, eine Node zu betreiben, die diese Anforderung nicht erfüllt. Das gilt insbesondere für Länder, in denen Hochgeschwindigkeitsinternet nicht erschwinglich oder nicht flächendeckend verfügbar ist.

Die Nutzerinnen und Nutzer müssen ihre Bandbreite auch anderweitig verwenden können, und man kann nicht erwarten, dass sie sie erhöhen, nur um Transaktionen zu empfangen.

Die lokale Speicherung würde darüber hinaus zu 864 Gigabyte pro Tag führen. Das entspricht grob einem Terabyte an Daten oder der Größe einer Festplatte.

Die Verifikation von 40.000 ECDSA-Signaturen (Elliptic Curve Digital Signature Algorithm) pro Sekunde ist ebenfalls kaum praktikabel,2 was den initialen Block-Download (IBD) der Bitcoin-Blockchain (d.h. die Synchronisation und Verifikation aller Transaktionen beginnend mit dem Genesis-Block) ohne sehr teure Hardware nahezu unmöglich macht.

Zwar klingen 40.000 Transaktionen pro Sekunde nach viel, doch man erreicht damit nur einen Gleichstand mit traditionellen Zahlungsnetzwerken zu Spitzenzeiten. Innovationen wie Maschine-zu-Maschine-Zahlungen, Mikrotransaktionen und andere Anwendungen werden den Bedarf sehr wahrscheinlich um ein Vielfaches ansteigen lassen.

Einfach ausgedrückt: Sie können eine Blockchain nicht so skalieren, dass sie alle Transaktionen dieser Welt in dezentralisierter Form validieren kann.

Doch was wäre, wenn eine Node nicht jede einzelne Transaktion kennen und validieren müsste? Was wäre, wenn es skalierbare Off-Chain-Transaktionen gäbe, ohne auf die Sicherheit des Bitcoin-Netzwerks verzichten zu müssen?

Im Februar 2015 haben Joseph Poon und Thaddeus Dryja mit der Veröffentlichung von »The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments«3 eine mögliche Lösung für Bitcoins Skalierungsproblem vorgeschlagen.

In dem (mittlerweile veralteten) Whitepaper schätzen Poon und Dryja, dass Bitcoin 8 Gigabyte große Blöcke benötigen würde, um die von Visa zu Spitzenzeiten verarbeiteten 47.000 Transaktionen pro Sekunde zu erreichen. Das würde den Betrieb einer Node, mit Ausnahme von großen Konzernen und Industrieunternehmen, für jeden unmöglich machen. Das Ergebnis wäre ein Netzwerk, in dem nur wenige Nutzer tatsächlich den Zustand des Kassenbuchs validieren könnten. Um dezentral zu bleiben, basiert Bitcoin darauf, dass Nutzer das Kassenbuch selbst validieren, ohne Dritten vertrauen zu müssen. Nutzer vom Betrieb einer Node auszunehmen, würde den durchschnittlichen Nutzer dazu zwingen, einer dritten Partei zu vertrauen, um den Status des Kassenbuchs zu erfahren, was letztlich zum Bruch des Bitcoin-Vertrauensmodells führen würde.

Das Lightning-Netzwerk schlägt ein neues Netzwerk vor, eine »zweite Schicht« (engl. Second Layer), in dem Benutzer Zahlungen direkt miteinander abwickeln können (Peer to Peer), ohne für jede Zahlung eine Transaktion in der Bitcoin-Blockchain festhalten zu müssen. Nutzer können einander im Lightning-Netzwerk so oft bezahlen, wie sie wollen, ohne zusätzliche Bitcoin-Transaktionen zu erzeugen oder On-Chain-Gebühren zahlen zu müssen. Sie nutzen die Bitcoin-Blockchain nur, um zu Beginn Bitcoin in das Lightning-Netzwerk zu laden oder dort zu verrechnen (engl. settle), also Bitcoin aus dem Lightning-Netzwerk zu entfernen. Das bedeutet, dass viele Bitcoin-Zahlungen außerhalb der Blockchain (Off-Chain) erfolgen können und nur das erstmalige Laden und das abschließende Verrechnen als Transaktionen von Blockchain-Nodes validiert und gespeichert werden müssen. Neben der reduzierten Last für die Nodes sind Zahlungen im Lightning-Netzwerk für die Nutzer günstiger, weil sie keine Blockchain-Gebühren zahlen müssen. Sie bieten außerdem eine bessere Privatsphäre, weil sie nicht allen Teilnehmern des Netzwerks bekannt gegeben und darüber hinaus nicht permanent gespeichert werden.

Zwar wurde das Lightning-Netzwerk ursprünglich für Bitcoin konzipiert, kann aber für jede Blockchain implementiert werden, die einige technische Anforderungen erfüllt. Andere Blockchains wie Litecoin unterstützen das Lightning-Netzwerk bereits. Zusätzlich entwickeln verschiedene weitere Blockchains vergleichbare Second-Layer- bzw. »Layer 2«-Lösungen für die Skalierung.

Die das Lightning-Netzwerk definierenden Eigenschaften

Das Lightning-Netzwerk ist ein Netzwerk, das als Second-Layer-Protokoll auf Bitcoin und anderen Blockchains aufsetzt. Das Lightning-Netzwerk ermöglicht schnelle, sichere, vertrauens- und genehmigungsfreie (engl. permissionless) Zahlungen. Hier einige Eigenschaften des Lightning-Netzwerks:

Nutzer des Lightning-Netzwerks können einander Zahlungen zu geringen Kosten und in Echtzeit weiterleiten.

Nutzer, die Werte über das Lightning-Netzwerk austauschen, müssen nicht auf die Blockbestätigungen ihrer Zahlung warten.

Sobald eine Zahlung im Lightning-Netzwerk abgeschlossen ist, üblicherweise innerhalb weniger Sekunden, ist sie final und kann nicht rückgängig gemacht werden. Wie eine Bitcoin-Transaktion kann eine Zahlung im Lightning-Netzwerk nur vom Empfänger zurückerstattet werden.

Während On-Chain-Bitcoin-Transaktionen an alle Nodes im Netzwerk weitergeleitet und von diesen verifiziert werden, werden Zahlungen im Lightning-Netzwerk zwischen Node-Paaren übertragen und sind nicht für jedermann sichtbar. Das führt zu mehr Privatsphäre.

Im Gegensatz zu Transaktionen im Bitcoin-Netzwerk müssen im Lightning-Netzwerk weitergeleitete Zahlungen nicht dauerhaft gespeichert werden. Lightning benötigt daher weniger Ressourcen und ist günstiger. Von dieser Eigenschaft profitiert ebenfalls die Privatsphäre.

Das Lightning-Netzwerk nutzt Onion-Routing ähnlich dem Tor-Netzwerkprotokoll, d.h., dass selbst die an einer Zahlung beteiligten Nodes nur den Vorgänger und den Nachfolger der Zahlungsroute kennen.

Setzt das Lightning-Netzwerk auf Bitcoin auf, nutzt es auch reale Bitcoins, die immer im Besitz und unter der vollständigen Kontrolle des Nutzers sind. Lightning ist kein separater Token oder Coin, es

ist

Bitcoin.

Anwendungsfälle, Nutzer und ihre Geschichten

Um besser zu verstehen, wie das Lightning-Netzwerk tatsächlich funktioniert und warum die Menschen es einsetzen, lernen Sie nachfolgend eine Reihe von Nutzerinnen und Nutzern mit ihren Geschichten kennen.

In unseren Beispielen haben einige Menschen Bitcoin bereits genutzt, während andere völlige Neulinge im Bitcoin-Netzwerk sind. Jede hier aufgeführte Person einschließlich ihrer Geschichte stellt einen oder mehrere Anwendungsfälle dar. Wir werden ihnen im Verlauf des Buchs immer wieder begegnen:

(End-)Verbraucher

Alice ist eine Bitcoin-Nutzerin, die schnelle, sichere, günstige und private Zahlungen für kleine Erwerbungen nutzen möchte. Sie kauft Kaffee mit Bitcoin über das Lightning-Netzwerk.

Händler

Bob betreibt »Bobs Café«. On-Chain-Bitcoin-Zahlungen eignen sich nicht für kleine Beträge wie eine Tasse Kaffee, weshalb er das Lightning-Netzwerk nutzt, um schnelle Bitcoin-Zahlungen anbieten zu können, die ihn kaum Gebühren kosten.

Softwareservice

Chan ist ein chinesischer Entrepreneur, der Informationsdienste zum Lightning-Netzwerk, zu Bitcoin und anderen Kryptowährungen anbietet. Chan verkauft diese Informationen über das Internet und hat dazu Mikrozahlungen über das Lightning-Netzwerk implementiert. Zusätzlich hat Chan einen Liquiditätsservice implementiert. Er verleiht eingehende Kanalkapazitäten im Lightning-Netzwerk und berechnet dafür eine kleine Gebühr.

Gamer

Dina ist eine russische Gamerin im Teenager-Alter. Sie spielt viele verschiedene Computerspiele, bevorzugt aber solche mit einer auf echtem Geld basierenden »In-Game-Ökonomie«. Während sie spielt, verdient sie auch Geld, indem sie virtuelle In-Game-Items erlangt und verkauft. Das Lightning-Netzwerk erlaubt ihr die Überweisung kleiner Beträge für In-Game-Items sowie das Erwirtschaften kleiner Beträge für das Abschließen von Quests.

Fazit

In diesem Kapitel haben wir das grundlegende Konzept behandelt, das sowohl Bitcoin als auch dem Lightning-Netzwerk zugrunde liegt: das Fairness-Protokoll.

Wir haben uns die Geschichte des Lightning-Netzwerks angesehen und die Motivation hinter Second-Layer-Skalierungslösungen für Bitcoin und andere Blockchain-basierte Netzwerke.

Und Sie haben grundlegende Begriffe wie Node, Zahlungskanal, On-Chain-Transaktion und Off-Chain-Zahlung kennengelernt.

Abschließend wurden Alice, Bob, Chan und Dina vorgestellt, denen wir im weiteren Verlauf des Buchs folgen werden. Im nächsten Kapitel begleiten wir Alice bei der Wahl einer Lightning-Wallet und den Vorbereitungen für ihre erste Lightning-Zahlung für einen Kaffee in Bobs Café.

KAPITEL 2

Erste Schritte

In diesem Kapitel beginnen wir da, wo die meisten Menschen anfangen, wenn sie das Lightning-Netzwerk für sich entdecken – wir wählen eine Software, um am LN-System teilnehmen zu können. Wir sehen uns die Wahl zweier Nutzer an, die typische Anwendungsfälle des Lightning-Netzwerks darstellen, und lernen von den Beispielen. Alice wird als Gast mit einer Lightning-Wallet einen Kaffee in Bobs Café kaufen. Bob, der Betreiber des Cafés, wird eine Lightning-Node und eine Lightning-Wallet nutzen, um ein Kassensystem in seinem Café zu betreiben, das Zahlungen über das Lightning-Netzwerk akzeptiert.

Alice’ erste Lightning-Wallet

Alice ist langjährige Bitcoin-Nutzerin. Wir kennen Sie bereits aus Kapitel 1 von Mastering Bitcoin1, wo sie eine Tasse Kaffee in Bobs Café mit einer Bitcoin-Transaktion bezahlt hat. Wenn Sie nicht wissen, wie Bitcoin-Transaktionen funktionieren, oder eine Auffrischung brauchen, lesen Sie bitte Mastering Bitcoin oder die Zusammenfassung in Anhang A.

Alice hat mitbekommen, dass Bobs Café mittlerweile auch LN-Zahlungen akzeptiert. Alice will unbedingt mehr über das Lightning-Netzwerk wissen und damit experimentieren. Sie möchte eine der ersten LN-Kundinnen von Bob sein. Dazu muss Alice zuerst eine Lightning-Wallet wählen, die ihren Bedürfnissen entspricht.

Alice möchte ihre Bitcoin nicht bei einer dritten Partei verwahren. Sie hat genug über Kryptowährungen gelernt, um zu wissen, wie man eine Wallet nutzt. Sie wünscht sich außerdem eine mobile Wallet, damit sie unterwegs kleine Zahlungen tätigen kann. Sie entscheidet sich für die beliebte mobile Lightning-Wallet Eclair. Sehen wir uns an, wie und warum sie diese Wahl getroffen hat.

Lightning-Nodes

Der Zugang zum Lightning-Netzwerk erfolgt über Softwareanwendungen, die das LN-Protokoll beherrschen. Eine Lightning-Netzwerk-Node (LN-Node oder einfach Node) ist eine Softwareanwendung mit drei wichtigen Eigenschaften. Erstens sind Lightning-Nodes Wallets, d.h., sie senden und empfangen Zahlungen über das Lightning-Netzwerk, aber auch über das Bitcoin-Network. Zweitens müssen Nodes auf Peer-to-Peer-Basis mit anderen Lightning-Nodes kommunizieren, um das Netzwerk aufzubauen, und drittens müssen Lightning-Nodes auch auf die Bitcoin-Blockchain (oder Blockchains anderer Kryptowährungen) zugreifen, um die für Zahlungen genutzten Mittel zu sichern.

Das höchste Maß an Kontrolle haben Nutzer, wenn sie eine eigene Bitcoin-Node und Lightning-Node betreiben. Lightning-Nodes können aber auch einen leichtgewichtigen Bitcoin-Client, die sogenannte vereinfachte Zahlungsverifikation (Simplified Payment Verification, kurz SPV) nutzen, um mit der Bitcoin-Blockchain zu interagieren.

Lightning-Explorer

LN-Explorer sind nützliche Werkzeuge, mit denen Sie sich Statistiken über Nodes, Kanäle und die Netzwerkkapazität ansehen können.

Nachfolgend eine unvollständige Liste:

1ML Lightning-Explorer (

https://1ml.com

)

ACINQs Lightning-Explorer (

https://explorer.acinq.co

) mit schöner Visualisierung

Amboss Space Lightning-Explorer (

https://amboss.space

) mit Community-Metriken und intuitiver Visualisierung

Fiatjafs Lightning-Explorer (

https://ln.bigsun.xyz

) mit vielen Diagrammen

hashXP Lightning-Explorer (

https://hashxp.org/lightning/node

)

Beachten Sie, dass bei der Nutzung von Lightning-Explorern, wie bei allen anderen Block-Explorern, die Privatsphäre ein Thema ist. Sind Nutzer zu sorglos, kann die Website ihre IP-Adressen und ihr Verhalten aufzeichnen (z.B. die Nodes, an denen Nutzer interessiert sind).

Sie sollten auch daran denken, dass es keinen globalen Konsens über den aktuellen Lightning-Graphen bzw. den Zustand irgendeines Kanals gibt. Nutzer sollten sich daher niemals auf Lightning-Explorer verlassen, wenn sie aktuelle Informationen abrufen wollen. Während die Nutzer Kanäle öffnen, schließen und aktualisieren, ändert sich darüber hinaus der Graph, und einzelne Lightning-Explorer sind möglicherweise nicht auf dem neuesten Stand. Nutzen Sie Lightning-Explorer zur Visualisierung des Netzwerks oder um Informationen einzuholen, aber nicht als verbindliche Quelle für das, was im Lightning-Netzwerk passiert. Für eine autoritative Sicht des Lightning-Netzwerks müssen Sie eine eigene Lightning-Node betreiben, die einen Kanal-Graphen aufbaut und verschiedene Statistiken führt, die Sie sich über eine webbasierte Schnittstelle ansehen können.

Lightning-Wallets

Der Begriff Lightning-Wallet ist etwas missverständlich, weil er eine Vielzahl von Komponenten beschreibt, die in einer Benutzerschnittstelle kombiniert werden. Die gängigen Komponenten einer Lightning-Wallet-Software umfassen:

einen Schlüsselspeicher (engl.

Keystore

), der »Geheimnisse« (engl.

Secrets

) wie etwa private Schlüssel vorhält,

eine LN-Node (Lightning-Node), die wie oben erwähnt mit dem Peer-to-Peer-Netzwerk kommuniziert,

eine Bitcoin-Node, die Blockchain-Daten speichert und mit anderen Bitcoin-Nodes kommuniziert,

eine Datenbank mit einer »Karte« der Nodes und Kanäle, die im Lightning-Netzwerk angemeldet sind,

einen Kanalmanager, der LN-Kanäle öffnen und schließen kann, sowie

ein System, das einen Pfad verbundener Kanäle zwischen der Quelle einer Zahlung und ihrem Ziel findet.

Eine Lightning-Wallet kann all diese Funktionen übernehmen, d.h. als »vollwertige« Wallet fungieren, ohne auf Dienste von Drittanbietern angewiesen zu sein. Eine oder mehrere dieser Komponenten können (ganz oder teilweise) von Drittanbieterdiensten abhängig sein, die diese Funktionen übernehmen.

Eine Schlüsselfrage (ja, ein Wortspiel) ist dabei, ob die Schlüsselspeicherfunktion intern vorhanden oder ausgelagert ist. Bei Blockchains bestimmt die Kontrolle der Schlüssel über die Kontrolle der Mittel, was sich im Mantra »deine Schlüssel, deine Coins; nicht deine Schlüssel, nicht deine Coins« widerspiegelt Jede Wallet, die die Verwaltung der Schlüssel auslagert, wird als depotführende (engl. custodial) Wallet bezeichnet, weil eine dritte Partei als Depotverwalter die Kontrolle über die Mittel des Nutzers hat, nicht der Nutzer selbst. Bei einer eigenverwahrenden Wallet ist der Schlüsselspeicher hingegen Teil der Wallet, und die Schlüssel werden direkt vom Nutzer kontrolliert. Der Begriff »eigenverwahrende Wallet« zeigt nur an, dass der Schlüsselspeicher lokal vorgehalten und vom Benutzer kontrolliert wird. Dennoch können andere Komponenten der Wallet ausgelagert und auf vertrauenswürdige dritte Parteien angewiesen sein.

Blockchains, insbesondere offene Blockchains wie Bitcoin, versuchen, das Vertrauen in dritte Parteien zu minimieren oder sogar auszuschließen und die Nutzer zu stärken. Das wird häufig als »vertrauensfreies« Modell bezeichnet, auch wenn es der Begriff »reduziertes Vertrauen« vielleicht besser träfe. Bei diesen Systemen vertraut der Nutzer einer Software und nicht dritten Parteien. Die Frage der Kontrolle über die Schlüssel ist daher eine grundsätzliche Erwägung bei der Wahl einer Lightning-Wallet.

Jede andere Komponente einer Lightning-Wallet führt zu ähnlichen Erwägungen in Bezug auf das Vertrauen. Stehen alle Komponenten unter der Kontrolle des Nutzers, wird das nötige Vertrauen in dritte Parteien reduziert, und der Nutzer erhält maximale Macht. Natürlich bringt das auch einen direkten Nachteil mit sich, da mit der Macht die entsprechende Verantwortung für die Verwaltung komplexer Software einhergeht.

Jeder Nutzer muss seine technischen Fähigkeiten bedenken, bevor er sich für eine bestimmte Art von Lightning-Wallet entscheidet. Wer über solide technische Fähigkeiten verfügt, sollte eine Lightning-Wallet wählen, bei der alle Komponenten der direkten Kontrolle des Nutzers unterstehen. Technisch weniger bewanderte Nutzer, die ihr Vermögen kontrollieren wollen, sollten eine eigenverwahrende Lightning-Wallet wählen. Vertrauen geht in diesen Fällen auch oft mit Privatsphäre einher. Entscheiden Nutzer, einen Teil der Funktionalität an eine dritte Partei auszulagern, geben sie auch einen Teil ihrer Privatsphäre auf, weil die dritte Partei einige Informationen über sie erhält.

Diejenigen, die schließlich Einfachheit und Bequemlichkeit suchen und dabei Kontroll- und Sicherheitsverlust in Kauf nehmen, sollten eine depotführende Lightning-Wallet wählen. Das ist die technisch einfachste Lösung, untergräbt aber das Vertrauensmodell von Kryptowährungen und sollte daher nur ein erster Schritt in Richtung mehr Kontrolle und Eigenständigkeit sein.

Wallets lassen sich auf unterschiedliche Art und Weise charakterisieren und kategorisieren. Die wichtigsten Fragen in Bezug auf eine bestimmte Wallet sind:

Besitzt diese Lightning-Wallet eine vollständige Lightning-Node, oder nutzt sie eine Lightning-Node einer dritten Partei?

Besitzt diese Lightning-Wallet eine vollständige Bitcoin-Node, oder nutzt sie eine Bitcoin-Node einer dritten Partei?

Speichert diese Lightning-Wallet ihre Schlüssel unter der Kontrolle des Nutzers ab (Eigenverwahrung), oder werden die Schlüssel von einem externen Verwahrer gehalten?

Nutzt eine Lightning-Wallet die Lightning-Node einer dritten Partei, entscheidet die Lightning-Node dieser dritten Partei, wie mit Bitcoin kommuniziert wird. Die Lightning-Node einer dritten Partei zu nutzen, bedeutet daher auch, dass man die Bitcoin-Node einer dritten Partei nutzt. Nur wenn die Lightning-Wallet eine eigene Lightning-Node nutzt, können Sie zwischen einer vollständigen Bitcoin-Node und der Bitcoin-Node einer dritten Partei wählen.

Auf der höchsten Abstraktionsebene sind die erste und die dritte Frage die wichtigsten. Aus diesen zwei Fragen können wir vier mögliche Kategorien ableiten. Wir können diese vier Kategorien in einen Quadranten eintragen, wie in Tabelle 2-1 geschehen. Bedenken Sie aber, dass das nur eine Möglichkeit ist, Lightning-Wallets zu kategorisieren.

Tabelle 2-1: Lightning-Wallets-Quadrant

Volle Lightning-Node

Drittpartei-Lightning-Node

Eigenverwahrung

F1: Hohes technisches Wissen, geringstes Vertrauen in Drittpartei, höchste Kontrolle.

F2: Unterdurchschnittliches technisches Wissen, unterdurchschnittliches Vertrauen in Drittpartei, eine gewisse Kontrolle.

Depotverwahrung

F3: Überdurchschnittliches technisches Wissen, überdurchschnittliches Vertrauen in Drittparteien, eine gewisse Kontrolle.

F4: Geringes technisches Wissen, hohes Vertrauen in Drittparteien, wenig Kontrolle.

Quadrant 3 (F3), wo eine vollständige Lightning-Node verwendet wird, die Schlüssel aber von einem Verwahrer gehalten werden, ist momentan nicht üblich. Zukünftige Wallets aus diesem Quadranten könnten dem Nutzer die betrieblichen Aspekte seiner Node überlassen und gleichzeitig den Zugriff auf die Schlüssel an eine dritte Partei delegieren, die hauptsächlich Cold Storage nutzt.

Lightning-Wallets können auf unterschiedlichen Geräten installiert werden, einschließlich Laptops, Servern und Mobiltelefonen. Um eine vollständige Lightning-Node zu betreiben, benötigen Sie einen Server oder einen Desktop, weil Mobiltelefone und Laptops in Bezug auf Kapazität, Verarbeitungsleistung, Akkulaufzeit und Konnektivität nicht leistungsfähig genug sind.

Die Kategorie »Drittpartei-Lightning-Nodes« lässt sich noch einmal unterteilen:

Leichtgewichtig