Name: Lightning Dienstleister als Alternative zu Neobanken?
Price: 0.99 EUR
Availability: InStock
Author: Yannic Fraebel
ISBN: 9783346818492

Der technologische Fortschritt verändert die globalen Finanzstrukturen rasant. Die Informations- und Kommunikationstechnologie treibt die Digitalisierung von Finanzdienstleistungen weiter voran. Insbesondere betrifft die Veränderung die historisch gewachsenen Zahlungsinfrastrukturen und ihre Akteure. Zu ihnen zählen Neobanken, die heutzutage als Vorreiter innovativer Finanztechnologie gelten. Abseits dieses Digitalisierungstrends hat sich parallel mit der Schaffung einer Internetwährung eine neue Finanzwelt aufgetan, die im Kern dezentral ist. Das Ökosystem der Internet-Währung Bitcoin ist ein Vorbote dieser dezentralen Finanzwelt. Die fortschreitende Miniaturisierung und die vollkommene Digitalisierung der Bitcoin-Technologie ermöglicht die weltweit gleichberechtigte Teilnahme an diesem Kryptotransaktionssystem. Ein wesentlicher Bestandteil des Systems sind Lightning Nodes, die im Verbund Netzwerke aus Zahlungskanälen bilden. Professionell betrieben werden sie von Lightning Service Providern, deren operative Tätigkeiten das Potenzial des vernetzten Internetgeldes entfalten. Diese Masterarbeit befasst sich mit der Frage, inwieweit das gerade entstehende Konzept der Lightning Service Provider eine Alternative zu Neobanken in der FinTech-Branche darstellt. Die Einschränkungen gegenwärtiger Zahlungsinfrastrukturen werden herauskristallisiert und die softwareseitigen Komponenten des emergenten Kryptotransaktionssystems beschrieben. Es wird ausführlich analysiert, wie der reibungslose Betrieb eines Lightning Nodes gelingt. Die Umsetzung eines prototypischen Lightning Nodes dient zur praxisnahen Veranschaulichung. Ferner wird das in diesem Zusammenhang bedeutsame Lightning Service Provider Modell präsentiert. Daraus wird ersichtlich, dass sich Lightning Service Provider noch in einer frühen Phase der Entwicklung befinden. Ebenso ist der Betrieb der Infrastruktur und die Integration von neuen Nutzern eine zu meisternde Herausforderung. Der interdisziplinäre Ansatz aus Technologieeinsatz und Finanzliteratur wirft einen Blick in die Zukunft, in welcher Lightning Service Provider sich zu einer Alternative zu konventionellen Anbietern entwickeln werden.

Extracto

Abstract

Advances in technology are rapidly changing global ﬁnancial structures. Information and communications technology continues to drive the digitization of ﬁnancial services. In particular, the change aﬀects the historically grown payment infrastructures and their operators. Among them are neobanks, which are now seen as pioneers of innova- tive ﬁnancial technology. Away from this digitization trend, a new ﬁnancial world has emerged in parallel with the creation of internet currency, which is decentralized at its core. The ecosystem of the Bitcoin currency is a forerunner of this decentralized ﬁnan- cial world. The ongoing miniaturization and complete digitization of Bitcoin technology enables equal participation in this crypto-transaction system worldwide. An essential part of the system are Lightning Nodes, which form interconnected payment channel networks. They are professionally maintained by Lightning Service Providers, whose operational activities unleash the potential of bitcoin. This master thesis explores the emerging concept of Lightning Service Providers as an alternative to neobanks in the FinTech industry. The limitations of current payment infrastructures are described, as are the software-side components of the nascent crypto-transaction system. A detailed demonstration of how to successfully run a Lightning Node in a frictionless manner is provided. The implementation of a prototypical Lightning Node serves as a practical example. Furthermore, the Lightning Service Provider Model, which is signiﬁcant in this context, is presented. This shows that Lightning Service Providers are still in an early phase. Likewise, operating the infrastructure and integrating new users is a chal- lenge to be mastered. The interdisciplinary approach from the use of technology and ﬁnance literature gives a glimpse into the future, in which Lightning Service Providers will eventually transform into a real alternative to conventional structures.

Keywords:Bitcoin, Lightning Network, Lightning Service Provider, Lightning Node, Routing Node, Node Operation, Crypto Transaction System, Payment Infrastructure, Miniaturization, CeFi, DeFi, Blockchain, Cryptocurrency, Neobank, Financial Techno- logy.

Kurzfassung

Der technologische Fortschritt verändert die globalen Finanzstrukturen rasant. Die Informations- und Kommunikationstechnologie treibt die Digitalisierung von Finanz- dienstleistungen weiter voran. Insbesondere betriﬀt die Veränderung die historisch ge- wachsenen Zahlungsinfrastrukturen und ihre Akteure. Zu ihnen zählen Neobanken, die heutzutage als Vorreiter innovativer Finanztechnologie gelten. Abseits dieses Digitalisie- rungstrends hat sich parallel mit der Schaﬀung einer Internetwährung eine neue Finanz- welt aufgetan, die im Kern dezentral ist. Das Ökosystem der Internet-Währung Bitcoin ist ein Vorbote dieser dezentralen Finanzwelt. Die fortschreitende Miniaturisierung und die vollkommene Digitalisierung der Bitcoin-Technologie ermöglicht die weltweit gleich- berechtigte Teilnahme an diesem Kryptotransaktionssystem. Ein wesentlicher Bestand- teil des Systems sind Lightning Nodes, die im Verbund Netzwerke aus Zahlungskanälen bilden. Professionell betrieben werden sie von Lightning Service Providern, deren ope- rative Tätigkeiten das Potenzial des vernetzten Internetgeldes entfalten. Diese Master- arbeit befasst sich mit der Frage, inwieweit das gerade entstehende Konzept der Light- ning Service Provider eine Alternative zu Neobanken in der FinTech-Branche darstellt. Die Einschränkungen gegenwärtiger Zahlungsinfrastrukturen werden herauskristallisiert und die softwareseitigen Komponenten des emergenten Kryptotransaktionssystems be- schrieben. Es wird ausführlich analysiert, wie der reibungslose Betrieb eines Lightning Nodes gelingt. Die Umsetzung eines prototypischen Lightning Nodes dient zur praxisna- hen Veranschaulichung. Ferner wird das in diesem Zusammenhang bedeutsame Light- ning Service Provider Modell präsentiert. Daraus wird ersichtlich, dass sich Lightning Service Provider noch in einer frühen Phase der Entwicklung beﬁnden. Ebenso ist der Betrieb der Infrastruktur und die Integration von neuen Nutzern eine zu meisternde Herausforderung. Der interdisziplinäre Ansatz aus Technologieeinsatz und Finanzlitera- tur wirft einen Blick in die Zukunft, in welcher Lightning Service Provider sich zu einer Alternative zu konventionellen Anbietern entwickeln werden.

Stichwörter:Bitcoin, Lightning Netzwerk, Lightning Service Provider, Lightning No- de, Routing Node, Nodebetrieb, Kryptotransaktionssystem, Zahlungsverkehr, Zahlungs- infrastruktur, Miniaturisierung, CeFi, DeFi, Blockchain, Kryptowährung, Neobank, Fi- nanztechnologie

Inhaltsverzeichnis

Erklärung Abstract Kurzfassung

1 Einleitung

1.1 Motivation

1.2 Aufgabenstellung & Ziel

1.3 Methodik & Durchführung

2 Stand gegenwärtiger Zahlungsinfrastrukturen

2.1 Entstehungsgeschichte

2.1.1 Der Wandel der IT-Systeme

2.1.2 Der Beginn der FinTech-Revolution

2.1.3 Das Entstehen von Neobanken

2.2 Wichtige Begriﬀe & Deﬁnitionen

2.2.1 Dimensionen des Zahlungsverkehrs

2.2.2 Clearing-Systeme

2.2.3 Auslandzahlungsverkehr

2.2.4 Zahlungsdienstleister

2.3 Einschränkungen gegenwärtiger Finanz-/Zahlungsinfrastrukturen

2.3.1 Politisierung & fehlende Neutralität

2.3.2 Kreditbasierte Systemrisiken

2.3.3 Finanzielle Inklusion

2.3.4 Unwirtschaftliche Kleinstbetragszahlungen

2.3.5 Datenhandel & -missbrauch

2.4 Quintessenz heutiger Strukturen

3 Lightning Nodes

3.1 Abgrenzung & Analogie

3.1.1 Einordnung in DeFi-Technologien

3.1.2 Digitale Bargeldzahlungen

3.1.3 Analogie zum traditionellen Zahlungsverkehr

3.2 Node-Architektur & Terminologien

3.2.1 Struktur des Kryptotransaktionssystems

3.2.2 Fairness-Protokoll

3.2.3 Aufbau eines Lightning Nodes

3.2.4 Software-Architektur

3.2.5 Populäre Software-Implementierungen

3.2.6 Hardware

3.2.7 Vorteile durch Miniaturisierung

3.3 Populäre Node-Architekturen

3.3.1 MyNode

3.3.2 Raspiblitz

3.3.3 Umbrel

3.4 Verbreitung verschiedener Nodearten

4 Node Implementierung

4.1 Zahlungskanäle

4.2 Ausgewählte Software-Architektur

4.2.1 Betriebssystem

4.2.2 Orchestrierung der Dienste

4.2.3 Installationsvoraussetzungen

4.3 Konﬁguration

4.3.1 Konﬁgurationsdatei

4.3.2 Node-Informationen

4.3.3 Konﬁgurationsszenarien

4.4 Inbetriebnahme

4.4.1 Deﬁnition optimaler Kriterien

4.4.2 Praxisnahe Umsetzung der Kriterien

4.5 Operative Risiken

4.5.1 Hot Wallet Risiko

4.5.2 Hardwarerisiko

4.5.3 Betriebssystem: Umbrel-speziﬁsche Risiken

4.5.4 Verlustrisiko des SCB

4.5.5 Risiken durch DoS-Angriﬀe

4.6 Sicherheit & Prävention

4.6.1 Remote Signing

4.6.2 Hardwaresicherheit

4.6.3 Sicherung der Backups

4.6.4 DoS-Schutz

4.7 Syllabus

Lightning Service Provider Modell

5.1 Interview

5.1.1 Vorgehensweise

5.1.2 Inhaltsanalyse

5.1.3 Resultate

5.2 Wortherkunft

5.2.1 Begriﬀ

5.2.2 Funktion

5.3 Unterschiede von LSP

5.3.1 Möglichkeiten zur Unterteilung von LSP

5.3.2 Zentralität als Unterscheidungskriterium

5.4 Herausforderungen & Lösungsansätze

5.4.1 Liquiditätsmanagement & Kapitalallokation

5.4.2 Verwaltung von Nutzerkonten

5.5 Vergleich von LSP und Neobank.

5.5.1 Gegenüberstellung.

5.5.2 Vergleichskriterien

6 Ergebnisse & Fazit

6.1 Reﬂexion der Ergebnisse

6.2 Ausblick & Implikationen für die Praxis

6.3 Weitere Forschungsarbeiten

A LND-Konﬁgurationsdatei

B Interview Transkript

Quellenverzeichnis

Abbildungsverzeichnis

1.1 Zuwachs der Kapazität des Lightning Netzwerks bis September 2021 [67]

2.1 Verlauf und Prognose von Neobankingnutzern [75]

2.2 Dimensionen des Zahlungsverkehrs nach Metzger [63]

2.3 Arten von Clearingsystemen nach Heldt et al. [43]

2.4 Illustrativer Ablauf einer Kreditkartenzahlung nach Schindele [70]

2.5 Weltweit allokierte Währungsreserven (Q2 2021) [38]

3.1 Abstrakte Darstellung eines LN-Node Softwarestacks

3.2 Verteilung nach Lightning Node Implementierung [21, S. 131]

4.1 Abstrakte Darstellung eines Umbrel-Systems [95]

4.2 Ein Raspberry Pi 4 und seine Anschlussmöglichkeiten [102]

4.3 Illustration des zirkulären Rebalancingsvon Antonopolous et al. [3, S. 202]

4.4 Weltweiter Rang des Prototypen auf Lightning Terminal [49]

5.1 Graﬁsche Darstellung der Tätigkeitsfelder eines LSP [79]

5.2 Wachsender Anteil der oberen 10% Nodes über das Routing im Netzwerk in Prozent im Zeitraum von April 2019 bis Januar 2021 [20, S. 2]

5.3 Oﬃzielle Graﬁk der Funktionsweise von LNDHub [53]

Tabellenverzeichnis

2.1 Übersichtsvergleich zwischen traditionellen Banken und Neobanken [73]

2.2 Top 10 Länder mit höchster Quote an fehlendem Zugang zu Bankkonten [81]

3.1 Dimensionen des Zahlungsverkehrs im Bitcoin-System

3.2 Funktionen der einzelnen Lightning-Protokollschichten und zugehörige BOLT-Speziﬁkationsnummer nach Antonopolous et al. [3, S. 209]

3.3 Verhältnis von Lightning Wallets zu Lightning Nodes nach Antonopoulus et al. [3, S. 40]

4.1 Konnektivitätsinformationen des Lightning Nodes

4.2 Etablierte Zahlungskanäle mit ID, Alias und Kapitalisierung

5.1 Tabellarischer Vergleich von LSP und Neobanken in Anlehnung an das DeFi-Vergleichsmodell der Wharton Business Schoolder University of Pennsylvania [17]

Abkürzungsverzeichnis

ACHAutomated Clearing House

APIApplication Programming Interface ASICApplication Speciﬁc Integrated Circuit BICBusiness Identiﬁer Code

BOLTBasis of Lightning Technology

BWährungssymbol des Bitcoin Netzwerks

CeFiCentralized Finance DeFi Decentralized Finance DNSDomain Name Server DoSDenial of Service

EWGEuropäische Wirtschaftsgemeinschaft FinTechFinancial Services and Technology HDDHard Disk Drive

HTLCHash Time Lock Contract

IBDInitial Block Download

IKTInformations- und Kommunikationstechnologie

IWFInternationaler Währungsfonds JSONJavaScript Object Notation KWGKreditwesengesetz

KYCKnow-Your-Customer, Verfahren zur Identiﬁkation von Kunden

LANLocal Area Network

LDKLightning Development Kit

LNDLightning Network Daemon LNRR Lightning Network Reference Rate LSPLightning Service Provider

MITMassachusetts Institute of Technology

NodeKnoten im Netzwerk

Oﬀ-ChainTransaktionen werden nicht auf der Blockchain, sondern auf dem Lightning Netzwerk oder bei Dienstleistern durchgeführt

On-ChainTransaktionen werden auf der Blockchain erfasst

OSOperating System

PeerKnoten mit gleicher Eigenschaft und Funktionsweise

P2PPeer-to-Peer

RAMRandom Accessed Memory (Arbeitsspeicher)

RESTRepresentational State Transfer

RLRust-Lightning

RPCRemote Procedure Call

Satoshieineinhundertmillionstel Bitcoin, kleinste Bitcoineinheit

SCBStatic Channel Backup SEPA Single Euro Payments Area SSDSolid State Drive

SSHSecure Shell

SWIFTSociety for Worldwide Interbank Financial Telecommunication

TCP/IPTransmission Control Protocol / Internet Protocol

TLSTransport Layer Security

TorThe Onion Router

TVLTotal Value Locked

TXTransaktionen

UPSUninteruptable Power Supply

VPSVirtual Private Server

WalletSoftware zur Verwaltung der Gelder

ZVKZahlungsverkehr

Kapitel 1

Einleitung

1.1. Motivation

Am 09. Juni 2021 hat El Salvador La Ley Bitcoin(wörtlich: das Bitcoin-Gesetz) ver- abschiedet. Ein Gesetz, das El Salvador am 07. September 2021 weltweit zum ersten Land deklarierte, welches Bitcoin oﬃziell als Landeswährung einführte. Seit diesem Da- tum gilt, zusätzlich zum US-Dollar, Bitcoin als gesetzliches Zahlungsmittel. Die radikale Krypto-Initiative wurde von El Salvadors Präsident Bukele eingeleitet und führte zu ei- nem weitreichenden medialen Interesse an der Umsetzung des Landes. Dieser Schritt gilt als internationaler Meilenstein in der Akzeptanz des Kryptogeldes: Einer Währung mit eigenen Regeln, einer eigenen Geldpolitik und einem eigenen durch Software imple- mentierten Regelwerk.

Eine allgemeine Stellungnahme bezog unter anderem auch der Internationale Wäh- rungsfonds (IWF) in seinem Beitrag Cryptoassets as National Currency? A Step Too Far . Der IWF ist der Ansicht, dass die staatliche Akzeptanz von Bitcoin „in den meisten Fällen die Risiken und Kosten den potenziellen Nutzen überwiegen“ [44]. Des Weiteren wird die Einschätzung vertreten, dass sich „Kryptowährungen in Ländern mit stabilen Inﬂationsraten und Wechselkursen“ [44], wie im Falle El Salvadors, aufgrund fehlender Anreize für Haushalte und Unternehmen nicht durchsetzen.

Massive Kritik an der neuen Gesetzgebung erfolgte auch von Steve H. Hanke, re- nommierter Professor und Co-Direktor für angewandte Wirtschaftswissenschaften der John Hopkins Universität. Im seinem Arbeitspapier Bukele’s Bitcoin Blunderweist Prof. Hanke gemeinsam mit seinen Co-Autoren nach, dass das Kryptogeld aufgrund fehlender privatwirtschaftlicher Akzeptanz sowie marginalen Kosteneinsparungen zum Scheitern verurteilt sei [42]. Besonderes Augenmerk wird in diesem Arbeitspapier auf ausländi- sche Rücküberweisungen gelegt, welche rund 21% des Bruttoinlandsprodukts von El Salvador ausmachen [42, S. 4].

Hingegen soll laut Angaben der Regierung El Salvadors mithilfe der Bitcoin-Techno- logie eine langfristig bessere und nahezu kostenlose Zahlungsinfrastruktur für Rücküber- weisungen bereitstehen [22]. Zum Tragen kommt hierbei ein staatlicher Treuhandfond [69], welcher anfangs mit etwa $150 Mio. US-Dollar gedeckt ist, um den Wechsel von US- Dollar in Bitcoin und vice versa zu ermöglichen. Dadurch ist die Option gegeben, dass alle privatwirtschaftlichen als auch staatlichen Akteure die neue Währung akzeptieren und einsetzen können.

Abseits der Kritik an der Wirtschaftlichkeit der neuen Legislative taucht die Fra- ge auf, ob die technische Umsetzung ausreichend leistungsfähig ist. In seiner aktuellen Form verarbeitet das Bitcoin-Netzwerk lediglich ein paar Transaktionen pro Sekunde, was für eine Volkswirtschaft von ca. 6,5 Mio. Menschen in El Salvador nicht ausreichend ist [66]. Das zentralamerikanische Land wird somit zugleich das erste Land sein, welches den Zahlungsverkehr hauptsächlich über eine Layer-2-Technologie, dem Bitcoin Light- ning Netzwerk, abwickelt. Hierfür stellt der zentralamerikanische Staat einerseits eine öﬀentliche Bezahl-App namens Chivo-Wallet[41] bereit, andererseits wird der volks- wirtschaftliche Zahlungsverkehr dadurch auch an die interoperable, global zugängli- che Bitcoin-Lightning-Technologie angebunden. Zahlungen in der mobilen App können alternativ auch ausschließlich in US-Dollar abgewickelt werden, da durch die Anbin- dung an den bereits erwähnten Treuhandfonds lediglich die Zahlungsabwicklung über die Lightning Technologie stattﬁndet. Neben El Salvador haben auch weitere latein- amerikanische Länder ihr Interesse an dem neuartigen Zahlungssystem bekundet, was den internationalen Fokus stark auf die Adoption und Weiterentwicklung des Lightning Netzwerks richtet.

Allgemein bekannt ist, dass das Lightning Netzwerk keine Beschränkungen in der möglichen Transaktionskapazität besitzt und alle Zahlungen nahezu in Echtzeit abwi- ckelt. Seit Beginn des Jahres 2021 ist der öﬀentliche Teil des Lightning Netzwerk (engl. Public Lightning Network ) in den ersten neun Monaten von rund ≈1000 Bitcoin auf über ≈2400 Bitcoin angewachsen¹, was aktuell einem kumulierten Netzwerkvolumen ²

von etwa $115 Mio. USD³, wie in Abbildung dargestellt, entspricht.

Abb. In Leseprobe nicht enthalten.

Abbildung 1.1:Zuwachs der Kapazität des Lightning Netzwerks bis September 2021 [

¹Aufgrund der Beschaﬀenheit des Netzwerk können nur Annäherungen erfasst werden

²In dezentralen Netzwerken auch Total-Value-Locked (TVL) genannt

³Wechselkurs zum Zeitpunkt 01. September 2021: ≈$47.000/B

Neben dem Volumen im Lightning Netzwerk, welches ebenso der verfügbaren Liqui- dität entspricht, deuten noch weitere Metriken auf eine verstärkte Netzwerkeﬀektdy- namik hin. So sind beispielsweise die Anzahl der öﬀentlichen Netzwerkknoten (Nodes) von Beginn des Jahres von etwa 5000 Nodes auf über 15.000 Nodes angestiegen (2021) [68]. Hinter jedem einzelnen Node kann weiterhin eine beliebige Anzahl an Konten (Ac-counts/Wallets) stehen, welche Zahlungen über diesen Node tätigen. Nodebetreiber, welche die Zahlungsinfrastruktur für Nutzer anbieten, werden Lightning Service Pro- vider (LSP) genannt. Das bereits erwähnte Chivo-Wallet der Regierung El Salvadors dient beispielsweise als LSP für die Bürger des Landes.

Besonders interessant an dieser technologischen Entwicklung ist nicht nur die schnel- le Verbreitung in realwirtschaftlichen Szenarien, sondern auch die Möglichkeit für Pri- vatpersonen und Unternehmen mit entsprechendem Fachwissen zu einem Lightning- as-a-Service-Anbieter zu werden. Der technische Fortschritt im Zahlungsverkehr stellt folglich im internationalen als auch nationalen Umfeld eine disruptive Konkurrenz zu traditionellen Banken- und Zahlungssystemen dar. An diesem Punkt knüpft diese Mas- terarbeit an, indem sie die Frage stellt:

1.2. Sind Lightning Service Provider eine Alternative zu Neobanken in der FinTech-Branche?

1.3. Aufgabenstellung & Ziel

Ziel dieser wissenschaftlichen Arbeit ist, das Modell von Lightning Service Providern zu untersuchen und eine geeignete aktuelle Bestandsaufnahme zu erstellen. Hierbei kristal- lisieren sich mehrere Unterziele heraus. Einerseits wird ein aufbereiteter Überblick über den aktuellen Stand des stetig wachsenden Lightning-Ökosystems gegeben. Erkenntlich wird, wie die technologische Entwicklung von Mainframe-Rechnern bis zu Lightning Nodes verlief. Weiterhin wird exemplarisch ausgeführt, welche Unternehmen und Soft- wareanwendungen sich bereits etabliert haben und welche Potentiale in dem neuartigen, internetgetriebenen Banking-as-a-Serviceliegen.

Andererseits wird prototypisch eine Implementierung eines Lightning Nodes vorge- nommen, um die softwareseitigen Details des Zahlungssystems intensiv zu beleuchten. Insbesondere der Aufbau der Software-Architektur und das interoperable Design werden anhand des Prototypen betrachtet. Es werden bestmögliche Vorgehensweisen zur Kon- ﬁguration und Inbetriebnahme des Nodes abgeleitet, welche sowohl von Privatpersonen als auch Unternehmen verwendet werden können, die sich erstmalig mit dem Krypto- transaktionssystem befassen. Auch soll die vorliegende Ausarbeitung als Anknüpfungs- punkt für zukünftige Arbeiten dienen, bei denen über einen Einsatz der Technologie diskutiert wird. Ausgehend von der Frage, ob Lightning Service Provider eine Alterna- tive zu Neobanken darstellen, lassen sich folgende zwei untergeordnete Forschungsfragen ableiten:

1.3.1. Wie ermöglichen Lightning Service Provider die Integration mehrerer Millionen neuer Nutzer?

1.3.2. Welche technischen Vorgehensweisen sind für den reibungslosen Betrieb der Zahlungsinfrastruktur vorteilhaft?

1.4 Methodik & Durchführung

Die vorliegende Arbeit beschäftigt sich mit einer modernen Thematik, welche zuneh- mend an Bedeutung im internationalen Finanzwesen gewinnt. Aufgrund der außerge- wöhnlichen, durch das Internet angetriebenen Dynamik sind bisher kaum Ausarbeitun- gen in klassischen Literaturanlaufstellen verfügbar. Wesentliche Quellen sind auf Grund dessen qualitative Online-Quellen, insbesondere solche, welche von oﬀenkundigen In- itiatoren, Machern und Entwicklern der neuzeitlichen Technologie verfasst werden. Aus sprachlicher Perspektive werden häuﬁg Amerikanismen verwendet, da die Namensge- bung inner- und außerhalb der Entwicklung eben diesen Sprachraum hauptsächlich um- fasst. Amerikanismen werden einmalig eingeführt sowie erläutert und ab dann gebräuch- lich im Verlauf der Arbeit verwendet. Der Autor der Arbeit bietet mittels qualitativer Empirie eine Selektion aus relevanten Informationsquellen dar, welche das ganzheitliche Verständnis des Lesers zur Thematik erweitern.

Dafür betrachten wir anfangs in Kapitel 2den Stand gegenwärtiger Zahlungsinfra- strukturen anhand konkreter Beispiele durch eine geeignete Literaturrecherche. Es wird ein Gesamtbild über den zeitgenössischen Fortschritt der Technologie gezeichnet, wel- ches explizit anhand aktueller Daten den Stand bestehender Zahlungsinfrastrukturen aufzeigt. Das Augenmerk liegt hier auf den Einschränkungen gegenwärtiger Systeme.

Kapitel 3behandelt die Struktur eines Lightning Nodes. Für die theoretische Ver- tiefung der Thematik werden grundlegende Konzepte aufgeschlüsselt. Es werden so- wohl Soft- und Hardware Voraussetzungen als auch der Aufbau der Architektur ab- strakt erläutert. Populäre Implementierungen der Node Software und weit verbreitete Node-Architekturen werden exemplarisch untereinander verglichen. Eine kurze qualita- tive Analyse des Netzwerks dient der Kontextualisierung von einzelnen Nodetypen im Verhältnis zu anderen.

Nachdem wir ein umfassendes Verständnis der Software-Komponenten aufgebaut ha- ben, wird in Kapitel 4die fallbasierte Evaluierung durch eine praxisnahe Implementie- rung eines Lightning Nodes umgesetzt. Optimale Konﬁgurationen, bewährte Verfahren als auch Betriebsanweisungen werden durch einen induktiven Ansatz erörtert. Hier- zu zählen beispielsweise ökonomische und technische Risiken, die es als Nodebetreiber zu vermeiden gilt. Die Umsetzung der technischen Vorgehensweisen wird weitgehend anhand von Shell-Skripten oder Anpassungen in ad hoc geschaﬀenen Konﬁgurationen aufgezeigt. Im Syllabus werden die bisherigen Umsetzungen subsumiert, um die For- schungsfrage nach einem reibungslosen Betrieb der Zahlungsinfrastruktur zu beantwor- ten. Gleichzeitig dient sie als Orientierungshilfe für neue Netzwerkakteure.

Anschließend widmen wir uns in Kapitel5dem Lightning Service Provider Modell. Der Fokus liegt auf der Funktion der Anbieter als strukturelle Problemlöser. Erkennt- lich wird die Notwendigkeit für aufkommende Dienstleister und welche Bedeutung sie einnehmen. Zugleich werden Denkanstöße gegeben, inwiefern Lightning Service Provi- der unterschieden werden können. Bekannte Herausforderungen, die sich teilweise aus der prototypischen Implementierung ergeben, werden mit möglichen Lösungsansätzen diskutiert. Ferner werden wirtschaftliche Anreizstrukturen wie der Referenzzinssatz des Lightning Netzwerks aufgeschlüsselt. Abschließend folgt eine ökonomisch-technische Ge- genüberstellung zwischen Neobanken und Lightning Service Providern und die Antwort auf die Forschungsfrage, wie die Integration mehrerer Millionen neuer Nutzer über LSP erfolgt.

Im letzten Kapitelfolgt eine Zusammenfassung der Erkenntnisse, welche sowohl die Interpretation der Wirtschaftlichkeit des LSP-Modells umfasst als auch die tech- nischen Entwicklungen subsummiert. Die eingangs gestellte Forschungsfrage wird aus- führlich beantwortet und es wird ein Ausblick auf weitere in diesem Zusammenhang bedeutsame Forschungsgebiete gegeben.

Kapitel 2

Stand gegenwärtiger Zahlungsinfrastrukturen

Für ein besseres Verständnis der aufkommenden technologischen Entwicklungen wird in diesem Kapitel die themeneingrenzende Historie zusammenfassend beschrieben. Der ganzheitliche Ansatz zeigt den Verlauf der Technik in einem größeren Rahmen auf. Dies hilft, spätere Entwicklungen besser zu konzeptualisieren und sie schematisch einzuord- nen. Ferner werden die Begriﬀe aus dem Finanzwesen FinTech, Neobank und Zahlungs- verkehr in ihren Entstehungskontext eingebettet. Zur Ein- und Abgrenzung der Themen liegt der Fokus auf bekannten Systemen der westlichen Staaten. Abschließend werden die Limitierungen bestehender Zahlungsinfrastrukturen aufgezeigt.

2.1. Entstehungsgeschichte

“Banking is an information-intensive industry, by which it is meant that dif- ferentiation comes exclusively from their intellectual capital and information or, in other words, their people, processes, relationships and technology.”

– Paul Griﬃths in FinTech and Its Historical Perspective[13, S. 22f]

In dem im Jahr 2021 erschienen Werk FinTech and Its Historial Perspective in The Palgrave Handbook of FinTech and Blockchainerläutert der Autor Paul Griﬃths von der Normandie Business School das Aufkommen der FinTech-Revolution und den zu- grundeliegenden historischen Kontext [13, S. 19]. Er geht der Frage nach, warum sich die FinTech-Industrie als ein vom Bankwesen unabhängiger Sektor entwickelte und wie die von der FinTech-Industrie angebotenen Dienstleistungen durch Technologie gestützt werden. Weiterhin wird die Beziehung zwischen traditionellen Banken und FinTechs durch Matousek et al. analysiert. Augenmerk liegt auf der im Laufe der Zeit entstande- nen symbiotischen Geschäftsfelder und aktuellen Daten zu diesen Trends. Die folgenden Abschnitte fassen die jahrzehntelangen Entwicklungen anhand der genannten Literatur- quellen zusammen.

2.1.1 Der Wandel der IT-Systeme

Professor Griﬃths greift die wesentlichen Entwicklungen der Informations- und Kommu- nikationstechnologie (IKT) in der westlichen Bankenbranche beginnend ab den 1970er Jahren auf. In der Zeit der 1970er und 1980er Jahre waren Großrechnersysteme (sog. Mainframe -Rechner) dominant und liefen wesentlich mit maßgeschneiderten Anwen- dungen, die „einen engen Funktionsumfang und eine schwache Integration zu anderen Anwendungen aufwiesen“ [13, S. 20]. Die verwendete Technologie war durchgängig auf die Verarbeitung großer Mengen an Daten spezialisiert, welche zunächst mit Lochkarten und später mit Magnetbändern und -platten eingegeben wurden. Hauptsächlich Ban- ken, staatliche Einrichtungen, Universitäten und große Unternehmen waren mit diesen IT-Systemen ausgestattet. Sie galten als Pioniere und Hauptanwender der Technologie. Gemeinsam war allen damaligen IT-Anwendungen, dass sie im Wesentlichen proprietär liefen und inkompatibel zu Anwendungen anderer Hersteller waren, weswegen man auch von einem „Client-Lock-In“sprach [13, S. 20].

Mit dem Aufkommen von privaten Computern, LAN-Netzwerken, ersten mobilen Geräten und besonders der relationalen Datenbank zog die IKT in den 1990er Jahren in kleinere Unternehmen und Betriebe ein. Griﬃths spricht im Zuge der „Demokratisie- rung der Technologie“ sowie der Verbreitung des Internets auch von einer „Revolution“ [13, S. 20]. Die bis dato vorherrschenden Großrechner und die zugehörige zentralisier- te Architektur gaben einen Teil ihrer Arbeit an die immer populärere Client-Server- Architektur ab. Gänzlich verschwunden sind monolithische Großrechnersysteme in der Bankenbranche jedoch bis heute nicht, da sie oft als reine Datenbankserver dienen, die große Transaktionsmengen verarbeiten. Aufgrund der Tatsache, dass Großrechnersys- teme extrem kritisch für Prozesse und Anwendungen im Bankensektor sind, war eine Migration auf neuere Rechnerarchitekturen nur schwer durchführbar. Zwar haben Ban- ken in vielen Geschäftsfeldern neue Lösungen adoptiert, aber das Rückgrat bilden nach wie vor Mainframe-Rechner [13, S. 23].

Die Trends der 2000 Jahre, wie der aufkommenden E-Commerce und die damit verbundenen Dot-Com-Blase, wurden nach Griﬃths wesentlich durch neue Paradigmen in der IT-Branche gestützt [13, S. 22]. Beispielsweise führte die Firma Oracle den Begriﬀ des Stacksein, welcher für eine verbesserte Modularität von IT-Systemen steht. Die Bedeutung der Integration von maßgeschneiderten, meist statischen Systemen schwächte sich durch den Einzug von Middleware-Kommunikation allmählich ab. Ein weiteres bedeutendes Konzept, das sich um die Jahrhundertwende herausbildete, war das der Application Programming Interface(API). Bereits einige Jahre nach ihrem Aufkommen spielten APIs eine wichtige Rolle in der FinTech-Welt, insbesondere als Ergebnis der sog. Open-Banking-Regulierung [13, S. 122].

Ab Mitte der 2000er folgten die Bestrebungen in Richtung Telefonbanking, Home- banking und Internetbanking (E-Banking) [13, S. 23f]. Paul Griﬃths führt als Gemein- samkeit aller Entwicklungen aus, dass sie den physischen Kundenkontakt verlagerten und die Kosten für Banktransaktionen weiter senkten. Er beschreibt diese Zeit in seiner Forschung als deﬁnierten Wendepunkt, indem „die Wirtschaft der westlichen Staaten fast unbemerkt von einer industriellen Wirtschaft mit überwiegend materiellen Werten zu einer wissensbasierten Wirtschaft übergegangen ist, in der immaterielle Werte gegen- über den materiellen Werten überwiegen“ [13, S. 24]. Dies war der Beginn einer „neuen Ära“, in der sich die Anwendung der Internet- und Kommunikationstechnologie radikal veränderte und in der Banken den Einﬂuss auf die Entwicklung der IKT verloren.

2.1.2 Der Beginn der FinTech-Revolution

Professor Paul Griﬃths führt drei wesentliche Gründe für das Entstehen der neuen Ära in der Bankenwelt an, welche gegen Mitte bis Ende der 2000er Jahre ¹ entstand [13, S. 30]:

• Die Finanzkrise von 2007/2008,

• bedeutende Fortschritte im Technologiesektor und

• gesellschaftliche Veränderungen mit dem Eintritt der Generation der Millennials in das Berufsleben.

Die auch als „große Rezession“ bekannte Finanzkrise von 2007/2008 veranlasste Regu- latoren und Regierungen weltweit neue Auﬂagen für Kreditinstitutionen zu beschließen, um das verlorene Vertrauen der Öﬀentlichkeit in diese Institutionen wiederherzustel- len. Das Ergebnis war eine weitaus strengere Bankenregulierung, die Banken vor große regulatorische Herausforderungen stellte. Banken wurden unter anderem verpﬂichtet konservativer zu wirtschaften und ihre Daten über Schnittstellen freizugeben². Open- Banking ermöglichte nicht nur den nahezu in Echtzeit stattﬁndenden Austausch von Daten zwischen angeschlossenen Banken, sondern insbesondere auch zu Nicht-Banken [23]. Besonders diese Öﬀnung der Schnittstellen diente der Schaﬀung eines erweiterten Wettbewerbs im Bereich der Finanztechnologie, indem es die vorhandenen Oligopole der Banken brach [13, S. 31]. Beide Entwicklungen, die Regulatorik und die Freigabe, för- derten den Aufstieg der FinTech-Branche. Der Begriﬀ FinTech setzt sich als Koﬀerwort aus den beiden Begriﬀen Financial (Services)und Technology zusammen [19, S. 2].

¹Auch Tiberius et al. ordnen den Beginn von FinTech in dieser Zeitspanne ein [19, S. 7]

²Bspw. die Open-Banking-Regulierung in Europa: Payment Services Directive2 (PSD2) [29]

Neben den regulatorischen Nachwirkungen der Finanzkrise 2007/2008 führten nach Griﬃths auch größere technologische Umbrüche zum Entstehen moderner Finanzdienst- leister. Ein technologisches Phänomen ist die omnipräsente Deﬂation der Rechnerleis- tung, auch bekannt als Moor’sches Gesetz. Durch den Einsatz von beispielsweise Cloud Computing auf der Anbieterseite und immer leistungsstärkeren Endgeräten wie mo- dernen Smartphones auf der Kundenseite wurden Möglichkeiten für Bankingdienstleis- tungen geschaﬀen, welche zuvor ohne den technologischen Fortschritt für klassische Fi- nanzdienstleister unwirtschaftlich gewesen wären. FinTech-Anbieter weisen durch ihren technischen Fortschritt einen höheren Spezialisierungsgrad im Finanzwesen auf als tradi- tionelle Banken [13, S. 89]. Sie bieten meist innovative Produkte und Dienstleistungen zu sehr geringen Kosten, die traditionelle Banken nicht leisten können [13, S. 89]. Im Laufe der letzten Jahre hat sich ein kollaboratives Modell zwischen Banken und FinTech An- bietern etabliert, welches „innovative IT-Dienstleistungen auf die FinTech-Anbieter aus- lagert“, während Banken als Kapitalgeber und Stakeholder dieser auftreten [13, S. 32]. Finanzdienstleistungen wurden dem technologieinhärenten Prozess unterzogen, der ger- ne auch als Disruptionbezeichnet wird [13, S. 89]. FinTech-Anbieter deﬁnieren seither die Art und Weise wie Finanzdienstleistungen für Endkunden zugänglich gemacht und erbracht werden.

2.1.3 Das Entstehen von Neobanken

Im Kapitel The Challenges and Competitivenes of Fintech Companies in Europe, UK and USA: An Overview in The Palgrave Handbook of FinTech and Blockchainanaly- sieren Roman Matousek und Dong Xiang in ihrer Publikation die verschiedenen Ein- ﬂussphären von FinTech [13, S. 87]. Ein Teilbereich der neu entstandenen Anbieter im FinTech-Bereich sind die sogenannten Neobanken [13, S. 89]. Diese wortwörtlichen „neu- en Banken“ legen ihren Fokus vermehrt auf das Endkundengeschäft (Retail Banking). Ihr Geschäftsmodell basiert auf der vollständigen Digitalisierung der Dienstleistungen, die es Neobanken ermöglicht, für ihre Kunden im Vergleich zu traditionellen Banken permanent verfügbar zu sein. Weiterhin besteht ihre „Unternehmensstrategie aus einer kontinuierlichen Anwendung disruptiver Innovationsprozesse“ [13, S. 99]. Das Spektrum ihrer Dienstleistungen wird wesentlich durch den Umfang bestimmt, welche in Koope- ration mit lizenzierten traditionellen Banken und im Rahmen der Aufsichtsbehörden möglich sind.

Das Alleinstellungsmerkmal einer Neobank ist, dass diese vollkommen virtuell exis- tiert und ihre Geschäfte ausschließlich online über zugehörige Anwendungen abwickelt. Sie haben keine physischen Filialen und können ihre Dienstleistungen sowohl über mo- bile als auch über Desktop-Geräte anbieten. Kunden müssen bei ihnen einen digitalen Registrierungsprozess durchlaufen, der meist über ein Smartphone erfolgt. Die Orientie- rung an einem reinen online-basierten Geschäftsmodell hilft Neobanken große Summen an Kosten einzusparen, weswegen sie ﬁnanzielle Dienstleistungen kostengünstig an Kun- den weitergegeben können.

In der Tabelle sind Eigenschaften traditioneller und neuer Banken aufgelistet.

Abb. In Leseprobe nicht enthalten.

Tabelle2.1:Übersichtsvergleich zwischen traditionellen Banken und Neobanken [73]

Die Kosteneinsparungen gepaart mit mobilen Anwendungen führen zu einer verbes- serten Kundenerfahrung im Banking Bereich und haben zu einem weltweiten explosiven Kundenzuwachs für Neobanken innerhalb der letzten Jahre geführt. So bedienen Neo- banken laut Statista [75] aktuell rund ca. 145 Mio. Nutzer weltweit und werden Pro- gnosen nach bis zum Jahr 2025 rund ca. 345 Mio. Kunden versorgen. Die Prognose von Statista ist in Abbildung 2.1 dargestellt. Neobanken sind durch ihr rasantes Wachstum zu einem strategischen Vorreiter für traditionelle Banken geworden und untergraben ihre bis dato exklusive Stellung im Retail Banking.

Abb. In Leseprobe nicht enthalten.

Abbildung2.1:Verlauf und Prognose von Neobankingnutzern [75]

³Übersetzt und angepasst

2.2. Wichtige Begriﬀe & Deﬁnitionen

In diesem Abschnitt werden wichtige Begriﬀe im Zusammenhang mit dem Zahlungsver- kehr näher erläutert. Das umfasst die Arten des Zahlungsverkehrs, die Clearing-Systeme, den Auslandzahlungsverkehr und die Deﬁnition von Zahlungsdienstleistern. Eine klare Unterscheidung der Begriﬀe hilft, in späteren Abschnitten Lightning Nodes besser zu schematisieren.

2.2.1. Dimensionen des Zahlungsverkehrs

Nach Metzger, Direktor der deutschen Bundesbank und Leiter des Zentralbereichs Zah- lungsverkehr und Abwicklungssysteme, umfasst der Zahlungsverkehr allgemein die

„Summe aller Zahlungsvorgänge zwischen Wirtschaftssubjekten innerhalb einer Volkswirtschaft (nationaler Zahlungsverkehr) oder zwischen verschie- denen Volkswirtschaften“ [58].

Letzterer wird deshalb auch als Auslandszahlungsverkehr ⁴ bezeichnet. Eine verkürzte, sinngemäße Deﬁniton ﬁndet sich auch im Kompakt-Lexikon Wirtschaft [18, S. 627]. Der Zahlungsverkehr lässt sich nach oﬃzieller Gabler Deﬁnition in drei Dimensionen untergliedern [58]:

2.2.1.1. Nach der Art des verwendeten Zahlungsmediums ,

2.2.1.2. nach der Verwendung von Belegensowie

2.2.1.3. nach der Dringlichkeit und Abwicklungder Zahlung.

In Abbildung stellt.

ist eine Visualisierung der Dimensionen des Zahlungsverkehrs darge-

Abb. In Leseprobe nicht enthalten.

Abbildung2.2:Dimensionen des Zahlungsverkehrs nach Metzger [63]

Art des verwendeten Zahlungsmediums

Die drei Formen des Zahlungsmediums umfassen den baren Zahlungsverkehr (Barzah- lung), den bargeldsparenden Zahlungsverkehr (halbbarer Zahlungsverkehr) und den un- baren Zahlungsverkehr (bargeldloser Zahlungsverkehr) [58].

Verwendung von Belegen

Die Verwendung von Belegen setzt sich aus beleggebundenen und beleglosen Zahlungen zusammen. Beleglose Zahlungen werden auch unter dem Begriﬀ elektronischer Zahlungs- verkehr zusammengefasst. Die letzte Dimension ist die Dringlichkeit und Abwicklung der Zahlung. Die zwei Subformen sind der Individualzahlungsverkehr und der Massen- zahlungsverkehr.

2.2.2. Dringlichkeit & Abwicklung der Zahlung

Systeme für den Individualzahlungsverkehr werden auch als Großbetragszahlungssys- teme bezeichnet. Laut Deutscher Bundesbank bilden sie die Basis für die Zahlungs- infrastruktur im Euroraum und wickeln meist große, zeitkritische Interbanken- und Kundenzahlungen ab [27]. Individualzahlungen werden in Bruttozahlungssystemen oder alternativ in Nettozahlungssystemen abgerechnet. Nettozahlungssysteme schonen im Gegensatz zu Bruttozahlungssystemen die Liquidität der Teilnehmer, da in diesen Sys- temen eine Aufrechnung der Salden erfolgt [27]. Ein Beispiel für ein Individualzahlungs- verkehrssystem ist das Trans-European Automated Real-time Gross Settlement Express Transfer System , kurz TARGET2-System.

Die deutsche Bundesbank deﬁniert den elektronischen Massenzahlungsverkehr als

„eine Zahlungsverkehrsplattform zur kostengünstigen Abwicklung nicht eiliger, natio- naler und grenzüberschreitender Zahlungen (im SEPA-Raum) wie zum Beispiel Über- weisungen und Lastschriften“ [28]. Weiterhin werden privatwirtschaftliche Akteure wie Zahlungsdienstleister über das System angebunden. Im Vergleich zum Individualzah- lungsverkehr werden im Massenzahlungsverkehr vor allem kleine Zahlungen zwischen Privatpersonen abgewickelt.

2.2.3. Clearing-Systeme

Deﬁnition & Funktion

Generell nehmen im Zahlungsverkehr die Clearing- und Settlement-Systeme eine bedeut- same Stellung ein, da die Abwicklung von Zahlungsmitteln abhängig von involvierten Parteien auf verschiedene Arten erfolgen kann. Das Clearing, sinngemäß die Verrech- nung von gegenseitigen Geldforderungen, leitet sich wörtlich aus dem Englischen to clear ab und ist der Wortherkunft nach gleichbedeutend mit „frei von Schulden“ [39]. Der Clearing-Prozess ist notwendig, um einen eﬃzienten Geschäftsverkehr zu ermög- lichen und den beteiligten Parteien die Gewissheit zu geben, dass ihre Transaktionen ordnungsgemäß abgewickelt werden [18, S. 106]. Die Zahlungsverkehrsabwicklung von Clearing-Systemen zwischen Banken wird nach Heldt et al. auf mehrere Ebenen un- terteilt [43]. Zum Einen gibt es das interne Clearing (Inhouse-Clearing), wobei „die Verrechnung zwischen Filialen einer Bank oder innerhalb einer Institutsgruppe (z. B. im Kreditbanken-, Sparkassen- oder Genossenschaftssektor) [43]“ stattﬁndet.

Zum Anderen existiert die Verrechnung über größere Kreditinstitute im gegenseiti- gen Austausch über Zentralbankkonten. Auf nationaler Ebene gibt es weiterhin die Mög- lichkeit der Auf- und Verrechnung über Ländergrenzen hinweg, wie dies beispielsweise im Rahmen des Europäischen Systems der Zentralbanken (ESZB) über das Echtzeit- Bruttozahlungsverkehrssystem für TARGET2-Salden geschieht [60].

Arten von Clearing-Systemen

In Abbildung 2.3 ⁶ ﬁndet sich eine graﬁsche Unterscheidung der Arten von Clearing- Systemen. Während im Clearing-Prozess die Übermittlung, der Abgleich und in einigen

Abb. In Leseprobe nicht enthalten.

Abbildung 2.3:Arten von Clearingsystemen nach Heldt et al. [43]

Fällen die Bestätigung von Transaktionen vor der Abwicklung und möglicher Aufrech- nung stattﬁndet, wird im Settlement-Prozess die eigentliche Übertragung der Zahlung vorgenommen. Je nach Anwendungsgebiet kann der Clearing- und Settlement-Prozess auch zusammengefasst durchgeführt werden, beispielsweise wenn dieser mit Finanz- markttransaktionen verbunden ist und über automatisierte Clearing-Häuser (ACH) ab- gewickelt wird [24].

2.2.4. Auslandzahlungsverkehr

Deﬁnition & Funktion

Komplementär zum bereits erläuterten Inlandszahlungsverkehr, bei dem Geldeinheiten in der gleichen Währung übertragen werden, existiert der Auslandzahlungsverkehr. Der auch als internationaler Zahlungsverkehr bezeichnete Auslandzahlungsverkehr grenzt sich nach Dr. Jasper durch die Konversion in andere Währungen vom Inlandzahlungs- verkehr ab [52]. Beispielsweise ﬁndet in der Europäischen Union die Abwicklung von Euro-Zahlungen (national und grenzüberschreitend) seit 2014 einheitlich über die Sin- gle Euro Payments Area(SEPA) statt, sodass hier keine Unterscheidung von In- und Auslandszahlungsverkehr vorgenommen wird [52].

Im internationalen Zahlungsverkehr werden zwischen unterschiedlichen Währungs- räumen elektronische Zahlungen meist über ein Netz von Korrespondenzbankbeziehun- gen oder grenzüberschreitend operierende Zahlungssysteme abgewickelt [52]. Essentiell ist der standardisierte Nachrichtenaustausch über Kommunikationsnetzwerke für den internationalen Zahlungsverkehr [59].

⁶Eigene Darstellung

Verbreitung & Beispiel

Das größte, bekannteste und am weitesten verbreitete Netz für den Nachrichtenaus- tausch zwischen teilnehmenden Kreditinstituten ist das SWIFTNet-System. Die 1973 gegründete Society for Worldwide Interbank Financial Telecommunication - Organisa- tion ist eine weltweit tätige Vereinigung, die unter anderem den Nachrichtenverkehr für mehr als 11.000 Banken in über 200 Ländern regelt [83]. Im SWIFT-Sytem wird teil- nehmenden Instituten unter anderem der Business Identiﬁer Code (BIC), auch SWIFT- Code genannt, zugeordnet [59]. SWIFT-Nachrichtenaustausch gilt als weltweiter Indus- triestandard der Kommunikation.

Der oﬃziellen Website nach beschreibt sich die Organisation als Kernelement für das Funktionieren von Zahlungssystemen [85]:

"While SWIFT is neither a payment nor a settlement system, and is therefore not regulated as such by central banks or bank supervisors, it is subject to central bank oversight as a critical service provider.

A large and growing number of systemically important payment systems have become dependent on SWIFT, which has thereby acquired a systemic character."

Nach eigener Deﬁnition ist das SWIFT-Netzwerk somit ein Dienstleister (engl. ser- vice provider), welcher die zahlreichen heutzutage verfügbaren Zahlungsverkehrssysteme weltweit miteinander verbindet. Durch die gewichtige Position im Netz internationale Bezahlssysteme kennzeichnet sich die SWIFT-Organisation zudem auch als systemrele- vant.

Einer Datenerhebung der SWIFT-Organisation aus dem Oktober 2020 ergab, dass im Auslandzahlungsverkehr rund 37,82% aller Transaktionen (nach Volumen) mit dem Euro abgewickelt werden. Darauf folgend ist der US-Dollar mit 37,64%, das britische Pfund mit 6,9% sowie der japanische Yen mit 3,59% [84]. Obwohl der Euro erstmals den US-Dollar im Transaktionsvolumen weltweit überstieg, bleibt der US-Dollar die be- vorzugte Währung für den internationalen Handel. Der US-Dollar dominierte weiterhin die Liste der meist gehandelten Währungspaare im Jahr 2020 und war an allen sieben größten Währungspaarpositionen (engl. forex currency pairs) beteiligt [26]. Zu den be- liebtesten Forex Paaren zählen absteigend Euro zu US-Dollar (EUR/USD), US-Dollar zu Japanischen Yen (USD/JPY), Britisches Pfund zu US-Dollar (GBP/USD), Australi- scher Dollar zu US-Dollar (AUD/USD), US-Dollar zu Kanadischen Dollar (USD/CAD), US-Dollar zu Schweizer Franken (USD/CHF) und Neuseeländische Dollar zu US-Dollar (NZD/USD) [26].

2.2.5. Zahlungsdienstleister

Deﬁnition & Funktion

Allgemein versteht man unter Zahlungsdienstleistern (engl. payment provider) Institute, die befugt sind Zahlungsdienste anzubieten [76]. Hierzu zählen neben gesetzlichen Stel- len wie Bundes- oder Zentralbanken vor allem auch privatwirtschaftliche Kreditinstitute. Unternehmen, die beispielsweise in der Europäischen Wirtschaftsgemeinschaft (EWG) als Zahlungsdienstleister fungieren, erbringen die Zahlungsdienste auf der Grundlage

eines Zahlungsdienstevertrags [76]. Die für Unternehmen genehmigungspﬂichtige Tätig- keit wird je nach ausgeübtem Währungsraum legislativ anders behandelt, in Deutsch-

land fällt sie ausgeübt durch Finanzdienstleistungsinstitute beispielsweise unter das Kreditwesengesetz (KWG) [18, S. 197]. Der Nutzer eines Zahlungsdienstes verwendet das bereitgestellte Zahlungsinstrument des Zahlungsdienstleisters, um Zahlungsaufträge abzuwickeln [61]. Um die Funktion eines Zahlungsdienstleisters zu verdeutlichen, wird nachfolgend der vereinfachte Ablauf des Zahlungsinstruments Kreditkarte illustriert.

Beispiel eines 4-Parteien-Zahlungssystems

Kreditkartenzahlungen sind eine Form der Zahlkarte und grenzen sich beispielsweise im Verhältnis zu Debitkarten in der Liquiditätswirkung, im Einsatzbereich und der Art des Speichermediums ab [62][18, S. 331]. Kredit- und Debitkarten zählen nach Angaben Statistas zu der weltweit ⁷ populärsten Bezahlmethode im Onlinehandel [74, S. 14]. Bei der Bezahlung mit der Kreditkarte, wie beispielsweise einem regulärem Onlinekauf, wird die Zahlung in einem 4-Parteien-Zahlungssystem getätigt.

Die vier involvierten Parteien sind [57]:

1. Der Zahler (Karteninhaber),

2. der Zahlungsempfänger (Händler),

3. der Zahlungsdienstleister des Zahlers (sog. Issuer) und

4. der Zahlungsdienstleister des Zahlungsempfängers (sog. Acquirer ).

In Abbildung 2.4 sind die Abhängigkeiten der einzelnen Akteure im System ersicht- lich. Zu Beginn tätigt ein Karteninhaber einen Kauf bei einem Händler, woraus ein

Abb. In Leseprobe nicht enthalten.

Abbildung 2.4:Illustrativer Ablauf einer Kreditkartenzahlung nach Schindele [70]

⁷Umfasst den asiatisch-paziﬁschen, den amerikanischen, den europäischen und den indischen Wirtschaftsraum

sogenanntes Valutaverhältnis entsteht. Der Karteninhaber und die kartenausgebende Bank (Zahlungsdienstleister des Zahlers) besitzen ein Deckungsverhältnis. Händler und Acquirer (Zahlungsdienstleister des Zahlungsempfänger) besitzen ein Vollzugsverhält- nis. Der Issuer besitzt wie sein Gegenspieler, der Acquirer, ein Clearingverhältnis mit der „fünften“ Partei. Die fünfte Partei, die aber oft nicht hinzugezählt wird, ist der Systembetreiber.

Die größten Systembetreiber für Kartenzahlungen sind VISA und MasterCard. Der Markt für Kreditkartenzahlungen teilt sich in Europa wesentlich in zwei Fraktionen auf, wobei der Anteil von Visa Europe Services Inc. etwa 60% entspricht und MasterCard Inc.die verbleibenden ca. 40% deckt [74, S. 26].

3- Parteien-Zahlungssystem

Analog zum 4-Parteien-System existiert das 3-Parteien-System . Ein Beispiel für ein 3-Parteien-System, also ein System bei dem Zahlungssender und -empfänger das gleiche Zahlungssystem (bzw. Systembetreiber) verwenden, ist beispielsweise das amerikanische Unternehmen PayPal Inc.[56].

2.3. Einschränkungen gegenwärtiger Finanz-/Zahlungsinfrastrukturen

Die bisherigen Ausführungen haben einen groben Überblick über bestehende IT-Systeme und Zahlungsinfrastrukturen in der Finanzwelt gegeben. Im Zuge des Trends zu mehr Digitalisierung in der Finanzbranche sind Neobanken die modernsten Dienstleister für den Endkunden-Zahlungsverkehr. Doch wie bisher angeführt, ist die Tätigkeit einer Neobank auf ein Netzwerk aus weiteren Dienstleistern, angebundenen Systemen und Stakeholder angewiesen. Möchte ein Kunde beispielsweise Gelder von einer Neobank zu einer anderen Neobank transferieren, kommen je nach Zahlungsmittel die Kreditkarten- systeme der Anbieter oder die Clearing-Systeme etablierter Großbanken zum Tragen. In einigen Fällen, wenn es sich um einen grenzüberschreitenden Zahlungsverkehr han- delt, sind zudem internationale Systeme wie das SWIFT-Nachrichtensystem essentiell als auch transnationale Stellen für das Zentralbank-Clearing erforderlich. Die bishe- rigen Erläuterungen in Abschnitt 2.2 zu Clearingsystemen und dem Zahlungsverkehr umfassten lediglich den deutsch/europäischen Raum. Die aufgezeigten Ausführungen können jedoch nur geringfügig den Umfang bestehender Komplexität in internationalen Zahlungsverﬂechtungen erfassen. Die historisch gewachsenen Verﬂechtungen zur Dienst- leistungserbingung von Bezahlfunktionen lassen sich weder quantitativ noch qualitativ auf einer globalen Skala darlegen.

In den nächsten Abschnitten werden fünf wesentliche Einschränkungen bestehender Finanz- und Zahlungsinfrastrukturen genauer beschrieben, welchen während der Lite- raturrecherche besondere Bedeutung zugemessen wurde.

2.3.1. Politisierung & fehlende Neutralität

Allgemein gültige Aussagen lassen sich im Gegensatz zur Gesamtkomplexität des heu- tigen Finanzsystems über die Verwendung der bevorzugten Währungen der Zahlungs- parteien treﬀen, denn statistisch betrachtet dominiert der US-Dollar den Reservestatus für die Abwicklung von Transaktionen [38]. So zeigen die vom Internationalen Wäh- rungsfonds (IWF) erhobenen Daten, dass der US-Dollar mit einem Anteil von etwa 60% ⁸ an den ca. 13 Billionen US-Dollar umfassenden Währungsreserven der Länder die beliebteste Währung für die Abwicklung von Schulden ist [38]. Der Euro fällt mit einem Anteil von ca. 21%, der japanische Yen mit ca. 6%, das britische Pfund mit 5% und der chinesische Renminbi mit ca. 3% ins Gewicht. Eine Visualisierung der Ver- teilung ﬁndet sich in Abbildung 2.5. Andere, kleinere Währungsräume sind auf einer globalen Ebene für den transnationalen Handel de facto von geringer Bedeutung. Diese immense Gewichtung des US-Dollars an den internationalen Transaktionsbeziehungen erklärt auch seine Stellung für die Einﬂussnahme auf die globalen Finanzmärkte. Die vorherrschende Rolle der Vereinigten Staaten eröﬀnet dem Land die Möglichkeit, den Zahlungsverkehr international zu beschränken. So ist nach Einschätzung der Stiftung Foundation for Economic Education die zeitweise SWIFT-Transkationssperre bestimm- ter Länder wie beispielsweise des Irans, Russlands, Nordkoreas oder auch Chinas zu einem wichtigen politischen Machtinstrument verkommen [55]. Die erste Einschränkung bestehender Zahlungssysteme ist folglich die Politisierung und die fehlende Neutralität der Systeme.

⁸Stand: Zweites Quartal 2021

Abb. In Leseprobe nicht enthalten.

Abbildung 2.5:Weltweit allokierte Währungsreserven (Q2 2021) [38]

2.3.2. Kreditbasierte Systemrisiken

Des Weiteren sind Transaktionen in Fiat-Währungen meist schwebend, da der Settle- ment-Prozess nicht sofort ﬁnalisiert wird. Wie im Abschnitt 2.2.2 beschrieben, existieren Clearing-Systeme auf verschiedenen Ebenen. Je nach Anwendungsfall und Transakti- onsvolumen ist die Abrechnung der Salden von einer anderen zeitlichen Komponente geprägt. Wie Rullière et al. [16] in ihrem Forschungspapier nachwiesen, ist der „Domi- noeﬀekt“ durch Kreditrisiken ein immanentes Systemrisiko für die Stabilität von Trans- aktionssystemen. Auch für Händler ist die Akzeptanz elektronischer Zahlungen oft ein ﬁnanzielles Risiko. Gründe sind beispielsweise die Rückbuchungen von Kreditkarten (engl. chargebacks ) oder die Verzögerungen in der Zahlungsabwicklung. Die zweite Ein- schränkung bestehender Zahl-/Finanzsysteme ist folglich die verzögerte Finalität der Transaktionen (Settlement) und Abhängigkeit von Kreditzahlungen.

2.3.3. Finanzielle Inklusion

Ein weiteres Manko existierender Zahlungssysteme ist der Mangel an ﬁnanzieller Inklu- sion. Der Term ﬁnanzielle Exklusion bezieht sich auf den informellen Begriﬀ der sog. unbanked people, also Menschen ohne Zugang zu ﬁnanziellen Dienstleistungen bzw. ohne Zugang zu einem Bankkonto. Der Global Findex Reportder Weltbank listet die Zahl der Menschen, die als unbankedgelten mit 1,7 Milliarden auf ⁹ [82]. Das Fehlen von ﬁnanziellen Dienstleistungen und die Nicht-Teilnahme an Zahlungsinfrastrukturen hat eine derart negative Auswirkung auf die Lebensqualität der unbanked people, dass die Vereinten Nationen sie als wesentlichen Faktor für die Verbesserung der Lebensverhält- nisse ansehen. In sieben von siebzehn geförderten Zielen für die nachhaltige Entwicklung bis zum Jahr 2030 haben die Vereinten Nationen die Inklusion festgeschrieben, wie bei- spielsweise im achten Ziel Decent Work and Economic Growth[65]:

"Strengthen the capacity of domestic ﬁnancial institutions to encourage and expand access to banking, insurance and ﬁnancial services for all."

⁹Letzter Stand der Daten aus dem Jahr 2017

– United Nations Sustainable Developments Goals Nr.8[65]

Aus einer im Februar 2021 veröﬀentlichen Studie der britischen Forschungsplattform Merchant Machineim Global Finance Magazine geht hervor, dass Marokko, Vietnam, Ägypten, die Philippinen und Mexiko die Länder mit der höchsten Quote an Menschen ohne Bankkonto repräsentieren [81]. Die Tabelle 2.2 ¹⁰ stellt die zehn Länder mit den höchsten Quoten dar. Die verwendete Abkürzung Tx steht für Transaktion. Auﬀallend sind die im internationalen Vergleich oft niedrig ausfallende Anzahl von Internetzugän- gen, welche meist eine Voraussetzung für das Banking darstellen. Auf globaler Ebene

Abb. In Leseprobe nicht enthalten.

Tabelle 2.2:Top 10 Länder mit höchster Quote an fehlendem Zugang zu Bankkonten [

führen die Regionen mit dem höchsten Anteil an Entwicklungs- oder Schwellenländern die Liste an: Im Nahen Osten und in Afrika sind 50% der Bevölkerung ﬁnanziell ausge- grenzt, Süd- und Mittelamerika folgen mit 38%, Osteuropa und die ehemaligen Sowjet- republiken mit 3% und der Anteil des asiatisch-paziﬁschen Raums liegt bei 24%.

2.3.4. Unwirtschaftliche Kleinstbetragszahlungen

Ein weiteres Merkmal gängiger Zahlungsinfrastrukturen ist das Fehlen von Kleinstbe- tragzahlungen. Bei sog. Micropaymentshandelt es sich um sehr kleine Transaktionen oder Zahlungen, die in der Regel weniger als eine Währungseinheit oder in einigen Fäl- len sogar nur den Bruchteil eines Hundertstel einer Währungseinheit umfassen [37]. Micropayments werden hauptsächlich online ausgeführt und in der Regel in Kombinati- on mit digitalen Gütern oder Dienstleistungen getätigt. Bekannte Beispiele hierfür sind Käufe in Online-Spielen, Streaming von Medien oder Internet-of-Things-Geräte. Weil Online-Zahlungen die Einbindung von mehreren Intermediären ¹¹ erfordern, sind diese Zahlungen oft mit einer Mindestgebühr seitens des Intermediärs versehen, was es den Händlern erschwert Micropayments gewinnbringend einzusetzen. Bei Internetzahlungen kommen oft noch Wechselkurse oder andere, nicht mit dem Kerngeschäft des Händlers in Verbindung stehende Gebühren hinzu. In der Praxis wird als Lösungsansatz oft ein Batching- bzw. Aggregrationsverfahren ¹² eingesetzt, welches über die Bündelung der

¹⁰Eigene, übersetze und angepasste Darstellung

¹¹z.B. das 3-Parteien-System PayPal oder das 4-Parteien-System VISA

¹²Typisch für beispielsweise In-App-Käufe auf Plattformen wie Google Play Storeoder Apple App Store

Transaktionen über einen längeren Zeitraum die Gebühren minimiert. Nachteilig für den Zahlungsempfänger ist dadurch nicht nur der Zahlungsverzug, sondern auch das Drittparteirisiko des Zahlungsdienstleisters (Schwebendes Kreditrisiko). Anders als die restliche Internetkommunikation, welche eine direkte Datenübertragung zwischen Par- teien ermöglicht, sind aktuelle Zahlungsinfrastrukturen nicht in der Lage Micropayments direkt zwischen zwei Parteien abzuwickeln.

2.3.5. Datenhandel & -missbrauch

Speziell im Bereich von Zahlungsdienstleistern ist der Handel von Nutzerdaten eine weit verbreitete Praktik. Obwohl 3- und 4-Parteien-Zahlungssysteme meist ein auf Transak- tionsgebühren basierendes Geschäftsmodell verwenden, ist für viele Anbieter die Mone- tarisierung von Daten ein weiterer lukrativer Geschäftszweig. So teilt beispielsweise das Unternehmen PayPal, welches mittels Nutzerkonten bankähnliche Dienstleistungen im Zahlungsverkehr anbietet, Transaktionsdaten der Zahlungsparteien mit einem Netz aus mehreren hundert Drittparteien [51]. Zu den Drittparteien, mit welchen unter anderem persönliche und sensible Transaktionsdaten wie beispielsweise der Name, die Adresse, die Telefonnummer, das Geburtsdatum, die verwendete IP-Adresse, die Bankkontoin- formationen oder der Einkauf geteilt werden, zählen¹³:

2.3.5.1. Weitere Zahlungsdienstleister (z.B. Klarna SE, Sofort GmbH)

2.3.5.2. Kreditratingagenturen (z.B. SCHUFA Holding AG)

2.3.5.3. Wirtschaftsprüfungsgesellschaften (z.B. KPMG)

2.3.5.4. Werbeagenturen (z.B. Ipsos GmbH)

2.3.5.5. Vertriebspartner (z.B. CCC GmbH, Facebook Inc.)

2.3.5.6. Anbieter operativer Dienstleistungen (z.B. Zyklop Inkasso Deutschland GmbH, Google Inc.)

2.3.5.7. Andere kommerzielle Partner (z.B. eBay Corporate Services GmbH)

2.3.5.8. Staatlichen Stellen (z.B. European Consumer Centre Network)

Tatsächlich stellt nicht nur die reine Verwendung konventioneller Zahlungsdienstleister wie der beliebte Anbieter PayPal eine Oﬀenlegung persönlicher Daten und somit der Privatsphäre dar.

Der Missbrauch der Daten zur Proﬁlerstellung (engl. sog. ﬁngerprinting) ist in mo- dernen Zahlungssystemen allgegenwärtig. Nicht nur Regierungen, sondern auch Unter- nehmen, Dienstleister und Plattformbetreiber analysieren aktiv das Nutzerverhalten und werten personenbezogene Daten zu wirtschaftlichen Zwecken oder zur Kontrolle aus. Gewöhnliche Nutzer sind gezwungen, nicht nur den Praktiken und Motiven dieser Akteure zu vertrauen, sondern auch ihrer technischen Sicherheit. Im Falle von feh- lenden Sicherheitsvorkehrungen werden die Kosten und Risiken in der Regel von den Nutzern getragen. Dahingehend ist es wenig überraschend, dass im August 2020 ver- öﬀentlichten Cost of a Data Breach Report 2020die Summe der ﬁnanziellen Schäden durch Datenpannen im Finanzsektor auf Platz drei aller Branchen gelistet ist [9, S. 25]. Die durchschnittliche Schadenssumme aufgrund von Datenmissbrauch im Finanzsektor betrug 5,85 Mio US-Dollar.

¹³Die vollständige Liste aller Partner und Zugriﬀsberechtigungen auf Transaktiondaten ﬁndet sich auf der oﬃziellen PayPal-Webseite

2.4. Quintessenz heutiger Strukturen

Das Aufkommen von FinTech und die damit einhergehende Entstehung von Neoban- ken hat die einst starren Strukturen der oligopolistischen Bankenlandschaft großﬂächig verändert. Der versprochene Demokratisierungsanspruch von Finanzdienstleistungen ist durch die FinTech-Branche gemeinhin erfüllt worden. Millionen Kunden in Industrie- staaten greifen täglich auf die praktischen und komfortablen Finanzdienstleistungen zurück, die es beispielsweise ermöglichen Banking über das eigene Smartphone auszu- führen. Die zu Beginn der FinTech-Revolution als Konkurrenz eingeschätzten FinTech- Unternehmen haben sich weitestgehend an die bestehende Bankenlandschaft assimiliert. Die enge Verzahnung ermöglicht es den FinTechs als IT-Dienstleister der Großbanken auf deren Kapital und bestehende rechtssichere Angebote zuzugreifen. Der Trend scheint klar vorgegeben. Die Unternehmensberatung Capgeminischätzt in ihrem veröﬀentlich- ten World Payments Report 2020 , dass im Jahr 2021 über 860 Milliarden bargeldlose Transaktionen abgewickelt werden [30]. Ein Großteil dieser Zahlungen entfällt auf Kre- ditkarten und auf den Zahlungsverkehr spezialisierte FinTech-Anbieter.

Gemein ist allen genannten Strukturen, seien es Neobanken, Zahlungsdienstleister oder Großbanken, dass es sich um sogenanntes CeFihandelt. Der Begriﬀ CeFi steht für Centralized Finance und impliziert bereits die Natur der Systems: Ihren zentra- listischen Kern. Der historisch gewachsene Aufbau beginnt im Wesentlichen mit der untersten Ebene des Finanzsystems: den Zentralbanken und den Währungssystemen. Beide Fundamente des Finanzwesens sind im Grunde hochpolitische Institutionen, die abhängig vom Stimmungsbild der öﬀentlichen Meinung sind, wie Abschnitt 2.3.1 Politisierung und fehlende Neutralität darlegt. Darauf aufbauende Ebenen, wie der vielschichtige Zahlungsverkehr, die angebundenen Clearing- und Settlement-Systeme oder Unternehmen als Zahlungsdienstleister fügen sich in die Reihe regulatorischer Vorgaben ein. Die resultierenden Limitationen bestehender Infrastrukturen umfassen mithin die genannten kreditbasierten Systemrisiken, welche nachweislich zur großen Rezession der späten 2000er Jahre führten.

Neben den größtenteils politischen Limitationen gibt es auch die sozialen Implikationen wie Abschnitt 2.3.3 Finanzielle Inklusion aufzeigt. Die Finanz- und FinTech- Branche operiert hauptsächlich in einem regulatorischen Rahmen, welcher sich in den Industriestaaten beﬁndet. Milliarden von Menschen haben nachweislich noch keinen Zugang zum elektronischen Zahlungsverkehr. Menschen ohne Bankkonto, welche sich überwiegend in Ländern mit weniger stabilen gesellschaftlichen Institutionen beﬁnden, können von den technologisch-ﬁnanziellen Fortschritten nur begrenzt proﬁtieren. Kein Zugang zu Bankkonten aufgrund fehlender Kreditwürdigkeit ist nur ein Beispiel hierfür. Bestehende Zahlungsinfrastrukturen sind darauf ausgelegt, sich nach den Gegebenhei- ten hiesiger Märkte zu richten¹⁴. Infolgedessen sind auch Innovationen im Bereich von Kleinstbetragszahlungen(Abschnitt 2.3.4) in den vergangenen Jahren bisher kaum um- gesetzt worden, da es an gemeinsamen, internationalen und kostengünstigen Standards fehlt.

Ferner gilt der Datenhandel(Abschnitt 2.3.5) als weiteres Manko in bestehenden Zahlungsinfrastrukturen. Nutzern wird die Hoheit über ihre persönlichen Informationen abgesprochen. Der Handel und teilweise Missbrauch mit Nutzerinformationen ist zum

¹⁴Nicht zuletzt auch wegen der Dominanz des US-Dollar als Weltreservewährung

festen Bestandteil der CeFi-Zahlungssysteme verkommen. Insofern ist der Datenhandel als Geschäftsmodell wenig überraschend, da Nutzer elektronischer Zahlungen bisher kei- ne echte Alternative nutzen konnten. Fundamental ist das Ermöglichen dieser Praktik auf das obskure Design des CeFi-Systems zurückzuführen, welches eine Rechenschafts- pﬂicht nur gegenüber autorisierten Beteiligten erlaubt. Zu solchen zählt beispielsweise der Zweig der Wirtschaftsprüfungsgesellschaften.

Konträr zum Status quo hat sich eine technologische Entwicklung angebahnt, dessen volles Potential noch nicht abgeschätzt werden kann. Das sog. Web 3.0und die integrier- te Decentralized Finance (DeFi) -Entwicklung. DeFi gibt dem Nutzer der Technologie seine Autonomie im Digitalen mittels radikal entgegengesetzter Infrastruktur zurück. In Kapitel 3 betrachten wir die Komponenten der Lightning Nodes, ein Teilbereich von DeFi, um ein technisches Verständnis von der Technologie zu bekommen.

Kapitel 3

Lightning Nodes

In diesem Kapitel wird der Aufbau eines Lightning Nodes beschrieben. Dies dient dem grundlegenden Verständnis der technischen Architektur für das Lightning Service Pro- vider Modell. Relevant ist hierfür die Abgrenzung von meist ähnlichen wirkenden Tech- nologien, welche sich auch im Themenfeld der DeFi-Entwicklung beﬁnden. Ein grundle- gendes Verständnis der Lightning-Technologie wird vorausgesetzt. Neben dem Aufbau der allgemeinen Software-Architektur wird auch die Hardware zur Verdeutlichung der Miniaturisierung elektronischer Zahlungssysteme beschrieben. Außerdem werden ver- schiedenen Node-Architekturen vorgestellt, von welchen eine Variante anschließend in Kapitel 4 praktisch implementiert wird.

3.1. Abgrenzung & Analogie

Zur besseren Einordnung von Lightning Nodes und dem Lightning Netzwerk werden diese zunächst von anderen Technologien im dezentralen Finanzwesen abgegrenzt, bevor wir uns dem Vergleich mit klassischen Strukturen widmen.

3.1.1. Einordnung in DeFi-Technologien

Mit der Erﬁndung und Veröﬀentlichung des Bitcoin-Protokolls durch Satoshi Nakamo- to im Jahr 2009 [12] ist die Voraussetzung für eine kambrische Explosion an digitalen Innovationen geschaﬀen worden. Die unter dem Begriﬀ Blockchainﬁrmierenden Techno- logien haben eine Welle an neuen Anwendungsfelder geschaﬀen. Ein besonders spannen- der Anwendungsfall ist das bereits genannte dezentrale Finanzwesen (DeFi). DeFi zielt darauf ab, Finanzdienstleistungen zu revolutionieren, indem es anders als bestehende FinTech-Anbieter auf einer dezentralen Infrastruktur aufbaut [2, S. 1]. Die Innovation von DeFi ist ähnlich wie bei der Blockchain-Technologie:

Reduktion des notwendigen Vertrauens. Das Ablösen zentraler Plattformen/Anbie- ter/Banken zugunsten dezentraler Systeme. Dank DeFi können Einzelpersonen an bei- den Seiten von Finanztransaktionen teilnehmen, d. h. Dienstleistungen in Anspruch nehmen und anbieten [2, S. 2]. Die neue Möglichkeit der ﬁnanziellen Interaktion führt ähnlich wie mit dem Beginn der FinTech-Revolution zu einer weiteren Demokratisie- rung von Finanzinstrumenten. Anders als in der traditionellen Finanzwelt dienen je- doch Kryptowährungen als native Vermögenswerte der dezentralen Infrastruktur. Die bekanntesten unter ihnen sind die beiden Blockchain-Netzwerke Bitcoin und Ethereum.

Amler et. al kategorisieren in ihrem Forschungspapier DeFi-ning DeFi: Challenges & Pathway DeFi-Dienstleistungen in fünf charakteristische Kategorien [2, S. 3]:

• Kreditvergabeplattformen,

• Plattformen zur Verwaltung von Vermögenswerten,

• dezentrale Börsen,

• Derivatdienste,

• und Zahlungsnetzwerke.

Amler et al. merken an, dass die genannten Kategorien nicht absolut sind und lediglich Klassiﬁzierungsrichtlinien darstellen, da sich viele Aspekte von DeFi noch ändern. Au- ßerdem können viele DeFi-Dienste mehr als einer Kategorie zugeordnet werden. Für die vorliegende Arbeit ist jedoch wesentlich der Teilbereich Zahlungsnetzwerke relevant, in welcher das Lightning Netzwerk und die kennzeichnenden Lightning Nodes gehören.

3.1.2. DigitaleBargeldzahlungen

Eines der wichtigsten Merkmale von Bargeld ist die Fähigkeit der beteiligten Parteien Zahlungen in Echtzeit und mit minimaler Beteiligung von Dritten durchzuführen. Die Bargeldinfrastruktur proﬁtiert auch von der sofortigen Abrechnung: Sobald ein Zahler einem Zahlungsempfänger Bargeld ausgehändigt hat, ist die Zahlung abgewickelt. Der Zahler hat keine Möglichkeit, die Zahlung einseitig umzukehren.

Wie wir bereits im vorangestellten Kapitel 2 gesehen haben, beeinträchtigt die Segmentierung unterschiedlicher Zahlungssysteme die Fähigkeit Zahlungen in Echtzeit

durchzuführen. Zahlungen ﬁnden über diverse Netzwerke und unterschiedlichste Zah- lungssysteme statt, die nicht global synchronisiert werden können. Die Abrechnung, der Clearing- und Settlement-Prozess, erfordert eine paarweise Synchronisation zwi- schen den Instituten. Die Abwicklungszeiten für inländische Banküberweisungen und Lastschriften betragen in der Regel einige Stunden bis Tage; die Abwicklungszeiten für internationale Überweisungen dauern oft ein vielfaches dessen. Zahlungsnetze bieten in der Regel kurzfristige Kredite an, um schnellere Abwicklungen zu ermöglichen. Auf- grund dessen ist bei modernen digitalen Zahlungen das Vertrauen in die abzuwickelnde Institution maßgeblich hoch und der Einsatz von Kreditzahlungen wesentlich.

Wie das Lightning Netzwerk eine bargeldähnliche Zahlungsart im Digitalen erreicht, wird durch die kommenden Abschnitte ersichtlich.

3.1.3. Analogie zum traditionellenZahlungsverkehr

In Kapitel 2 wurden im Abschnitt 2.2 die einzelnen Dimensionen des Zahlungsverkehrs aufgezeigt. Die Dimensionen umfassen die Art des verwendeten Zahlungsmediums, die Verwendung von Belegen und die Dringlichkeit und Abwicklung der Zahlung.

Nach dieser Deﬁnition lassen sich einige Parallelen zum Lightning Netzwerk herstel- len. So entspricht die Art des verwendeten Zahlungsmittels auf dem Lightning Netzwerk analog dem baren Zahlungsverkehr. Da es sich aufgrund der Eigenschaften der Kryp- towährung Bitcoin um bargeldähnliches Geld handelt, ist die Kombination der Eigen- schaften von Bargeld und der digitalen Gegebenheit ein Novum im Zahlungsverkehr.

Der Verwendung nach handelt es sich um einen beleglosen, elektronischen Zahlungs- verkehr, weil keine Datensätze erst elektronisch umgewandelt werden müssen, wie dies für beleghafte Zahlungen der Fall ist. Eine Abwicklung der Zahlungen im nicht-digitalen ist ausgeschlossen.

In puncto Dringlichkeit und Abwicklung ähnelt der Zahlungsverkehr auf dem Light- ning Netzwerk dem Massenzahlungsverkehr. Der Unterschied besteht jedoch darin, dass die Finalität der Zahlung einem bargeldähnlichen Vorgang gleicht. Es gibt folglich keine schwebenden Zahlungen mit Kreditabhängigkeit. Hierbei lässt sich der Bezug zu den Clearing- und Settlement-Systemen herstellen.

Lightning Nodes wickeln untereinander den letzten Zustand, beziehungsweise die Guthaben zwischen den etablierten Zahlungskanälen, ab. Dies entspricht analog dem Clearing-Prozess. Werden die Zahlungskanäle zwischen zwei Nodes geschlossen, ﬁndet eine Closing-Transaction auf der Bitcoin-Blockchain statt. Die Blockchain gilt deshalb aus Sicht des Lightning Netzwerks als Settlement-System. Eine Einordnung des Zah- lungsverkehrs auf dem zweischichtigen Kryptotransaktionssystem als auch die charakte- ristischen Unterschiede zum traditionellen Zahlungsverkehr ﬁndet sich in Tabelle 3.1¹.

Abb. In Leseprobe nicht enthalten.

Tabelle3.1:Dimensionen des Zahlungsverkehrs im Bitcoin-System

¹Eigene Einteilung anhand der Kriterien aus Abschnitt

3.2. Node-Architektur & Terminologien

Ein theoretische Vertiefung unterstützt die spätere Interpretation der Konﬁguration ei- nes Lightning Nodes. In den ersten drei Abschnitten wird ein Überblick über die systemi- schen Komponenten gegeben. Anschließend wird die Software-Architektur illustriert und die einzelnen Bestandteile vorgestellt. Darauf folgen die populären Lightning-Software- Implementierungen und die universellen Hardwareanforderungen an den Nodebetrieb.

3.2.1. Struktur desKryptotransaktionssystems

Das Lightning Netzwerk ist ein dem Bitcoin Netzwerk übergeordnetes Netzwerk², wel- ches den Transaktionsdurchsatz des Systems massiv skaliert. Es wird deshalb als Zah- lungsnetzwerk von Bitcoin betrachtet. Wie in Abschnitt 3.1.3 ausgeführt, erlaubt das Zahlungsnetzwerk sofortige und privatsphärewahrende Zahlungen mit geringen Gebüh- ren, indem es Zahlungen oﬀ-chainausführt und die Sicherheit der zugrundeliegenden Blockchain als Settlementschicht nutzt. Die Idee für die Skalierung der Bitcoin Techno- logie wurde von Poon und Dryja im Jahr 2015 konzeptualisiert [14]. Beim Verständnis der Technologie ist es wichtig, die beiden interagierenden Netzwerke zu diﬀerenzieren:

• Das Bitcoin Netzwerk:Ein Bitcoin-Client dient als Basisschicht (engl. base- layer), auf der Lightning arbeitet. Lightning nutzt die zugrundeliegende Block- chain für Transaktionen zum Öﬀnen und Schließen von Zahlungkanälen, Light- ning Nodes überwachen das Bitcoin-Netzwerk auf relevante Ereignisse wie den Zahlungskanalstatus.

• Das Lightning Netzwerk:Die Peer-to-Peer-Netzwerkschicht auf der Block- chain, auf der sich Lightning Nodes miteinander verbinden (engl. second-layer) und Details und Nachrichten über Zahlungskanäle teilen, um Zahlungen durchzu- führen.

Der Base- und der Second-Layer bilden eine konkrete Protokollkombination. Ähnlich wie im Falle der Internetprotokollfamilie handelt es sich um eine hierachische Struk- tur. Nach Mandl werden innerhalb eines Endsystems (hier: Kryptotransaktionssystems) Nachrichten von den höheren zur niedrigeren Schicht übergeben, die mit Steuerungs- informationen angereicht werden [10, S. 5]. Innerhalb des Kryptotransaktionssystems werden im Lightning Netzwerk Steuerungsinformationen über die Zahlungskanäle aus- getauscht, welche auf der darunterliegenden Schicht, der Blockchain, festgeschrieben werden.

3.2.2. Fairness-Protokoll

Die Infrastruktur des Bitcoin-Lightning-Systems wird allgemein als trustless bezeichnet. Die Verwendung des Begriﬀs bedeutet in diesem Kontext, dass das System die Fähigkeit besitzt, ohne das Vertrauen in andere Teilnehmer zu funktionieren. Vorhandenes Ver- trauen für die betrugsfreie Zahlungsabwicklung ist natürlicherweise auch durch externe Faktoren existent, jedoch im Bitcoin-Lightning-System keine vorangestellte Notwendig- keit. Antonopolous et al., Autoren von Mastering the Lightning Network - A Second Layer Blockchain Protocol for Instant Bitcoin Payments , sprechen im Zusammenhang

²Die Lightning Technologie ist auf andere Blockchain-Netzwerke portierbar

auch von einem Fairness-Protokoll[3, S. 22f]. Sie deﬁnieren ³ das Protokoll als „ein Verfahren, das ein System von Anreizen und/oder Negativanreizen verwendet, um faire Ergebnisse für Teilnehmer zu gewährleisten, die sich nicht gegenseitig vertrauen. Die Durchsetzung eines Fairness-Protokolls ist nur notwendig, um sicherzustellen, dass die Teilnehmer den Anreizen oder Negativanreizen nicht entgehen können“ [3, S. 23]. Maß- geblich für die Umsetzung der Regeln des Protokolls ist der Einsatz spieltheoretischer Ansätze und die Anwendung von Kryptographie zur Gewährleistung dieser.

3.2.3. Aufbau eines Lightning Nodes

Generell ist ein Lightning Node eine Softwareanwendung, die mittels des Lightning- Protokolls Zugriﬀ aus das Lightning Netzwerk hat. Ein Lightning Netzwerk Node muss grob betrachtet, folgende drei Eigenschaften erfüllen [3, S. 34f]:

1. Implementiertes Wallet, d.h. ein Node sendet und empfängt Zahlungen sowohl über das Lightning Netzwerk als auch über das reguläre Bitcoin Netzwerk

2. Kommunikation auf Peer-to-Peer-Basis mit anderen Lightning Nodes

3. Zugang zur Bitcoin-Blockchain und Kontrolle über die Mittel

Die Nutzer des Netzwerks haben den höchsten Grad an Sicherheit und Kontrolle, wenn sie ihre Bitcoin und Lightning Nodes eigenständig betreiben. Lightning Nodes kön- nen andernfalls auch einen leichtgewichtigen Bitcoin-Client verwenden, der gemeinhin als vereinfachte Zahlungsveriﬁzierung (engl. Simple Payment Verﬁciation) bezeichnet wird, um mit der Bitcoin-Blockchain zu interagieren. Als Beispiel hierfür dient der in der Programmiersprache Go geschriebene Neutrino-Client, welcher einen Betrieb eines Lightning Nodes ermöglicht, ohne die Bitcoin- und Blockchain-Software selbst auszu- führen und zu speichern [109]. Ein Anwendungsfall für Neutrino-Clients ist der Einsatz in mobilen Geräten, wie beispielsweise Smartphones.

3.2.4. Software-Architektur

Die Software-Architektur eines Lightning Nodes ist stark von der verwendeten Imple- mentierung abhängig⁴, jedoch lässt sie sich auf wenige Kernkomponeten abstrahieren. Die Kernkomponenten, also Teile des Bitcoin-Software-Stacks, setzen sich aus drei wesentlichen Komponenten zusammen: der Bitcoin-Blockchain-Software, der Lightning- Netzwerk-Software und der Anwendungssoftware. Die ersten beiden stellen Protokoll- implementierungen dar, wohingegen die Anwendungssoftware generisch für jede Art von Software steht, mit welcher eine Interaktion über die beiden anderen Typen von Soft- ware erfolgt. Eine Visualisierung des exemplarischen Softwarestacks für einen Lightning Netzwerk Node ﬁndet sich in Abbildung 3.1⁵. Jede Komponente der Architektur setzt auf der darunterliegenden auf und steht in einem Abhängigkeitsverhältnis zu ihr.

³Wörtliche und sinngemäße Übersetzung

⁴Siehe hierzu Abschnitt

⁵Eigene Darstellung

Abb. In Leseprobe nicht enthalten.

Abbildung 3.1:Abstrakte Darstellung eines LN-Node Softwarestacks

Bitcoin-Software

Die am weitesten verbreitete Referenzimplementierung für die Bitcoin-Blockchain-Soft- ware ist Bitcoin Core(als Prozess: bitcoind) und liegt aktuell in der Version 22.0 publik auf GitHub vor [86]. Alternativ ist btcdeine in der Programmiersprache Go geschriebe- ne, langjährige in der Praxis verwendete Implementierung [105]. Die aktuelle Version ist btcd v0.22.0-beta. Gemein ist beiden Versionen, dass sie die Kernlogik wie die Konsen- susregeln abbilden, um eine gemeinsame Interoperabilität und die Funktionsweise der Blockchain zu gewährleisten. Sie werden weiterhin im Open-Source-Ansatz weiterentwickelt.

Lightning-Software

Damit auch die Lightning-Netzwerk-Software unabhängig der verwendeten Program- miersprache zur Implementierung ein gemeinsames Fundament aufweist, werden in den Basis of Lightning Technology(BOLT) die Grundpfeiler für die Speziﬁkation des Pro- tokolls festgelegt. Die Standards werden auf GitHub in dem Repository lightning/boltsgepﬂegt [33]. Sie beﬁnden sich in der konstanten Weiterentwicklung und sind nicht ﬁnalisiert. Die Protokollspeziﬁkation wird zunehmend zu einem allgemeingültigen Re- ferenzmodell, ähnlich wie dies beispielsweise bei der Datenkommunikation über das OSI-Modell der Fall ist [10, S. 2].

Laut akuteller Fassung werden in insgesamt 11 BOLT Speziﬁkationen die Mecha- niken des Protokolldesigns der Lightning-Technologie dargelegt. BOLT Nr. 6 wurde oﬃziell entfernt, sodass es im Grunde genommen lediglich zehn verschiedene Speziﬁ- kationen sind. Die Protokollsuite umfasst insgesamt fünf verschiedene Schichten [3, S. 208ﬀ]:

• Eine Netzwerkverbindungsschicht,

• eine Nachrichtenübermittlungsschicht,

• eine Peer-to-Peer-Schicht,

• eine Routing-Schicht und

• eine Zahlungsschicht.

Die Tabelle 3.2 ⁶ behandelt die Funktion jeder einzelnen Schicht sowie die verwendete Speziﬁkationsnummer [3, S. 208ﬀ]

Abb. In Leseprobe nicht enthalten.

Tabelle 3.2:Funktionen der einzelnen Lightning-Protokollschichten und zugehörige BOLT-Speziﬁkationsnummer nach Antonopolous et al. [3, S. 209]

Anwendungssoftware am Beispiel von Lightning Wallets

Nach Antonopolous et al. ist ein wesentliches Merkmal zur Unterscheidung von Ligh- ting Wallets die Art der Verwahrung der Gelder und der Grad der Abhängigkeit von Drittparteien [3, S. 36f]. Wird die Verwahrung der Gelder von einem Dienstleister an- geboten, wie später in Kapitel 5 betrachtet, spricht man von custodialWallets. Der Gegensatz dazu sind die selbstverwahrten, non-custodial/self-custody Wallets. Unab- hängig der Verwahrung können einzelne Softwarekomponenten eines Lightning Nodes wie beispielsweise die Blockchainanbindung an einen Dritten ausgelagert werden. Je nach technischer Aﬃnität des Nutzers wird mehr Kontrolle über das Lightning Wal- let und/oder den Lightning Node selbstständig ausgeübt. Die Art des Lighting Wallets wird deshalb vom Anwendungsfall abhängig gemacht, je nachdem welche Komponenten des Softwaresystems benötigt werden. Tabelle 3.3 ⁷ unterscheidet zwischen vollwertigen Lightning Nodes und solchen, die eine externe Abhängigkeit aufweisen, sog. Drittanbie- ter Lightning Nodes.

⁶Wörtliche und sinngemäße Übersetzung

⁷Sinngemäße Übersetzung

Abb. In Leseprobe nicht enthalten.

Tabelle 3.3:Verhältnis von Lightning Wallets zu Lightning Nodes nach Antonopoulus et al. [3, S. 40]

Der dritte Quadrant Custodial/Vollwertiger Lightning Nodeist eine Spezialform. Es wird ein vollständiger Lightning Node verwendet, die Mittel werden aber von einem Verwahrer gehalten. Antonopolous et. al gehen davon aus, dass künftige Wallets aus diesem Quadranten es dem Nutzer überlassen, sich um die operativen Aspekte seines Nodes zu kümmern, den Zugriﬀ auf die Schlüssel aber an eine dritte Partei delegieren, die in erster Linie cold storage, also eine besonders sichere Verwahrmethode, nutzt.

Lightning-Wallets können auf einer Vielzahl von internetfähigen Geräten installiert werden. Hierzu zählen Standard-Computer, Server und Smartphones. Um einen voll- ständigen Lightning Node zu betreiben, muss in der Regel ein dedizierter Server oder ein Desktop-Computer verwenden werden, um die nötige Leistungsfähigkeit hinsichtlich Kapazität, Verarbeitung, Laufzeit und Konnektivität zu gewährleisten ⁸.

3.2.5. Populäre Software-Implementierungen

Die am häuﬁgsten verwendeten Implementierungen sind die Softwareprogramme c- lightning, LND, eclairund rust-lightning. Die jeweiligen Implementierungen unterschei- den sich durch ihren Funktionsumfang, ihre Leistungsfähigkeit, die Programmiersprache (C, Go, Scala und Rust) und für die Implementierung entstandene individuelle Softwa- reprodukte. Weiterhin gibt es Lightning-Implementierungen in anderen Sprachen, z. B. Node-Lightning in Node.js[113], welche jedoch nicht voll kompatibel zu allen BOLT sind und in der Praxis keine Relevanz aufweisen.

C-lightning

C-lightning ist eine Lightning Netzwerk-Implementierung, die vom Unternehmen Block-stream Inc.in C++ geschrieben wurde und unter der BSD-MIT-Lizenz verfügbar ist [104]. C-lightning ist seit Anfang 2018 im Bitcoin-Mainnet ⁹ im produktiven Einsatz. In seiner Software-Architektur folgt C-lightning einem modularen und erweiterbaren Ansatz mit starker Rückwärtskompatibilität. Die Implementierung bietet einen Low- Level-Zugriﬀ für individuelle Anpassungen und eine ﬂexible Nutzung der Lightning- Daemons.

LND

Der Lightning Network Daemon(LND) ist eine Lightning Netzwerk Implementierung, die von Lightning Labs in Go entwickelt wurde und unter der MIT-Lizenz verfügbar ist [108]. LND ist als besonders benutzerfreundliches Programm konzipiert, wodurch die Entwicklung von Applikationen erleichtert wird. Es ist ein eigenständiger Daemon mit umfangreichen Funktionen, der seit dem ersten Quartal 2018 für das Mainnet zur Verfügung steht.

Eclair

Eclair ist eine vom Unternehmen ACINQentwickelte Scala-Implementierung des Light- ning Netzwerks, die unter der Apache Lizenz 2.0 verfügbar ist [116]. Seit dem Mainnet- Release Anfang 2018 bietet Eclair nach eigenen Angaben eine Implementierungsbiblio- thek für robuste, sichere und skalierbare Nodes, die hohe Transaktionsvolumina bewäl- tigen können und eine native mobile Implementierung des Lightning Netzwerks bieten.

Rust-Lightning & LDK

Rust-Lightning (RL) ist eine generische Bitcoin-Lightning-Bibliothek, die von der Rust- Bitcoin-Community in Zusammenarbeit mit dem Unternehmen Square Crypto Inc.in Rust entwickelt wurde und unter Apache 2.0- oder MIT-Lizenzen verfügbar ist [91]. RL wurde im Dezember 2019 veröﬀentlicht und zielt darauf ab, eine ﬂexible Implementie- rung mit vollem Funktionsumfang für Lightning mit minimalen Systemabhängigkeiten bereitzustellen. Alle Funktionen sind über einfache, kombinierbare APIs zugänglich. Die

⁹Das in Produktion beﬁndliche Netzwerk wird mainnetgenannt. Für die Entwicklung werden sog.

testnetsverwendet.

Entwickler des Projektes haben sich mit Square Crypto, dem Initiator des Lightning De- velopmentKits(LDK), zusammengeschlossen. Basierend auf Rust-Lightning enthält das LDK eine API und andere Funktionalitäten sowie eine zugehörige Dokumentation, um Lightning-Integrationen für Entwickler anwendungsfreundlich zu gewährleisten [90].

3.2.6. Hardware

Zunächst werden die Anforderungen an Hardware Nodes detailliert beschrieben, bevor die verschiedenen Arten von Hardware Nodes aufgezeigt werden.

Anforderungen

Für eine Partizipation am Kryptotransaktionssystem ist keine spezialisierte Hardware erforderlich. Lediglich im Mining-Betrieb werden sog. Application Speciﬁc Integrated Circuits(ASICs) eingesetzt, welche eine enorme Rechenleistung zum Erstellen neuer Blöcke für die Blockchain bereitstellen. Die Mining-Geräte werden von Unternehmen im industriellen Maßstab produziert und sind für die Thematik der Lightning Nodes nicht relevant. Für alle anderen Operationen im Netzwerk unabhängig des Mining-Prozesses wird Hardware benötigt, welche in gewöhnlichen Endverbraucher-Rechnern zu ﬁnden ist. Ein seit Beginn an gewählter Entwicklungsansatz des Bitcoin-Lightning-Systems ist die Berücksichtigung der marginalen Kosten zum Betrieb eines Nodes. Es handelt sich um einen Softwarestack, welcher sowohl einen gemäßigten technischen als auch ökonomischen Ressourcenaufwand aufweist, sodass Nutzer mit für Verbraucher üblichen Elektronikpreisen einen Node betreiben können.

Je nach Implementierung werden die Hardware Voraussetzungen mit leichten Un- terschieden aufgeführt, wir richten uns jedoch nach dem verallgemeinerten Ansatz von Antonopolous et al. [3, S. 159 ﬀ.]¹⁰. Ein generalisierter Ansatz für den Betrieb eines eigenen Lightning Node Rechners erfordert:

3.2.6.1. Genügend Prozessorleistung (CPU): Eine ausreichende Rechenleistung ist er- forderlich, um einen Bitcoin Node im Bitcoin-Netzwerk zu betreiben. Der Bitcoin- Node lädt kontinuierlich neue Blöcke und validiert alle Blöcke einschließlich Signa- turen. Bei der Einrichtung eines Bitcoin Nodes muss der Nutzer auch den anfäng- lichen Download von Blöcken (engl. initial block download, IBD ) einkalkulieren, der zwischen mehreren Stunden und Tagen dauern kann. Es wird mindestens ein 2-Kern- oder 4-Kern-Prozessor empfohlen.

3.2.6.2. Ausreichend Arbeitsspeicher (RAM): Für den reibungslosen Betrieb wird ein Rechner mit mindestens 4GB Arbeitsspeicher empfohlen, um sowohl Bitcoin als auch Lightning Nodes zu betreiben. Auch der IBD stellt mit weniger als 4GB RAM eine Herausforderung dar. Mehr als 8 GB RAM sind nicht notwendig, da der Prozessor aufgrund von kryptograﬁschen Operationen wie der Signaturvalidierung der größere Engpass ist.

3.2.6.3. Passendes Speichermedium: Die Festplatte kann als Hard Disk Drive(HDD) oder als Solid State Drive(SSD) eingesetzt werden. Eine SSD ist für den Be- trieb eines Nodes deutlich schneller und deshalb von Vorteil. Der größte Teil des Speicherbedarfs wird für die Bitcoin-Blockchain verwendet, die mehrere hundert

¹⁰Sinngemäße und ergänzte Übersetzung

Gigabyte groß ist. Ein angemessener Kompromiss ist nach Antonopolous et al. [3,

S. 159] die Anschaﬀung einer kompakten SSD zum Booten des Betriebssystems und einer größeren HDD zum Speichern größerer Datenobjekte, welche hauptsäch- lich Datenbanken umfasst.

3.2.6.4. Permanente Internetverbindung: Eine verlässliche Internetverbindung ist so- wohl für den Download neuer Bitcoin-Blöcke als auch für die Kommunikation mit anderen Lightning Nodes erforderlich. Der Datendurchsatz variiert je nach Ein- satz und Konﬁguration. Zu Beginn lädt ein vollwertiger Bitcoin-Node die gesamte Historie der Blockchain herunter, welche aktuell ¹¹ rund 426 GB umfasst.

3.2.6.5. Unterbrechungsfreie Stromversorgung: Da Lightning Nodes permanent onli- ne sein müssen, ist eine zuverlässige Stromversorgung unbedingt erforderlich. Ein Ausfall der Stromversorgung führt zum Verlust laufender Zahlungen. Bei stark beanspruchten Nodes ist ein Backup oder eine unterbrechungsfreie Stromversor- gung (USV) für den Fall eines Stromausfalls sinnvoll. Im Idealfall wird auch der Internet-Router an diese USV angeschlossen.

3.2.6.6. Automatische Datensicherung: Die Datensicherung ist von zentraler Bedeu- tung, da ein Ausfall zu Datenverlusten und somit zu ﬁnanziellen Verlusten führt. Es empﬁehlt sich daher, eine Backup-Lösung in Betracht zu ziehen. Eine solche Lösung kann eine automatische Cloud-basierte Sicherung auf einem selbst kontrol- lierten Server oder Webdienst sein. Alternativ kann es sich auch um eine automa- tisierte lokale Hardwaresicherung handeln, beispielsweise auf einer zusätzlichen Festplatte. Optimale Ergebnisse erzielt man mit einer Kombination aus lokaler und Remote-Datensicherung.

Arten von Hardware Nodes

Die genannten Hardware Voraussetzungen können je nach Einsatzgebiet und -zweck auf einer Vielzahl von unterschiedlichen Komponenten laufen. Antonopolous et al. diﬀeren- zieren wesentlich, ob der eigene physische Zugriﬀ auf das Gerät möglich ist. Wenn es sich beispielsweise um eine Lightning Node Instanz auf einem Virtual Private Server(VPS) in einem Rechenzentrum handelt, widerspricht dies dem Dezentralisierungsprin- zip des Kryptotransaktionssystems und der Privatsphäreaspekt wird nicht gewahrt [3,

S. 157]. In einem Szenario, bei welchem das komplette Rechenzentrum vom Netz geht, würde dies zudem zu einem weitreichenden Ausfall des Lightning Netzwerks führen, wenn besonders viele Nodes in Rechenzentren angesiedelt sind.

Eine bessere Umsetzung ist das Betreiben von physisch zugänglichen Lightning No- des, die wiederum in drei Subkategorien aufgegliedert werden können [3, S. 156 f.]:

3.2.6.7. Standard-Computer: Ein Node kann auf einem Heimcomputer oder Laptop mit einem der Betriebssysteme Windows, macOS oder Linux betrieben werden. Im Normalfall erfolgt der Betrieb gemeinsam mit einem Bitcoin-Node.

3.2.6.8. Dedizierte Hardware: Ein Lightning-Node lässt sich auch auf dedizierter Hard- ware wie einem Raspberry Pi, Rock64oder Mini-PCbetreiben. In diesem Fall läuft in der Regel ein Software-Stack, der einen Bitcoin-Node und weitere Anwen-

¹¹Stand: Dezember 2021

dungen enthält¹². Diese Variante ist besonders verbreitet, da die Hardware nur für den Betrieb und die Wartung des Nodes bestimmt ist und in der Regel mit einer Installationshilfe eingerichtet wird. Eine konkrete Umsetzung auf dedizierter Hardware ﬁndet sich in Kapitel 4 Implementierung.

3.2.6.9. Vorgefertigte Hardware: Ein Node kann ebenfalls auf speziell für ihn gewählter und konﬁgurierter Hardware betrieben werden. Dazu gehören „Out-of-the-Box“- Lightning-Node-Lösungen, die als Bausatz oder fertiges System erworben werden.

3.2.7. Vorteile durch Miniaturisierung

Die minimalen Anforderungen an die Hardware der Lightning Nodes verdeutlicht zum einen die extrem anpassungsfähige Natur des Zahlungs- und Transaktionsnetzwerks. Zum anderen zeigt es einen Trend auf, der zu Beginn von Kapitel 2 Stand gegenwärtiger Zahlungsinfrastrukturen bereits ersichtlich wurde: Die Internet- und Kommunikations- technologie dominiert einem immer größeren werdenden Teil einst rein institutionell zugänglicher Aufgaben. Durch die beschriebene Miniaturisierung des Bezahlvorgangs ermöglicht das Lightning Netzwerk einen weiteren Meilenstein in der Demokratisierung von Finanzdienstleistungen. Nicht zuletzt wird dies eine kontinuierliche Verbesserung von Software und Hardware in allen Ebenen der IKT ermöglicht.

3.3. Populäre Node-Architekturen

In diesem Abschnitt werden drei populäre Full-Node-Software-Stacks vorgestellt und ihre Unterschiede aufgezeigt. Bei den drei Software-Architekturen handelt es sich um Node-Software, welche für dedizierte Hardware Nodes optimiert ist. Sie bilden somit nicht das volle Spektrum aller verfügbaren Bitcoin Lightning Nodes ab, stellen aber eine typische Auswahl an Node-Architekturen dar, mit welcher ein neuer Betreiber von Lightning Nodes üblicherweise konfrontiert ist. Dedizierte Hardware Nodes sind für den durchschnittlichen Nutzer angepasst und weisen keine Besonderheiten an Kapitalauf- wänden für Nodebetreiber auf, da sie mit handelsüblicher Elektronik betrieben werden. Alle vorgestellten Full Node Architekturen werden für gewöhnlich auf einem Einplati- nencomputer wie dem Raspberry Pi betrieben.

Der Begriﬀ Full Node beschreibt die Zusammensetzung aus den Kernkomponenten und erspart Nutzern die manuelle Komposition einzelner Softwarekomponenten. Ein vollwertiger Bitcoin-Software-Stack dient insbesondere einem erleichterten Einstieg in das Bitcoin- und Lightning-Ökosystem. Gleichzeitig ermöglicht die eigenständige Inbe- triebnahme eines vollwertigen Nodes die vollkommene Kontrolle über die verwalteten Gelder sowohl auf der Blockchain als auch im Lightning Netzwerk. Alle drei nachfolgend

gelisteten Softwaresysteme werden nach Open-Source-Prinzipien entwickelt.

3.3.1. MyNode

MyNodeist ein im Jahr 2019 entstandenes Projekt und wird nach der Creative Com- mons BY-NC-ND 4.0 Lizenz publik auf GitHub entwickelt [93]. Nach eigenen Angaben zielt das Projekt darauf ab, durch eine eigenes entwickelte Benutzeroberﬂäche die In- tegration von Anwendungssoftware von Drittanbietern für Bitcoin und Lightning auf einfache Art und Weise bereitzustellen [64]. MyNode bietet hierfür eine Management- und Monitoringsoftware für den Bitcoin Lightning Node als Community-Edition an. Unterstützt werden neben dem Raspberry Pi 4 auch der RockPro64, Rock64 oder vir- tuelle Maschinen für einen Einsatz abseits dedizierter Hardware. Neben der kostenfreien Version existiert mit myNode Premiumeine eigener Support für die Software sowie mit einem myNode 1wird Gerät ein vorgefertigtes Hardwaregerät angeboten.

3.3.2. Raspiblitz

Raspiblitzist im Jahr 2018 von der Fulmo GmbH mit Sitz in Berlin ins Leben gerufen worden und wird seitdem aktiv gepﬂegt und weiterentwickelt [40]. Das Projekt steht un- ter der MIT-Lizenz [103]. Die Fulmo GmbH ist sowohl der Anbieter als auch Entwickler des Softwarestacks und auf die Beratung im Bitcoin-Umfeld spezialisiert. Ähnlich wie myNode bietet Raspiblitz einen vollwertigen Bitcoin Lightning Node an, welcher wahl- weise mit C-lightning oder mit der LND-Lightning-Implementierung betrieben wird. Im Gegensatz zu myNode ist die Administration eines Raspiblitz Nodes nur über die Kom- mandozeile via SSH und nicht über eine lokale Weboberﬂäche möglich. Zusätzlich zur kostenfreien Open-Source-Full-Node-Architektur existiert die Option, einen dedizierten Bitcoin Lightning Node über die Fulmo GmbH zu erwerben.

3.3.3. Umbrel

Das Umbrel-Projekt wurde Anfang 2020 gestartet und bildet wie die beiden zuvor ge- nannten Systeme einen vollwertigen Bitcoin und Lightning Node ab [31]. Von den Ent- wicklern wird UmbrelOS weiterführend als Personal Server OSbezeichnet, also ein Node-Betriebssystem, welches neben den Bitcoin-Lightning-Funktionalitäten noch wei- tere Applikationen unterstützt, die meist auf Peer-to-Peer-Basis funktionieren. Umbre- lOS ist unter der PolyForm Noncommercial License 1.0.0verfügbar [95]. Weiterhin werden über die oﬃzielle Webseite des Projektes auch vorgefertigte Nodes in Koopera- tion mit Hardwareherstellern angeboten [31]. Nach Angaben der Entwickler sind bereits mehr als 13.000 UmbrelOS-Serversysteme im Lightning Netzwerk aktiv, was das Projekt zum populärsten Full Node Software Stack bzw. Lightning Node Betriebssystem macht [32].

3.4. Verbreitung verschiedener Nodearten

Aufgrund der dezentralen, systemimmanenten Eigenschaften des Lightning Netzwerks ist eine genauere Beziﬀerung der verschiedenen Nodetypen ¹⁴ schwierig zu erfassen. Ein besserer Ansatz ist es, hauptsächlich die verwendete Softwareimplementierungen als Un- terscheidungsgröße heranzuziehen, um die Popularität der verschiedenen Implementie- rungen zu messen. Eine im Januar 2021 veröﬀentliche empirische Untersuchung mit dem Titel Node Classiﬁcation and Geographical Analysis of the Lightning Networkhat das Bitcoin-Bezahlnetzwerk über einen Zeitraum von ca. zwei Jahren überwacht [21]. Die Daten wurden anschließend systematisch ausgewertet, um anhand von Standardeinstel- lungen der Nodeimplementierungen einen Rückschluss auf die Aufteilung des Netzwerks zu ermöglichen. Für die Auswertung wurden die am weitest verbreiteten und bereits in Abschnitt 3.2.5 vorgestellten Implementierungen C-lightning, LND und Eclair anhand ihrer Standardprotokollkonﬁguration analysiert. Die Implementierung Rust-Lightning taucht aufgrund ihrer geringen Verbreitung und ihrer Neuheit nicht in den Daten auf. Die Ergebnisse der empirischen Datenauswertung von Zabka et al. ﬁnden sich im Ori- ginal in Abbildung 3.2.

¹⁴bspw. den Hardwaretyp

Abb. In Leseprobe nicht enthalten.

Abbildung 3.2:Verteilung nach Lightning Node Implementierung [21, S. 131]

Überraschend an der Auswertung der Forscher ist die Tatsache, dass das Lightning- Netzwerk bisher wesentlich durch die LND-Implementierung dominiert wird. So hat die Methodik von Zabka et al. zur Klassiﬁzierung der Nodes ergeben, dass rund 87% aller verwendeten erfassten Nodes diese Software verwendeten. Weitere ca. 11% der Nodes verwenden C-lightning, während Eclair auf einen Anteil von nur etwa 2% kommt. Das restliche 0,1% betriﬀt nicht bestimmbare, andere Implementierungen. Zabka et al. sehen die ungleiche Distribution als Folge einer besseren Benutzeradressierung durch den LND- Client [21, S. 131]. Die LND-Software bot trotz späterer Veröﬀentlichung als Eclair und C-lightning bereits vorkompilierte Versionen des Clients für die verschiedenen CPU- Architekturen und Betriebssysteme, einschließlich Windows, an.

Kapitel 4

Node Implementierung

In diesem Kapitel wird die praxisnahe Implementierung eines Lightning Nodes umge- setzt. Ausgehend von der gewählten Software-Architektur und der erforderlichen Hard- ware werden die verschiedenen operativen Modi eines Nodes aufgezeigt. Im Zuge der Inbetriebnahme des Nodes werden optimalen Konﬁgurationen, bewährte Verfahren und Betriebsanweisungen erläutert. Hierbei kommt sowohl die Software zur Verwaltung des Nodes, als auch Shellskripte für die Konﬁguration zum Tragen. Zur Gewährleistung eines langfristigen, reibungslosen Node-Betriebs werden weiterhin bekannte ökonomische und technische Risiken betrachtet und Sicherheitseinstellungen zur Prävention dieser Risi- ken vorgenommen. Abschließend folgt der Syllabus bisheriger Konﬁgurationen, welcher als Orientierungshilfe für zukünftige Nodebetreiber dient und die Forschungsunterfrage zum reibungslosen Betrieb eines Nodes subsumiert.

1. Node Implementierung 39

4.1. Zahlungskanäle

Für die weiterführenden Abschnitte ist ein konzeptionelles Verständnis des Lightning Netzwerks erneut essentiell. Um einen besseren Leseﬂuss zu ermöglichen, werden die Grundlagen und Konzepte der Zahlungskanäle grob aufgezählt.

Die Kernfunktion von Bitcoin’s Layer-2-Protokoll ist die Abwicklung von schnellen und günstigen Zahlungen. Gewährleistet wird dies durch ein Netzwerk bestehend aus Zahlungskanälen. Jeder dieser Zahlungskanäle entsteht zwischen zwei Lightning-Nodes¹. Eröﬀnet wird ein Zahlungskanal durch eine Opening-Transactionauf der Bitcoin Block- chain, analog wird der Zahlungskanal durch eine Closing-Transaction geschlossen. In der Zwischenzeit ﬁnden die Transaktionen lediglich o ﬀ-chainstatt, sodass die Nodes die Guthaben in den Zahlungskanälen stets aktualisieren. Dieser Prozess erfolgt sofort und erspart beiden Parteien das Warten auf Blockbestätigungen für die Finalisierung der Zahlung. Auch wenn zwei Lightning Nodes keinen direkten Zahlungskanal zuein- ander etabliert haben, sind sie in der Lage sich gegenseitig über einen oder mehrere intermediäre Lightning-Nodes zu bezahlen, welche die Zahlung vom Zahler an den Zah- lungsempfänger weiterleiten. Für die Weiterleitungen der Zahlungen wird eine speziel- le Variante von konditionalen Bitcoin-Transaktionen, sog. Hash-Time-Lock-Contracts ² (HTLCs), eingesetzt. Die HTLCs sind Bestandteil eines Fairness-Protokolls, wie in Ab- schnitt 3.2.2 beschrieben. Eine wesentliche Herausforderung im Lightning Netzwerk be- steht darin, dass ein Zahlungsweg gefunden werden muss, der die Gelder vom Zahler zum Zahlungsempfänger sendet. Man spricht auch vom Routingbzw. Pathﬁnding ³ der Zahlung⁴. Idealerweise ist die gewählte Route des Zahlungsweg die günstigste, schnellste und die zuverlässigste Route.

Weiterführende Literatur und eine detaillierte Beschreibung der Funktionsweise ﬁn- det sich in der vom Autor verfassten Bachelorarbeit mit dem Titel Das Lightning Netz- werk als Grundlage für die Kryptoökonomie [5].

¹Auf Protokollebene werden in zukünftigen Implementierungen auch Kanäle aus mehr als zwei Par- teien möglich sein, sog. Channel Factories [4, S. 6]

²Diese Art von Transaktion ﬁndet oﬀ-chainstatt und kann unter bestimmten Umständen jederzeit

on-chaineingelöst werden.

³Darunter versteht man die konkrete Berechnung der Route

⁴Siehe hierzu Abschnitt unter Routing-Schicht

4.2. Ausgewählte Software-Architektur

Eine Beschreibung des gewählten Betriebssystems sowie das Zusammenspiel der ein- zelnen Softwarekomponenten und -dienste werden in diesem Abschnitt erläutert. Des Weiteren wird über die Installationsvoraussetzungen für Hard- und Software informiert, um eine Reproduzierbarkeit der Implementierung zu gewährleisten.

4.2.1. Betriebssystem

Aufgrund seiner Popularität und seinem repräsentativen Einsatz ⁵ in tausenden Light- ning Nodes wird zur praxisnahen Veranschaulichung das vorgestellte Full-Node-Be- triebssystem UmbrelOS eingesetzt. Die verwendete PolyForm Noncommercial 1.0.0Li- zenz erlaubt zudem eine Modiﬁzierung der Software, sofern diese nicht zu kommerziellen Zwecken weiter veräußert wird. Dadurch eignet sich das Umbrel-Projekt besonders für den Einsatz von Nodes im Umfeld von Lightning Service Providern. Nach Angaben der Entwickler wird das Umbrel-Projekt noch unter einer Beta-Version geführt [95]. Das frei verfügbare OS-Image , welches unter anderem ein vollwertiges Linux-Betriebssystem umfasst, kann aus dem oﬃziellen GitHub Repository heruntergeladen werden [117 ]. Es handelt sich um ein modiﬁziertes RaspbianLinux Betriebssystem, welches für den Ein- satz auf dem Einplatinencomputer Raspberry Pi, einer ARMv8 Architektur, optimiert ist. Neben dem UmbrelOS kann das Framework von Umbrel auch als direkte Instanz,

z. B. im Cloud-Umfeld⁶, verwendet werden, da es plattform- und architekturunabhän- gig ist und alle orchestrierten Dienste Multi-Architektur-Docker-Images verwenden [95]. Von den Entwicklern wird bisher nur der Einsatz auf einem Raspberry Pi empfohlen [95].

Die Logik zur Orchestrierung des Systems besteht wesentlich aus Shellskripten, die von der initialen Installation des Betriebssystems bis zur Verwaltung von Applikationen die Einrichtung weitestgehend automatisieren.

4.2.2. Orchestrierung der Dienste

Die Architektur der verwendeten Dienste umfasst bei Installation alle nötigen Software- bausteine, welche für den Betrieb eines vollwertigen Bitcoin Lightning Nodes notwendig sind.

Zu diesen Diensten zählen das Umbrel Dashboard, der interne Umbrel Manager, die Kommunikationsmiddleware Umbrel Middleware , die Bitcoin Core Software und der zugehörige Indexierungsdienst Electrs , die Lightning Netzwerk Software LND und der zugehörige Neutrino Switcher , die Tor-Software und die populäre Webserver Software Nginx. Sowohl die Bitcoin als auch Lightning Netzwerk Software läuft in einem Daemon- prozess. Eine abstrakte Darstellung der gegenseitigen Abhängigkeit bestehender Dienste ist in Abbildung 4.1 ⁷ skizziert. Alle Dienste laufen orchestriert innerhalb eines Docker Containers und bieten somit die Vorteile der Isolation einzelner Komponenten.

Das Umbrel Dashboard baut auf dem Nginx Webserver auf und dient als webbasierte

⁵Siehe Abschnitt

⁶Beispielsweise unter Ubuntu Linux oder Debian

⁷Eigene Darstellung nach Entwicklerskizze [95]

Oberﬂäche zur komfortablen Interaktion des Nutzers mit dem Node [97]. Weiterhin kommuniziert es mit dem Umbrel Manager und der Umbrel Middleware.

Der Umbrel Manager bietet eine Low-Level-System-API, die die Benutzerauthenti- ﬁzierung⁸, die Ver- und Entschlüsselung von sensiblen Informationen und die Lebens- zyklusVerwaltung aller anderen containerisierten Dienste übernimmt. Über die Umge- bungsvariablen des Umbrel Managers werden unter anderem die Zugriﬀe auf die Bitcoin Remote Procedure Calls (RPC) als auch der Port zur Kommunikation mit der Umbrel Middleware deﬁniert [99].

Die Umbrel Middleware wird von der Weboberﬂäche verwendet, um sowohl mit der Bitcoin Core Software als auch mit der LND-Software zu interagieren. Zusätzlich wird die Schnittstelle beider Applikationen von einer RPC bzw. gRPC auf eine RESTful- API gemapped und zur Verfügung gestellt. Ebenso wie im Umbrel Manager werden in der Middleware weitere Umgebungsvariablen für die involvierten Programme zur gegenseitigen Kommunikation deﬁniert [100].

Abb. In Leseprobe nicht enthalten.

Abbildung 4.1:Abstrakte Darstellung eines Umbrel-Systems [95]

Die Hauptkomponenten eines Lightning Nodes werden durch die LND-Implemen- tierung des Lightning Netzwerks und der Bitcoin Core P2P-Software ausgeführt. Beim erstmaligen Start des Nodes, wenn die IBD-Synchronisierung noch nicht abgeschlossen ist, wird die Neutrino Switcher Software eingesetzt [89]. Der Zweck dieses Containers ist es, zwischen Neutrino und bitcoind ⁹ zu wechseln. Dadurch ist sichergestellt, dass ein Lightning Node auch dann betrieben werden kann, wenn die komplette Bitcoin- Blockchain noch nicht heruntergeladen und veriﬁziert wurde. Über das Umbrel-System hinweg läuft standardmäßig jeglicher ausgehender Datenverkehr durchgängig über das Tor-Netzwerk.

⁸über JSON-Web-Token (JWT)

⁹Bitcoin Core DaemonProzess

4.2.3. Installationsvoraussetzungen

Das UmbrelOS reiht sich in die gängigen Vorgaben zum Betrieb von Nodes ein. Die Vor- gaben umfassen typischerweise jene Voraussetzungen, die in Abschnitt 3.2.6 beschrieben wurden. Auf der Softwareseite werden nach Entwicklerangaben jeweils

4.2.3.1. mehr als 600GB freier Festplattenspeicher,

4.2.3.2. eine Docker und Docker-Compose Installation,

4.2.3.3. sowie Python 3.0 oder höher

4.2.3.4.als auch kommandozeilenbasierte Programme wie curl

vorausgesetzt [95]. Hardwareseitig ist eine Limitierung auf mindestens einen Raspberry Pi 4 zu empfehlen. Für diese Arbeit wird im konkreten Anwendungsfall ein Raspberry Pi 4 Model Bmit 4 GB Arbeitsspeicher eingesetzt. Als Festplatte kommt eine SanDisk Extreme Portable SSD mit 1TB Speicher zum Einsatz. Das Betriebssystem ist auf einer handelsüblichen microSD-Karte mit 32GB Speicher eingerichtet. Neben einem 5V USB- C-Stromanschluss ist der Node dauerhaft über einen LAN-Anschluss mit dem Internet

verbunden. Ein Raspberry Pi 4 ist in Abbildung mit seinen Hardwareschnittstellen exemplarisch dargestellt.

Abb. In Leseprobe nicht enthalten.

Abbildung 4.2:Ein Raspberry Pi 4 und seine Anschlussmöglichkeiten [102]

4.3. Konﬁguration

Die Konﬁguration des Nodes entscheidet über dessen operativen Modi. Nachfolgend wird sowohl die Standardkonﬁguration eines Umbrel Nodes beschrieben als auch eine Refe- renzierung zu möglichen weiteren Anpassungen genannt. Zur Node-Konﬁguration zählen auch die einzigartigen Node-Informationen, welche gleichzeitig für den Verbindungsauf- bau benötigt werden. Weiterhin werden die Konﬁgurationsszenarien beschrieben und ein Szenario gewählt, auf welches anschließend der Kriterienkatalog angewandt wird.

4.3.1. Konﬁgurationsdatei

Das Betriebssystem UmbrelOS ist auf Docker-Container-Images abgestimmt. Für jeden Container liegen eigene Konﬁgurationsdateien vor, welche wahlweise für den Betrieb und die Kommunikation über die Schnittstellen angepasst werden können [96]. Der Fokus für diese Arbeit liegt auf der Anpassung der Konﬁgurationsdatei für den Lightning Network Daemon. Die vollständige Konﬁgurationsdatei für LND, lnd.conf, und alle anpassbaren Parameter ﬁnden sich in Anhang A LND-Konﬁgurationsdatei.

Standardmäßig verfügt UmbrelOS über eine adaptierte LND-Konﬁgurationsdatei für die eigene Architektur [98]. Nachfolgend wird der Aufbau beschrieben. In den re- ferenzierten Seitenverweisen ﬁnden sich ausführliche Informationen zu den einzelnen Parametrisierungsoptionen.

In den Application Options werden die applikationsspeziﬁschen Einstellungen festge- legt [S. 82]. Vor und während dem Verbindungsaufbau werden die Informationen ausge- tauscht, um Aufschluss über das Peeringzu geben. Das umfasst nicht nur die Einstellung der Sockets und Ports (listen, rpclisten, restlisten), sondern auch Informationen über das Etablieren von Zahlungskanälen. Hierzu zählt beispielsweise die maximale An- zahl gleichzeitig öﬀnender Zahlungskanäle (maxpendingchannels), die Mindestgröße ei- nes Zahlungskanals in Satoshis (minchansize) als auch die Unterstützung für die direkte Kommunikation zwischen Nodes über das KeySend-Protokoll (accept-keysend) [48]. In den mit tls-beginnenden Feldern wird obendrein die Generation von TLS-Zertiﬁkaten näher bestimmt.

Unter Bitcoind werden die Konnektivitätseinstellungen für die RPC-Aufrufe festgelegt [S. 92]. Über die ZeroMQ (bitcoind.zmq*) Verbindungsoptionen ﬁndet der asynchrone Nachrichtenaustausch statt.

In den Bitcoin-Kriterien wird die aktive Verbindung auf das mainnet festgelegt [S. 90]. Umbrel verwendet standardmäßig den Neutrino-Client, bis die IBD abgeschlossen ist. Ergänzend wird deﬁniert, wie viele Blockbestätigungen abgewartet werden, bis ein Zahlungskanal als eröﬀnet gilt. Standardmäßig sind zwei Bestätigungen festgeschrieben.

Zusätzlich sind die Parameter des Neutrino-Clients festgelegt [S. 92]. Der Client kommt in Umbrel werkseitig nur im testnet zum Einsatz.

Alle ein- und ausgehenden Verbindungen des Umbrel-Systems laufen von Grund auf über das Tor-Netzwerk. Im Abschnitt tor der LND-Konﬁgurationsdatei werden neben Einstellungen zum Proxy-Server auch die Version und das Verbindungspasswort gesetzt

4.3.2. Node-Informationen

Nach der erfolgreichen Installation des UmbrelOS erhält der Node eine einzigartige Identität im Netzwerk. Von besonderer Bedeutung ist der öﬀentliche Schlüssel (engl. Node Public Key). Diese einzigartige Kennung wird in Kombination mit dem Netzwerk- Socket für den Verbindungsaufbau über Tor mit anderen Lightning Nodes und somit für die Etablierung von Zahlungskanälen in Anspruch genommen.

In Tabelle sind die Konnektivitätsinformationen ¹⁰ des betriebenen Nodes do-

kumentiert. Für einen Verbindungsaufbau wird das Muster öffentlicherSchlüssel- @torAdresse:port verwendet.

¹⁰Aus Formatierungsgründen verkürzt. Vollständiger öﬀentlicher Schlüssel ist 03ed6942f3a32b143b34- 79b85ed64453c9b7fbd2057ea15094c0486a39df8b1691 und die Tor Adresse c5foqy74ztjle6odbpoyakayrtxd5v- u73bz5zx6njlubimm3zdqhc2ad.onion

Abb. In Leseprobe nicht enthalten.

Tabelle 4.1:Konnektivitätsinformationen des Lightning Nodes

Die schnelle Abfrage des aktuellen Nodestatus lässt sich mithilfe des Kommandozeilen- programms lncli wie folgt ermitteln:

docker exec lnd lncli getinfo

Programm 4.1:Ausgabe des aktuellen Nodestatus unter LND

1 {

2 "version": "0.14.1-beta commit=v0.14.1-beta",

3 "commit_hash": "6042004edaaa5b3cad0a0808ff23dba4716f7178",

4 "identity_pubkey": "03 ed6942f3a32b143b3479b85ed64453c9b7fbd2057ea15094c0486a39df8b1691",

5 "alias": "simplecrypto.app-learning.com",

6 "color": "#ffc107",

7 "num_pending_channels": 0,

8 "num_active_channels": 17,

9 "num_inactive_channels": 1,

10 "num_peers": 20,

11 "block_height": 719136,

12 "block_hash": "00000000000000000ac86f252157986b6962628227eed2553fb68bb478c545",

13 "best_header_timestamp": "1642425250",

14 "synced_to_chain": true,

15 "synced_to_graph": true,

16 "testnet": false,

17 "chains": [

18 {

19 "chain": "bitcoin",

20 "network": "mainnet"

21 }

22 ],

23 "uris": [

24 "03ed6942f3a32b143b3479b85ed64453c9b7fbd2057ea15094c0486a39df8b1691

25 @c5foqy74ztjle6odbpoyakayrtxd5vu73bz5zx6njlubimm3zdqhc2ad.onion:9735"

26 ],

27 "features": {

28 "0": {

29 "name": "data-loss-protect",

30 "is_required": true,

31 "is_known": true

32 },

33 }

34 }

Die Ausgabe erzeugt eine JSON-Darstellung zum aktuellen Status des Nodes. Hier ﬁn- den sich die bereits erläuterten Konnektivitätsinformationen als auch Statusinformatio- nen über die Zahlungskanäle und die Bitcoin-Blockchain. Des weiteren lässt sich durch

die Ausgabe des Kommandos ein Überblick über angepasste und aktivierte Funktionen ¹¹ herstellen. Die Ausgabe ﬁndet sich in Programm 4.1.

4.3.3. Konﬁgurationsszenarien

Für den Einsatz eines Lightning Nodes gibt es drei wesentliche Betriebsmodi, auf welche die Konﬁguration und der spätere Betrieb eines Nodes ausgerichtet wird. Je nach An- wendungsszenario, wird der Node als Inbound Node, als Outbound Node oder als Routing Nodeklassiﬁziert. Die für diese Arbeit konstruierte Klassiﬁzierung ist jedoch dynamisch zu verstehen, da die Grenzen von einem Betriebsmodus zum anderen ﬂie- ßend sind. Die Ursache für die Unterscheidung ist, dass Zahlungskanäle unidirektional eröﬀnet werden¹². Somit liegt ein Teil der Bitcoin bzw. Gelder im Zahlungskanal vor der ersten Lightning-Transaktion stets auf der eröﬀnenden Seite des Kanals. Des Weite- ren entscheidet der konkrete Anwendungsfall des Nodebetreibers, welcher Betriebsmodi angestrebt werden soll.

Inbound Node

Wenn zu einem Lightning Node wesentlich mehr einkommende Zahlungskanäle als aus- gehende Zahlungskanäle bestehen, dann besitzt dieser Node mehr eingehende (engl. Inbound Capacity) als ausgehende (engl. Outbound Capacity ) Zahlungskanalkapazität. Beispiel:Ein typisches Szenario, bei welchem ein Node weitaus mehr Gelder emp- fangen als senden muss, ist der Einsatz im gewerblichen Bereich als Händler. Die Grund- annahme, dass Kunden viele einzelne Zahlungen an den Händler senden, führt dazu, dass dieser eine weitaus höhere eingehende Zahlungskanalkapazität benötigt. Diese ein- gehende Zahlungskanalkapazität kann beispielsweise durch den Einkauf von Liquidität

auf Seiten des Händlers sichergestellt werden.

Outbound Node

Im Falle, dass der Node hauptsächlich zur Bezahlung im Lightning Netzwerk verwen- det wird und keine einkommenden Gelder empfangen muss, spricht man von einem Outbound Node. Der Node verfügt somit über wesentlich mehr ausgehende Zahlungs- kanalkapazität, also Guthaben, welche nur das Senden und keinen Empfang von Geldern ermöglichen.

Routing Node

Die gängigste und gleichzeitig proﬁtablste Form eines Betriebsszenarios für einen Light- ning Node ist das Szenario eines Routing Nodes. Dieses Konﬁgurationsszenario strebt an, jeden Zahlungskanal in einem ausbalancierten Verhältnis zu halten. Dadurch wird die namensgebende Zahlungsweiterleitung, das Routing, realisiert. Die Aufgabe eines Routing Nodes ist es folglich, als Intermediär Zahlungen von einem Kanal mit einer Partei in einen Kanal mit einer anderen Partei zu leiten. Weil das Weiterleiten von

¹¹Ab Zeile 27 aus Gründen der Lesbarkeit eine verkürzte Darstellung

¹²Zukünftige Implementierungen des Lightning-Protokolls sehen eine bidirektionale Zahlungskanal- öﬀnung vor [4]

Zahlungen einen Aufwand in Form von Kapitalkosten für einen Nodebetreiber erzeugt, wird für jede Zahlungsweiterleitung eine Transaktionsgebühr erhoben. Während der Weiterleitung des HTLC, der Zahlung, ist es nur dem Zahler möglich die komplette Route einzusehen. Die Intermediäre der Zahlung erhalten jeweils nur die Information von welchem Zahlungskanal sie die Zahlung erhalten haben und an welchen Zahlungs- kanal sie die Zahlung weiterleiten. Der empfangende, ﬁnale Lightning Node sieht selbst nur den letzten auf der Route beﬁndlichen Node. Möglich macht die Verschleierung der Zahlungswege das Onion-Routing ¹³ .

4.4. Inbetriebnahme

Aufgrund der Tatsache, dass Routing Nodes wesentlich zur Infrastruktur im Lightning Netzwerk beitragen, wird für das weitere Vorgehen der Betrieb auf dieses Szenario op- timiert.

4.4.1. Deﬁnition optimaler Kriterien

UmbrelOS verwendet die LND-Software zur Interaktion mit dem Netzwerk. Lightning Labs, das Entwicklerstudio hinter LND, veröﬀentlichte mehrere Orientierung- und Kon- ﬁgurationsmuster für den erfolgreichen Betrieb eines Routing Nodes. Für diese Arbeit wird Bezug auf den oﬃziellen Builder’s Guidevon Lightning Labs genommen [50]. Lightning Labs listet fünf wesentliche Kriterien für einen vorteilhaften Betrieb auf¹⁴:

1. Erreichbarkeit: Ein Routing-Node muss jederzeit erreichbar sein. Der Node sollte in Betrieb sein und über aktive Zahlungskanäle mit dem Netzwerk verfügen. Falls man andere Nodes zum Öﬀnen von Kanälen berechtigt, müssen auch eingehende Verbindungen zugelassen werden.

2. Stabilität: Um die Zuverlässigkeit des Routings zu garantieren, benötigt der No- de eine genügende Anzahl an Kanälen zu anderen guten Routing-Nodes im Netz- werk¹⁵.

3. Aktivität: Im Idealfall sind alle Kanäle verfügbar und nicht deaktiviert. Es soll- te ein öﬀentliches Netzwerk-Peering mit nicht routingfähigen Nodes vermieden werden.

4. Kapitalisierung: Um Zahlungen eﬃzient weiterzuleiten, benötigen die Zahlungs- kanäle eine ausreichende Kapazität. Daher ist eine ausreichende Größe des Zah- lungskanals mit genügend ein- und ausgehender Liquidität erforderlich.

5. Rücklagen: Ein jeder Zahlungskanal muss ein Mindestkapital vorhalten, was ein Mindestmaß an ausgehender und eingehender Kapazität bedeutet. Auf diese Wei- se wird gewährleistet, dass der Zahlungskanal jederzeit in der Lage ist, ein Rou- ting durchzuführen. Ist dies nicht der Fall, werden andere Lightning Nodes den Zahlungskanal möglicherweise nicht mehr als Verbindungspunkt wählen, wenn sie aufgrund eines geringen Kapitalpuﬀers Routing-Fehler feststellen.

4.4.2. Praxisnahe Umsetzung der Kriterien

Zur Erfüllung der oben genannten Kriterien wird in den folgenden Abschnitten ein praxisnaher Auszug zur Konﬁguration des Routing Nodes aufgezeigt. Zur Umsetzung der Kriterien werden vielseitige Open-Source-Softwareprogramme zur Node- und Zahl- ungskanalverwaltung verwendet. Die von Lightning Labs entwickelten Kriterien spielen auch in der öﬀentlichen Wahrnehmung einer bedeutende Rolle. Die Webseite Lightning Terminalbietet eine weltweite Rangliste aller Lightning Nodes [46]. Neben Rang und

¹⁴Sinngemäße und ergänzte Übersetzung

¹⁵Ein Sonderfall spielen die privaten Zahlungskanäle, welche nicht für das öﬀentliche Routing verwen- det werden können. Lediglich als Gateway-Node eröﬀnen private Kanäle zusätzliche Möglichkeiten für das Routing.

Namen des Nodes wird die Anzahl der „guten“ Zahlungskanalpartnernodes, ihr Zentra- litätsfaktor im Netzwerk, die gesamte Nodekapazität sowie das Alter ¹⁶ gelistet.

Erreichbarkeit

Anders als für den Betrieb der Bitcoin-Blockchain müssen Lightning Nodes dauerhaft online und erreichbar sein. Die dauerhafte Erreichbarkeit stellt sicher, dass Zahlungen empfangen werden, Kanäle geöﬀnet und kooperativ geschlossen und zudem Protokoll- verletzungen überwacht werden können. Kürzere Ausfallzeiten werden toleriert, ein län- gerer Ausfall kann jedoch zum Verlust der Gelder in den Zahlungskanälen führen. Fallen die Zahlungskanalpartner aus, ist zudem kein Routing mehr möglich und das Kapital im Zahlungskanal gesperrt. Es sollten nur Nodes als Routing-Partner gewählt werden, die auch eine dauerhafte Verfügbarkeit aufweisen. Vorteilhafte Routing-Partner müssen eine Verfügbarkeit von mehr als 99% der Zeit aufweisen. Der Status und die Verfüg- barkeit der Zahlungskanalpartnernodes lässt sich mit dem Kommandozeilenprogramm lncli von LND abfragen.

Weitere Techniken zur Vermeidung von Ausfällen werden von Antonopolous et al. im Abschnitt Lightning Node Uptime and Availabilityin Mastering the Lightning Networkausführlich beschrieben [3, S. 191]. Zu den empfohlenen Handlungsanweisungen zählen unter anderem das Automatisieren des Neustarts und das Monitoring der Logeinträge.

Stabilität

Eine ausreichend große Anzahl an Kanälen verhindert die Abhängigkeit von anderen Zahlungskanalpartnernodes. Dadurch wird gleichzeitig die Ausfallwahrscheinlichkeit der eigenen Liquidität minimiert. Bisherige Richtwerte zur einer passenden Anzahl an Zah- lungskanälen gibt es in bestehender Literatur noch keine, allerdings empfehlen Antono- polous et al. im Abschnitt Channel Managementin Mastering the Lightning Network eine Heuristik zum Umgang mit Kanälen [3, S. 195]. Ihrer Erfahrung nach muss immer mehr als ein Zahlungskanal eröﬀnet werden und es müssen zudem Verbindungen zu ei- nigen wenigen gut vernetzten Nodes hergestellt werden. Zu beachten ist auch, dass die Zahlungskanäle eine angemessene Größe haben, da sie sonst nicht für das Routing von anderen Nodes in Betracht gezogen werden (s. Kapitalisierung, Rücklagen ).

Aktivität

Für einen optimalen Betrieb muss der Lightning Node und alle bestehenden Zahlungs- kanäle dauerhaft aktiv sein. Auf technischer Ebene versteht man darunter, dass keine Kanäle protokollseitig als deaktiviert gelten. Aus wirtschaftlicher Sicht sollte das im Zahlungskanal beﬁndliche Kapital Transaktionsgebühren durch das Weiterleiten von Zahlungen erwirtschaften. Hierfür eignet sich eine dynamische Anpassung der Gebüh- ren. Mit dem Kommandozeilenprogramm Charge-LNDwerden die Gebühren auf die aktuelle Nachfrage im Kanal angepasst. Strategien zur Umsetzung der dynamischen Gebührenstruktur werden über eine individuelle Konﬁgurationsdatei deﬁniert. Die in

Verwendung beﬁndliche Konﬁgurationsdatei ist in Programm gelistet.

¹⁶Hierbei handelt es sich um eine Information darüber, wann der Node das erste Mal im Netzwerk gelistet wurde

Programm 4.2:Personalisierte, beispielhafte Konﬁgurationsdatei zur dynamischen Ge- bührenstruktur unter Charge-LND

Beispielsweise kann hier eine proportionale Strategie zur Preisﬁndung der Liquidität im Zahlungskanal, wie ab Zeile 18 proportional festgeschrieben, eingestellt werden. Fer- ner können pauschal separate Gebührenstrukturen für private Zahlungskanäle festgelegt werden (ab Z. 12 leafnode). Ergänzend gibt es eine Konﬁguration für Standardstrate- gien (ab Z. 1 default) und solche, die nicht in die Bearbeitung des Tools eingebunden werden (ab Z. 7 ignored channels).

Charge-LND wird im Open-Source-Ansatz entwickelt und ist auf der Entwickler- plattform GitHub zur frei Nutzung verfügbar [88]. Für eine reibungslose Integration in das bestehende System kann Charge-LND optional als Docker-Image installiert werden.

Kapitalisierung

Unter der Kapitalisierung der Zahlungskanals versteht man die entsprechende „Größe“ des Zahlungskanals. Abhängig vom Anwendungsfall und der Gegenpartei des Node- betreibers sollte der Kanal ausreichend groß gewählt werden. Als Orientierung sollte stets eine langfristige Zahlungskanalöﬀnung in Betracht gezogen werden, da mit jeder erneuten Etablierung des Zahlungskanals wieder Transaktionsgebühren auf der Bitcoin- Blockchain entrichtet werden müssen. Im Lightning-Protokoll gibt es keine Vorgaben über die minimale Größe des Zahlungskanals, sie darf jedoch nicht die minimale Grö- ße einer On-Chain-Bitcoin-Transaktion unterschreiten. Standardmäßig verwendet der Lightning Network Daemon eine Minimalgröße von 20.000 Satoshis (0,0002 Bitcoin) [s. S. 87]. Die Maximalgröße eines Zahlungskanals beträgt 16.777.215 Satoshi (0,167 Bitcoin) [s. S. 87]. Ergänzend gibt es für besonders große Zahlungskanäle die Option der Wumbo-Channels, welche extra aktiviert werden muss [s. S. 102]. Das maximale Limit für diese Art von Zahlungskanal beträgt 1.000.000.000 Satoshi (10 Bitcoin) [s. S. 87].

Für diese Arbeit wurden insgesamt 17 Zahlungskanäle mit einer Größe von 1.000.000 Satoshi bis zur maximalen Standardgröße von 16.777.215 Satoshi eröﬀnet. Eine Auf- listung der etablierten Zahlungskanäle (ID), den Partnernodes (Alias Name) und die speziﬁsche Kanalkapitalisierung ﬁndet sich in Tabelle 4.2¹⁷.

Abb. In Leseprobe nicht enthalten.

Tabelle 4.2:Etablierte Zahlungskanäle mit ID, Alias und Kapitalisierung

Details zu den Zahlungskanälen können anhand der ID beispielsweise über Lightning Explorer wie Ambossabgerufen werden [77]. Die Kapitalisierung des Nodes beläuft sich als Summe aller etablierten Kanäle somit auf 57.066.061 Satoshi (0,57 Bitcoin).

Rücklagen

Öﬀentliche Zahlungskanäle müssen jederzeit in der Lage sein Zahlungen weiterzuleiten. Bei der Abwicklung und Weiterleitung von Zahlungen gerät das Verhältnis von einge- hender und ausgehender Zahlungskanalkapazität leicht aus dem Gleichgewicht. Je nach Kapitalisierung des Zahlungskanals ist bereits nach wenigen Zahlungen die Liquidität des Zahlungskanals vollständig auf der einen Seite der Transaktionsparteien. Um dem zu entgegen, ist ein aktives Rebalancing , also das Wiederherstellen des Gleichgewichts im Zahlungskanal, erforderlich. Antonopolous et al. schildern in der Sektion Channel Management im Abschnitt Rebalancing Channelsdas grundlegende Prozedere dieses

¹⁷Zeitpunkt: 07. März 2022

Verfahrens [3, S. 201f]. Laut ihrem Forschungsstand sind derzeit drei gängige Methoden für das Rebalancing gebräuchlich:

1. Der Einsatz von spezialisierten Dienstleistern für das Rebalancing

2. Das Rebalancing durch den Transaktionspartner durch Zahlungen

3. Das Senden einer zirkulären Zahlung

Im letzten Fall wird aktiv ein anderer Zahlungskanal des Nodes verwendet, um den Zahlungskanal mit geringer Liquidität erneut zu füllen. Eine Illustration dieses Verfah- rens ﬁndet sich in Abbildung 4.3. Hier balanciert Alice ihren Zahlungskanal erneut mit Bob und Chan, sodass nach der zirkulären Zahlung wieder ausreichend Liquidität auf jeweils allen Seiten der Zahlungskanäle vorhanden ist. Eine Automatisierung dieses Pro-

Abb. In Leseprobe nicht enthalten.

Abbildung 4.3:Illustration des zirkulären Rebalancings von Antonopolous et al. [3, S. 202]

zesses lässt sich mit dem quell-oﬀenen Skript ¹⁸ rebalance-lnd vom Lightning-Entwickler Carsten Otto umsetzen [115]. Zahlungskanäle, die häuﬁger für das Routing verwendet werden und hohe Erträge erwirtschaften, sollten permanent ein Mindestmaß an Rück- lagen aufweisen. Das Skript rebalance-lndweist zwei wesentliche Merkmale auf, welche den Nodebetrieb optimieren: Erstens ignoriert das Skript für zirkuläre Zahlungen di- rekt Zahlungswege, die eine höhere Gebühr haben als die Gebühr, die man selbst für das Ausbalancieren gewählt hat. Zweitens ist ein sog. econ-fee-Faktor implementiert. Mit einem Econ-Fee-Faktor ist es möglich, nur ausbalancierende Zahlungen durchzu- führen, welche unter den Gebühren für die eigene Liquidität liegen. Angegeben wird der Faktor mit einer Variablen die größer als Null und kleiner als Eins ist. Dadurch ist die Wirtschaftlichkeit des Rebalancing für den Nodebetreiber garantiert und kann auf Netzwerkebene zu einer besser verteilten Liquidität führen.

¹⁸Veröﬀentlicht unter MIT-Lizenz

4.5. Operative Risiken

In den nächsten Abschnitten wird auf einige technische Risiken eingegangen, aus wel- chen ökonomische Risiken erwachsen. Die Aufzählung bestimmter Risiken kann unter keinen Umständen als vollständig angesehen werden, da unter anderem die Entwicklung des Lightning Protokolls in vieler Hinsicht sich noch im Beta-Stadium beﬁndet und kritische Sicherheitslücken auf allen Ebenen des Systems nicht ausgeschlossen werden können. Ebenso beﬁndet sich das verwendete UmbrelOS Betriebssystem nach Angaben der Entwickler im Betastadium und gilt nicht als sicher [101].

4.5.1. Hot Wallet Risiko

Ein Lightning Node ist nach Antonopolous et al. deﬁnitionsgemäß eine sog. Hot Wallet[3, S. 181]. Das bedeutet, dass die von einem Lightning Node kontrollierten Gelder direkt auf dem Gerät verwaltet werden und permanent mit dem Internet verbunden sind. Der Zugang zu den Geldern ist entweder direkt in den Arbeitsspeicher des Nodes geladen oder auf der Festplatte des Nodes gespeichert. Wenn ein Lightning Node kompromittiert wird, dann ist es für einen Angreifer trivial, Lightning- und Blockchain-Transaktionen auszuführen, die die Gelder abschöpfen. Aus diesem Grund ist es von enormer Relevanz, dass der Node vor unbefugtem Zugriﬀ geschützt wird.

4.5.2. Hardwarerisiko

Eine Beschädigung der Hardware führt zu schwerwiegenden Folgen für den Nodebe- trieb. Aufgrund der Tatsache, dass sich ein Lightning Node stets online beﬁnden muss, führen Ausfälle zu einer Kaskade an Problemen. Es wird nicht nur der Rang des Nodes in der globalen Rangliste stark abgewertet, sondern besteht auch die Möglichkeit des ﬁnanziellen Schadens. Sind zum Zeitpunkt des Ausfalls beispielsweise Zahlungen wei- tergeleitet worden, hängen diese teilweise bis auf unbestimmte Zeit fest ¹⁹. Ist der Node eine längere Zeit oﬄine, dann besitzen Partnernodes die Möglichkeit zu betrügen, in- dem sie falsche Guthabenstände der Zahlungskanäle auf der Blockchain veröﬀentlichen. Durch beispielsweise einen Stromausfall führt das Risiko des Hardwareausfalls zu einem folgenreichen Schaden für den Nodebetrieb.

4.5.3. Betriebssystem: Umbrel-speziﬁsche Risiken

Die Entwickler des Umbrel-Projekts haben in oﬃziellen Repository einige Sicherheits- risiken zusammengefasst, welche für Nutzer und Nodebetreiber des Systems relevant sind. Hier zu zählen ein Fehler der Signaturveriﬁkation bei Over-The-Air-Updates. Im konkreten Fall würde eine existente Hintertüre durch GitHub oder DockerHub nicht erkannt werden. Ferner sind Schwachstellen in eingebundenen Bibliotheken (z.B. No- de.js) möglich. Kommunikation im lokalen Netzwerk wird unter der Prämisse, dass die Verbindung sicher ist, unverschlüsselt abgewickelt. Berechtigungen von Nutzern werden meist als root-Nutzer ausgeführt, obwohl weitreichende Berechtigungen nicht zwingend erforderlich sind. Auf Netzwerkebene wird kein Sandboxing verwendet, sodass ohne das

¹⁹sog. stuck HTLC, ausführlich beschrieben in Onion Routing in Mastering the Lightning Network[3, S. 362]

Einholen der Genehmigung des Nodebetreibers die Kommunikation von Umbrel-Apps zu anderen Netzwerkdiensten möglich ist. Details zu allen genannten Sicherheitsrisiken können über das oﬃzielle Repository abgerufen werden [101].

4.5.4. Verlustrisiko des SCB

Die Lightning Software LND legt bei jeder Zahlungskanalöﬀnung und -schließung eine neue statische Sicherungskopie der aktuellen Zahlungskanäle an [47]. Dieses sog. StaticChannel Backup(SCB) speichert explizit nicht die letzten Guthabenstände, sondern nur Informationen über die etablierten Zahlungskanäle. Die SCB-Datei wird standardmä- ßig mit dem privaten Schlüssel ²⁰ des Nodes verschlüsselt und auf dem Gerät abgelegt. Die Umbrel-Entwickler implementierten eine anwenderfreundliche Lösung, die das au- tomatisierte Hochladen des letzten Stands der SCB-Datei auf die Server der Entwickler gewährleistet [36]. In diesem Fall ist auch nach einem Totalausfall des Lightning Nodes die Wiederherstellung der Zahlungskanäle nach Anfrage an die Entwickler realisierbar. Jedoch ist wie bereits erwähnt nicht der letzte Stand der Guthaben gespeichert, sodass ein Betrug des Partnernodes nicht ausgeschlossen werden kann. Der einzige Lösungsan- satz ist das Verwenden von sog. Watchtowern²¹.

4.5.5. Risiken durch DoS-Angriﬀe

Einen negativen Einﬂuss auf den Betrieb eines Lightning Nodes haben sog. Denial-of- Service-Angriﬀe (DoS) [3, S. 486f]. Insbesondere, wenn wie im vorliegenden Fall die bereitgestellten Hardwareressourcen im Verhältnis zu üblichen dedizierten Servern ge- ringfügig ausfallen, können DoS-Angriﬀe schnell zur Lahmlegung des Systems führen. Das Umbrel-Betriebssystem akzeptiert deswegen auf der Blockchainebene in Bitcoin Core keine eingehenden Verbindungen. Innerhalb des Lightning Protokolls existieren DoS-Angriﬀsvektoren, welche sich häuﬁg in Debatten unter Entwicklern wiederﬁnden. Antonopolous et al. gehen von zwei bekannten DoS-Szenarien aus [3, S. 487]:

4.5.5.1. Commitment Jamming: Lightning Nodes aktualisieren ihren gemeinsamen Sta- tus durch asymmetrische Commitment-Transaktionen, bei denen HTLCs hinzu- gefügt und entfernt werden, um Zahlungen zu ermöglichen. Mit einem Channel- Jamming-Angriﬀ kann ein Angreifer einen Zahlungskanal unbrauchbar machen, indem er das maximale HTLC-Limit an Zahlungen ²² durch den Zielkanal leitet und bis zum Ablauf der Zeit festsetzt. Das Opfer muss anschließend alle Zahlun- gen auf der Blockchain veröﬀentlichen, was zu extrem hohen Gebühren führt und somit einen ﬁnanziellen Schaden hinterlässt.

4.5.5.2. Channel Liquidity Lockup: Ein Angriﬀ auf die Zahlungskanalliquidität ist ver- gleichbar mit einem Channel-Jamming-Angriﬀ, bei dem Zahlungen durch einen Zahlungskanal geleitet und dort festgehalten werden, so dass der Zahlungskanal unbrauchbar wird. Bei einem Channel-Liquidity-Lockup-Angriﬀ werden stattdes- sen große HTLCs durch einen Zielkanal geleitet, wodurch die gesamte verfügbare

²⁰Gegenspieler zum öﬀentlichen Schlüssel und einzig gültiger Eigentumsnachweis

²¹Siehe Abschnitt

²²Derzeit beträgt das Protokolllimit 483 HTLC, dieses ändert sich ggf. in zukünftigen Softwarever- sionen

Liquidität des Opfers gesperrt wird. Die Kapitalbindung ist bei diesem Angriﬀ höher als beim Channel-Jamming-Angriﬀ, da der angreifende Node mehr Mittel benötigt, um fehlgeschlagene Zahlungen durch das Ziel zu leiten.

Auch Harris et. al beschreiben in ihrem Forschungspapier Flood & Loot: A Systemic At- tack On The Lightning Network den DoS-Vektor als systematisches Problem des Netz- werks, wenn der Angriﬀ gezielt gegenüber mehreren Nodes eingesetzt wird [6]. Dadurch ist es einem Angreifer theoretisch möglich, einen Teil der Gelder der Opfer zu stehlen. Ebenso wird dieser von Mizrahi et. al in ihrem Papier Congestion Attacks in Payment Channel Networkserwähnt [11]. Allerdings gibt es bisher keine Berichte über erfolgreiche Angriﬀe dieser Art.

4.6. Sicherheit & Prävention

Die Sicherheit eines Systems steht oft im Zielkonﬂikt zur Benutzerfreundlichkeit. Oft muss ein Benutzer sich in puncto Anwenderfreundlichkeit einschränken, um unbefug- ten Dritten eine Kompromittierung so schwer wie möglich zu machen. Im Fokus eines Lightning Node steht die Sicherheit der zu verwaltenden Bitcoin. In diesem Abschnitt werden einige Methoden zur Lösung der genannten Risiken präsentiert, die eine gute Balance aus Benutzerfreundlichkeit und Sicherheit bieten.

4.6.1. Remote Signing

Das wichtigste Thema bei dem Betrieb eines Nodes ist die Sicherheit der zu verwaltenden Gelder. Um das genannte Hot Wallet Risiko zu minimieren, eignet sich die Möglichkeit der Verwendung eines Fernsignierungs-Prozesses (engl. Remote Signing).

Nach Angaben von Lightning Labs bezieht sich Remote Signing auf einen Betriebs- modus von lnd, bei dem das Wallet des Nodes in zwei Instanzen unterteilt ist, und jede Instanz unabhängig von der anderen läuft [110]. Eine Instanz läuft im reinen Beob- achtungsmodus (engl. watch-only mode ), wodurch sich nur öﬀentliche Schlüssel in der Wallet beﬁnden. Die zweite Instanz, der „Fernunterzeichner“ (engl. Remote Signer), hat denselben Zugang zu der Wallet, einschließlich der privaten Schlüssel.

Der Vorteil eines solchen Ansatzes liegt darin, dass die Instanz mit den privaten Schlüsseln, bis auf eine einzige eingehende Kommunikationsverbindung vollständig oﬀ- line sein kann. Die Instanz des Fernunterzeichners kann auf einem anderen Gerät mit strengeren Sicherheitsvorkehrungen im Netzwerk laufen. Dadurch ist gewährleistet, dass ein kompromittiertes System nicht zum vollständigen Verlust der Gelder führt.

4.6.2. Hardwaresicherheit

Um dem genannten Szenario eines Hardwareausfalls zu entgegen, eignet sich zur Mi- nimierung der Eintrittswahrscheinlichkeit die Verwendung eines Uninteruptable PowerSupply(UPS)²³). Das Gerät gewährleistet im Falle eines Stromausfalls den weiteren Betrieb eines Nodes und ist in Verbindung mit einer mobilen Datenverbindung eine Ab- sicherung gegen einen Totalausfall. Insbesondere wenn Lightning Nodes über dedizierte Hardwaregeräte wie einen Raspberry Pi in Breitengraden mit häuﬁgen Stromausfäl- len betrieben werden, ist die Inbetriebnahme eines UPS für den reibungslosen Betrieb unerlässlich.

4.6.3. Sicherung der Backups

Das Static Channel Backup wird bei einer Statusänderung der Zahlungskanäle aktuali- siert und auf der SD-Karte sowie auf der Festplatte des Nodes abgelegt. Es beinhaltet nicht die letzten Guthabenstände der Kanäle, was ein erhebliches Restverlustrisiko der Gelder für den Nodebetreiber aufweist.

Zur Eliminierung des Risikos ist in der Protokollspeziﬁkation von LND die Verwen- dung von sog. Watchtowernvorgesehen. Auch Antonopolous et al. empfehlen den Ein-

Watchtower sind ein Mechanismus zur Auslagerung

der Überwachung und Sanktionierung von Verstößen [45]. Sie werden in Watchtower

Towerund Watchtower Clientsunterschieden [3, S. 193].

Watchtower Tower sind Nodes, welche für andere Nodes die aktuellen Zahlungs- kanalstände speichern und demnach eine unabhängige, protokollbasierte Schlichtungs- partei bilden. Wenn ein Partnernode nun einen veralteten Zahlungskanalzustand auf der Blockchain veröﬀentlichen würde, kann der Watchtower Tower die aktuelle Version zeitgleich veröﬀentlichen und den betrügenden Node durch einen Verlust der Gelder im Zahlungskanal sanktionieren. Es gibt zwei Arten von Towern: Tower, die eine Beloh- nung für ihren Dienst beanspruchen und „altruistische“ Tower, die keine Teilzahlung der Gelder im Falle der Notwendigkeit beanspruchen [45].

Watchtower Clients sind hingegen Nodes, die den Service von Towern beanspruchen. Ein Watchtower Client kann eine unbeschränkte Anzahl an Towern einrichten, um sich gegen das Verlustrisiko abzusichern. Eine Einrichtung erfolgt mithilfe des Kommando- zeilentools lncli unter LND.

docker exec lnd lncli wtclient towers

Das towers Kommando ermöglicht die Abfrage der aktuellen Watchtower. Im Stan- dardfall ist kein Watchtower eingerichtet und die Ausgabe leer. Als nächstes wird ein Watchtower anhand seiner öﬀentlichen Konnektivitätsinformationen ²⁴ hinzugefügt. In diesem Beispiel wurde ein anonymer, öﬀentlicher Tower ausgewählt.

Abschließend folgt die Abfrage der Watchtower Tower/Server Informationen durch die Einbindung des —include-sessions Parameters in Kombination mit der Node-ID (No- de Public Key).

In der Code-Darstellung in 4.3 ist im JSON-Format im Attribut sessions in Zei- le 8 eine aufschlussreiche Leistung der Einstellungen des Towers gelistet. Zu diesen zählen die Anzahl der Backups (num_backups), die Anzahl der noch durchzuführenden Backups (num_pending_backups), die Anzahl der maximal mit diesem Tower durchführ- baren Backups, und die Informationen mit welcher Gebühr die On-Chain-Transaktion im Falle einer Protokollsanktionierung durchgeführt werden soll (sweep_sat_per_byte, sweep_sat_per_vbyte).

Verbesserungen und Weiterentwicklungen im Bereich von Watchtowern wurde u.a. von Rahimpour et al. in ihrem Forschungspapier Hashcashed Reputation with Application in Designing Watchtowersvorgeschlagen, welches ein Reputationssystem für die breite Anwendung in gebührenpﬂichtigen Watchtowern formalisiert [15].

4.6.4. DoS-Schutz

Anchor-Channels

Bei sog. Anchor-Channelshandelt es sich um eine verbesserte Version von regulären Zahlungskanälen [3, S. 438f]. Im Falle einer forcierten Zahlungskanalschließung erlau-

²⁴Das bekannte Tupel aus Node Public Key und Socket

Programm 4.3:Informationsabfrage des Prototypen über erstellte Sicherungskopien

Abb. In Leseprobe nicht enthalten.

ben Anchor-Channels der Closing-Transaktion eine dynamische Gebührenstruktur zu verleihen, sodass die Wahrscheinlichkeit einer Blockbestätigung beschleunigt wird und der Zahlungskanal damit schneller als geschlossen gilt. Eﬀektiv verringert diese Option des Zahlungskanals das Szenario des genannten Flood- & Loot-Angriﬀs und den damit einhergehenden ﬁnanziellen Schaden. Innerhalb der LND-Konﬁgurationsdatei wird sie mit der Option [s. S. 102 ]

aktiviert und ist nach einem Neustart von LND sofort mit allen Zahlungskanalpartner- nodes aktiv, die ebenfalls Anchor-Channels unterstützen.

Circuit Breaker

Das Tool Circuit Breakerist von einem ehemaligen Entwickler von Lightning Labs Inc., Joost Jager, programmiert und veröﬀentlicht worden [112]. Nach eigenen Angaben ist Circuit Breaker eine „Firewall“ für Lightning Nodes. Es ermöglicht Nodes sich vor ei- ner Überlastung mit eingehenden Zahlungen zu schützen. Mit Circuit Breaker kann für jeden Partnernode ein Höchstwert für die Anzahl der im Umlauf beﬁndlichen HTLCs festgelegt werden. Bekannten und vertrauenswürdigen Nodes kann beispielsweise ein höheres Maximum zugewiesen werden, während ein neuer Kanal von einem bisher un- bekannten Knoten auf nur wenige HTLCs beschränkt werden kann.

4.7. Syllabus

Die Implementierung des Node vollzog sich über mehrere Stadien. Angefangen von der Wahl der passenden Soft- und Hardware über die Installation und Inbetriebnahme der Komponenten bis hin zu Konﬁguration und Optimierung im laufenden Betrieb. In allen Stadien der prototypischen Implementierung wurde stets auf eine praxis- und reali- tätsnahe Vorgehensweise geachtet, damit die Reproduktion und Erkenntnisfähigkeit der Umsetzung gewahrt bleibt.

Die ausgewählte Software-Architektur des Umbrel-Projektes ist aufgrund ihrer Multi- Container-Docker-Images eine moderne Plattform-Architektur, die dank des Open-Source- Ansatzes eine hohe Popularität im Bereich der Lightning Node Enthusiasten genießt. Ein Prototyp eines Systems muss stets einen repräsentativen Charakter haben, damit der induktive Ansatz für einen Erkenntnisgewinn aus diesem vorliegt. Im Falle der Wahl auf der genannten Software-Stack in Abschnitt 4.2 war diese Eigenschaft mehrfach gege- ben. Einerseits durch die geschilderte moderne und modulare Architektur, andererseits durch die Wahl der am weitesten verbreiteten Lightning Node Implementierung: LND.

Die Konﬁguration dieser Lightning-Implementierung wurde in Abschnitt 4.3 aus- führlich aufgezeigt und einzelne Parameter einer Standard-Umbrel-Installation detail- liert beschrieben. Individuelle Node Informationen des Prototypen zeigen die Details einer einzelnen Instanz auf. Bedeutsam sind die Informationen vor allem für die Kon- nektivität im Netzwerk. Je nach Präferenz und Gebrauch muss sich ein Nodebetreiber für ein Betriebsszenario des Lightning Node entscheiden und diesen dahingehend konﬁ- gurieren. Drei Szenarien wurden beschrieben, von welchen das Routing Node Szenario die proﬁtablste Betriebsform im Lightning Netzwerk darstellt.

Basierend auf dieser Annahme wurde in Abschnitt 4.4 Inbetriebnahme ein Kriterienkatalog deﬁniert und die praxisnahe Umsetzung dieser Kriterien erarbeitet. Zu diesen Kriterien zählen die Optimierung des Betriebs auf Erreichbarkeit, Stabilität, Aktivität, Kapitalisierung und Rücklagen. Jedes einzelne Kriterium wurde separat abgehandelt und mittels Softwaretools und -skripten bestmöglich praktikabel verwirklicht. Hierbei wurde unter anderem ersichtlich, dass sich das Themenfeld zunehmend professionalisiert und es für jede Art von Konﬁgurationsthematik (z. B. Rebalancing von Zahlungskanä- len) speziﬁsche Werkzeuge für Nodebetreiber gibt. Der im Geiste der Open-Source- Entwicklung geprägte Ansatz führt konstant von einer individuellen Verbesserung des Nodebetriebs zu einer gesamtheitlichen Verbesserung des Lightning Netzwerks wie bei- spielsweise im Bereich der Zahlungsweiterleitung (Routing).

Zu guter Letzt behandelt die Thematik des Nodebetriebs die Intersektion aus Fi- nanzwelt und Technologie. Das Novum zur Verwaltung von Geldern mit der Finanztech- nologie der Lightning Nodes bringt auch einige nicht zu unterschätzende Risiken mit sich. Einige von ihnen wurden im Abschnitt 4.5 Operative Risikengenannt. Die popu- lärsten und zumeist auch die fatalsten unter ihnen wurden präsentiert und verdeutlicht. Gegen einige dieser Risiken kann ein Nodebetreiber aktiv etwas unternehmen und bei anderen Risiken besteht eine Abhängigkeit von den zugrundeliegenden Entwicklern auf Protokollebene oder im Falle des Betriebssystems von den Umbrel-Entwicklern.

Die aktiv zu ergreifenden Maßnahmen gegen die genannten Risiken werden in Ab- schnitt 4.6 Sicherheit & Präventionaufgezählt. Neben der Schaﬀung eines Bewusstseins für die gängigen Risiken mittels operativer sicherheitsorientierter Vorgehensweise (z. B.

mit Hot Wallets), ist auch der Einsatz weiterer Software zur Absicherung gegen Risiken eine klare Empfehlung für den reibungslosen Nodebetrieb.

Die in diesem Kapitel genannten Handlungsempfehlungen wurden auf dem verwen- deten Prototyp erfolgreich umgesetzt. Ziel war es, die deﬁnierten optimalen Kriterien sinnvoll zu implementieren und die Forschungsunterfrage nach dem reibungslosen Be- trieb eines Lightning Nodes zu beantworten. Auf der von Lightning Labs betriebenen Webseite Lightning Terminal lässt sich der weltweite Rang eines jeden öﬀentlichen Light- ning Node einsehen.

Insgesamt wurde Platz 504 von derzeit mehr als 19.000 routingfähigen Nodes erreicht, wie in Abbildung zu sehen ist²⁵. Die Begründung für die gute Positionierung

innerhalb des Netzwerks ﬁndet sich einerseits in der Anwendung der genannten Soft- waretools (z. B. regelmäßiges Rebalancing der Zahlungskanäle) und andererseits durch die Wahl bestimmter Parameter wie der Median der Zahlungskanalgröße von 3 Mio. Satoshis.

Trotz des Erfolgs der Umsetzung und der geringen Hürde zur Partizipation im Netz- werk schlussfolgert der Autor keine zukünftige Platzierung von Routing Nodes für je- den Nutzer des Lightning Netzwerks. Zwar steht Privatpersonen mit entsprechendem Fachwissen die Möglichkeit des Betriebs oﬀen, doch ist in diesem von Konkurrenz domi- nierten Umfeld ein immenser Zeitaufwand erforderlich. Für die weitere Verbreitung des Kryptotransaktionssystems Bitcoin wird sich der Betrieb von routingfähigen Lightning Nodes deshalb zunehmend professionalisieren.

Lightning Node Betreiber sind wichtige Infrastrukturanbieter im virtuellen Raum und ermöglichen durch ihre Dienstleistungen die massentaugliche Adoption von Bit- coin. Die Anbieter der neuen Zahlungsinfrastruktur werden Lightning Service Provider genannt. Im nächsten Kapitel wird das Lightning Service Provider Modell näher be- leuchtet.

Abb. In Leseprobe nicht enthalten.

Abbildung 4.4:Weltweiter Rang des Prototypen auf Lightning Terminal [49]

²⁵Stand: 07. März 2022

Kapitel 5

Lightning Service Provider Modell

In diesem Kapitel wird das Lightning Service Provider Modell vorgestellt. Die Erfahrungen aus der prototypischen Implementierung stellen dabei den Ausgangspunkt des Forschungsvorhabens dar. Der folgende Abschnitt erläutert aufbauend auf den gesammelten Erkenntnissen in Kombination mit geführten Experteninterviews und qualitativen Lite- raturquellen eine Einordnung von Lightning Service Providern. Das Kapitel besteht aus fünf Teilen und beginnt mit der Inhaltsanalyse des Experteninterviews. Darauf folgt die Darlegung der Wortherkunft, die Möglichkeiten zur Unterscheidung von LSP, die aktuellen Herausforderungen sowie passende Lösungsansätze. Zu diesen Lösungen zäh- len auch Ansätze, die die Forschungsunterfrage nach der skalierbaren Integration einer hohen Anzahl an neuen Nutzern beantwortet. Abschließend resultiert ein allgemeiner Vergleich vom Konzept Neobank und LSP.

5.1. Interview

Um Informationen aus erster Hand zu erhalten, wurden im Rahmen dieser Masterar- beit neben der Literaturrecherche mehrere Interviews zum Thema Lightning Service Provider durchgeführt¹. Die drei interviewten Experten haben ausdrücklich darauf be- standen anonym zu bleiben und nicht namentlich genannt zu werden. Auch das Gespräch durfte lediglich in nur einem Interview aufgezeichnet werden. Die Erkenntnisse des auf- gezeichneten, transkripierten und aufschlussreichsten Interviews ﬁnden sich in diesem Abschnitt.

5.1.1 Vorgehensweise

Bei der Anwendung qualitativer Forschungsmethoden folgen Forscher laut Amaratunga et al. einem ﬂexiblen und explorativen Forschungsansatz [1, S. 22]. Da die Forschungs- fragen der vorliegenden Arbeit einen solchen explorativen Charakter haben, basiert das Interview auf qualitativen Forschungsmethoden. Im Vergleich zur quantitativen For- schung, die Hypothesen mit mathematischen oder statistischen Methoden überprüft, bewertet die qualitative Forschung nach Ketokivi et al. die Konzepte im Hinblick auf ihre Bedeutung und Interpretation in speziﬁschen Untersuchungskontexten [8, S. 233]. In Bezug auf die vorliegende Arbeit besteht das Ziel des Interviews also darin, die prak- tischen Erfahrungen eines Experten auf dem Gebiet der Routing Nodes zu sammeln und induktiv zu erweitern.

In einem Experteninterview wird eine Person zum Experten erklärt, die einen Über- blick über ein bestimmtes Wissensgebiet hat. Daher wurde eine Person interviewt, die im aufstrebenden Themenfeld der Lightning Service Provider arbeitet und praktische Erfahrungen weitergeben kann. Die für das Interview befragte Person muss aufgrund eines non-compete agreements ² anonym bleiben. Sie ist dem Autor namentlich bekannt. Im Allgemeinen gibt es drei Arten von Interviews in Relation zum Grad ihrer Struktu- rierung: narrative/oﬀene, teil-strukturierte und strukturierte Interviews [7, S. 3]. Nach Kaiser gehören qualitative Experteninterviews entweder zu den semi-strukturierten oder den strukturierten Interviews, was bedeutet, dass sie teilweise oder vollständig gelenkt sind. Aufgrund der Vorteile der Kombination von strukturierten und oﬀenen Fragen wurde in dieser Arbeit der Fokus auf ein teil-strukturiertes Interview gelegt. Dies ge- währleistet genügend Spielraum, um je nach Interviewsituation spontan neue Fragen und Themen einzuführen oder Themen herauszuﬁltern.

Die Durchführung des qualitativen Experteninterviews orientierte sich an den von Kaiser vorgegebenen Vorgehensschritten [7, S. 12]. Demnach wurde zunächst der Inter- viewleitfaden aus den Forschungsfragen und den theoretischen Grundlagen entwickelt (Fragenkatalog). Die abschließenden Schritte des Kaiser’schen Ansatzes umfassten die Transkription der Interviews, die Kodierung sowie die theoriegeleitete Generalisierung und Interpretation [7, S. 12].

Das vollständig transkribierte Interview ist in Anhang englischer Sprache zu ﬁnden.

¹Zeitraum: Dezember 2021 bis Janaur 2022

²Im deutschen Recht analog als Wettbewerbsverbotsklausel bezeichnet

5.1.2 Inhaltsanalyse

Das Experteninterview wurde mittels qualitativer Inhaltsanalyse ausgewertet. Die qua- litative Inhaltsanalyse versucht, den Inhalt systematisch zu reduzieren und entsprechend den Forschungsfragen und der zuvor analysierten Literatur zu strukturieren [7, S. 90]. Im nächsten Abschnitt werden die Kernaussagen des Interviews zusammengefasst. Ein Verweis auf die jeweilige Aussage ist mittels Seitenangaben für den Anhang eingebun- den.

Die interviewte Person gründete ein Unternehmen im Bereich der professionellen Routing Nodes. Während des Interviews wurde mit vorher gewählten Fragen aus dem Fragenkatalog sowie spontanen Fragen ein Leitfaden für den Inhalt gewählt. Die In- haltsanalyse lässt das Gespräch retrospektiv in sechs wesentliche Themen gliedern:

• Zukünftige Entwicklungen des Lightning Netzwerks

• Entwicklungspotential und Branchen von LSP

• Voraussetzungen für die zukünftige Infrastruktur

• Proﬁtabilität von Routing Nodes

• Adoption von Bitcoin Lightning und

• Sonstige themenverwandte Inhalte

5.1.3 Resultate

Motivation für die Gründung des Unternehmens war die Erkenntnis, dass Routing No- des „pretty hard to manage“[s. S. 106] sind. Wegen der Tatsache, dass die Branche rund um professionelle Nodeverwaltung noch am Anfang steht, wurde die Chance zur frühzei- tigen Gründung ergriﬀen. Nach eigenen Berechnungen des Gründers wird davon ausge- gangen, dass Routing Nodes einen wesentliches Teil des in Zukunft mehreren Milliarden US-Dollar schweren Markt für Bitcoin-Lightning-Transaktionen bestimmen [s. S. 109]. Die Annahme basiert auf der Projektion vergangener „Bitcoin Adoptionszyklen“, welche sich exponentiell in den letzten Jahren verhalten haben³. Ziel des Unternehmens ist es, in diesem entstehenden fee market, also dem Markt für Lightning-Transaktionsgebühren, frühzeitig eine wichtige Marktposition zu erarbeiten und von den zukünftigen Ent- wicklungen des Lightning Netzwerks zu proﬁtieren [s. S. 109].

Geschäftsmodelle für die Anwendung von Lightning-Transaktionen werden nach An- gaben des Interviewpartners wesentlich im Bereich von eSports und Online Gaming stattﬁnden [s. S. 106]. Grundlage der Argumentation ist die Annahme, dass die Dis- ruption bestehender Plattformen durch Lightning-kompatible Applikationen vollzogen wird. Bedeutsam hierfür ist die gänzlich neue direkte, monetäre Verknüpfung von Spie- lern in der Online-Welt [s. S. 106]. Geschäftsmodelle im Bereich der Routing Nodes wer- den sich auf die eﬃziente Verwaltung von Geldern fokussieren [s. S. 107]. Nach Ansicht des Interviewpartners gibt es im Bereich der Sicherheit und Verwaltung von Lightning Nodes diverse ungelöste Problemstellungen, welche zukünftig noch gehandhabt werden müssen. Neben dem eﬃzienten Verwalten von Konten (engl. account management) ist auch die eﬃziente Allokation von Liquidität ein ungelöster Problemfall. Entscheidend

³Die Prognose für die Entwicklung der Marktkapitalisierung des Bitcoin und Lightning Netzwerks wurde vom Interviewpartner auf das Jahr 2026 extrapoliert.

für das Entwicklungspotential und die Branchen von LSP ist also die Ansie- delung des LSP im Infrastrukturbereich des Lightning Netzwerks oder im Bereich der Dienstleistungen, welche Lightning-Technologie nutzen, oder beide Tätigkeitsfelder.

Die Voraussetzungen der zukünftigen Infrastruktursind nach Ansicht des In- terviewpartners nur durch professionelle Anbieter zu lösen. Zum Einsatz kommen wie bei gewöhnlichen Hosting-Dienstleistern Cloudserver oder On-Prem-Server, um eine ausrei- chend leistungsstarke Architektur zu gewährleisten. Auf die Frage zur Zentralisierung der Nodebetreiber, verwies der Interviewpartner auf die zugangsfreien Eigenschaften des Netzwerks, welches einen barrierelosen Einsteig in den Wettbewerb ermöglicht [s. S. 107]. Aktuell ist der Betrieb von Routing Nodes auch im professionellen Betrieb nach Einschätzung des Interviewpartners wenig rentabel [s. S. 107]. Die Volumen an Trans- aktionen sind im Verhältnis zu den geringen Gebühren pro Transaktion zu niedrig. Die generelle Pro ﬁtabilität von Routing Nodesist nach derzeitigem Stand also noch niedrig. Hierbei ist wieder das Themenfeld der Allokation von Kapital von Bedeutung. Der Markt für eine eﬃziente Einteilung und Zuteilung von Zahlungskanalkapazitäten ist bisher zu unterentwickelt. Als Mindestanforderung für einen proﬁtablen Nodebe- trieb empﬁehlt der Interviewpartner eine Anzahl von mindestens fünf Kanälen und ein Kapitaleinsatz von 30 Millionen satoshis ⁴ (0,3 Bitcoin) [s. S. 108]. Das Auﬃnden ei- ner Nische innerhalb des Netzwerks und die passende Kapitalallokation kann zu einem überdurchschnittlichen ﬁnanziellen Ertrag führen.

Ein besonders aktuelles Thema des Interviews war die Massenadoption von Bitcoin Lightning wie sie beispielsweise in El Salvador stattﬁndet [s. S. 108]. Die Einschät- zung des Interviewpartners ist es, dass eine Massenadoption aufgrund der Expansion professioneller LSP schnell stattﬁnden kann. Der Betrieb eigener Nodes wird Privat- personen zukünftig ebenfalls oﬀen stehen, jedoch ist die Erfolgswahrscheinlichkeit des Netzwerks maßgeblich von den professionellen Anbietern und deren Erfolg abhängig. Von besonderer Bedeutung, so die interviewte Person, ist auch der rasante Fortschritt des Lightning Netzwerks. Innerhalb von drei Jahren wurden vielschichtige Protokolle und Lösungen programmiert [s. S. 108 ]. Der allgemeine Entwicklungsansatz im Light- ning Netzwerk ist merklich schneller als die Entwicklungsgeschwindigkeit der Software für die Bitcoin-Blockchain. Es werden konstant neue Konzepte entwickelt, welche die Chancen erhöhen die massenhafte Adoption von Bitcoin Lightning weiter voranzubringen.

Sonstige themenverwandte Inhaltedes Interviews umfassten die e Meinung zu El Salvador’s Bitcoin Adoption, sowie Verfahren zur Veröﬀentlichung von digitalen Vermögenswerten auf Bitcoin Lightning. Das beinhaltete bekannte Lösungsansätze als auch andere existente Zahlungskanalnetzwerke im DeFi-Bereich. Diese Themen werden allerdings als nicht relevant für den weiteren Verlauf der Arbeit gewertet und können im Anhang B im Original nachgelesen werden.

In den kommenden Abschnitten des Kapitels wird durch ergänzende Informationen, die von Enthusiasten, Gründern und Forschern im Bereich des Lightning Netzwerk und der Lightning Service Provider stammen, die Wortherkunft und Funktion(Abschnitt 5.2), die Abgrenzung und Unterscheidung (Abschnitt 5.3) und die aktuellen Herausfor- derungen und Lösungsansätze (Abschnitt 5.4) abgeleitet.

⁴In etwa 13.000€ (Wechselkurs zum Zeitpunkt 29. März 2021: ≈43.000e/B)

5.2. Wortherkunft

Die Wortherkunft und die Deutung des Begriﬀs Lightning Service Provider werden in diesem Abschnitt anhand seiner Funktion erläutert.

5.2.1. Begriﬀ

Der Begriﬀ Lightning Service Provider (LSP) tauchte erstmalig im Jahr 2019 im Beitrag Introducing Lightning Service Providersvon Breez Technologyauf der Plattform Medi- um auf [71]. Das Unternehmen Breez Technology entwickelt nach eigenen Angaben einen Lightning Client in Form eines gleichnamigen Wallets (Breez Mobile) und einen Light- ning Hub⁵, welcher das Netzwerk in seiner Funktion als Zahlungsinfrastruktur stärkt [78]. Roy Sheinfeld, der Gründer von Breez Technology, schrieb in seinem Beitrag über den zunehmenden Bedarf an Dienstleistern im Umfeld der Lightning Technologie [71]. Die Wortschöpfung von Lightning Service Provider und die vorhandene Analogie zu Internet Service Provider ist nicht zufällig gewählt. Sheinfeld weist darauf hin, dass beide Arten von Anbietern die gleiche Aufgabe haben: Nutzer mit einem Netzwerk zu verbinden.

Eine auf der Webseite von Breez veröﬀentlichte Graﬁk, welche die Funktion(en) eines Lightning Service Provider zeigt, ist in Abbildung 5.1 dargestellt. Darin wird die Verknüpfung von Anbietern und Nutzern graﬁsch dargestellt.

Abb. In Leseprobe nicht enthalten.

Abbildung 5.1:Graﬁsche Darstellung der Tätigkeitsfelder eines LSP [79]

⁵Einen Lightning Node als strukturellen Aggregator von Zahlungskanälen

5.2.2. Funktion

Aus Sicht der Nutzer sind LSP nach Sheinfeld Vertragspartner ⁶ für die Interaktion mit dem Lightning Netzwerk, da sie im Grunde genommen die Verwaltung der Zahlungs- kanäle übernehmen [71]. Die bereitgestellten Dienstleistungen sind demnach struktu- reller Natur, damit Zahlungen im Lightning Netzwerk aus Sicht des Nutzers konsistent und reibungslos funktionieren. Nach dieser Deﬁnition werden in Anlehnung an die Ent- würfe des Unternehmers Roy Sheinfeld fünf verschiedene Aufgabenfelder eines LSPs abgeleitet, welche erbracht werden [71]:

5.2.2.1. Bereitstellung von Liquidität im Netzwerk

5.2.2.2. Unterstützung von (Light-)Nodes mit neuen Zahlungskanälen (Inbound Capacity)

5.2.2.3. Weiterleitung von Daten und Zahlungen (Routing)

5.2.2.4. Ausgleich der Zahlungskanäle mit anderen LSP (Rebalancing)

5.2.2.5. Gewährleistung von Zuverlässigkeit und Redundanz (Reliability)

Diese Art von strukturellen Problemen lösen Lightning Service Provider. Sie bieten den Nutzern eine stabile Verbindung zum Lightning Netzwerk, eine vereinfachte Zahlungs- kanalverwaltung und Liquidität. Dadurch vervielfachen LSP die Zugangsmöglichkeiten der Nutzer zum Lightning Netzwerk. Gleichzeitig verringern LSP die Anforderungen an die zu investierende Zeit und das zu erlernende Fachwissen ihrer Nutzer. Im abstrakten Sinn können LSP außerdem als Fusion der Konzepte von Internet Service Providern, Financial Service Provider und Payment Service Provider betrachten. Sie sind Internet Service Provider, da sie die Aufgabe haben, Datenpakete (Zahlungen) ihrer Nutzer zu den richtigen Endpunkten weiterzuleiten. Sie sind Financial Service Provider, indem sie beispielsweise das Clearing für ihre Nutzer übernehmen und weitere Finanzdienstleis- tungen anbieten. Zu guter Letzt sind sie auch Payment Service Provider, weil sie die Zahlungsabwicklung übernehmen.

Ein ebenfalls neuartiger Charakterzug von LSP ist zudem das oﬀene Vertragsmodell, welches Nutzern jederzeit ermöglicht ihre Gelder von einem LSP zu einem anderen zu migrieren. Es eröﬀnet die Chancen für einen freien Wettbewerb unter Lightning Service Providern. Im Gegensatz zu klassischen Bankkonten oder Konten bei FinTech-Anbietern besteht zu jedem gegebenen Zeitpunkt die Möglichkeit der sofortigen, unilateralen und vollständigen Migration der Gelder von LSP zu LSP – unabhängig von jeglicher Regu- latorik und vollständig softwarebasiert.

⁶Beispielsweise in Form von Service Level Agreements

5.3. Unterschiede von LSP

In diesem Abschnitt werden geographische als auch topologische Strukturen als Unter- scheidungskriterium für LSP präsentiert.

5.3.1. Möglichkeiten zur Unterteilung von LSP

Im bisher einzigen Standardwerk Mastering the Lightning Network von Antonopolous et al. taucht der Begriﬀ der Lightning Service Provider bisher nicht auf. Eine nähere Klassiﬁzierung zur Unterscheidung von LSP ﬁndet sich in der existierenden Literatur bisher nicht.

Da im Prinzip jeder Lightning Node die Möglichkeit besitzt zu einem Dienstleister zu werden, ist die Eintrittsschwelle für den Betrieb eines Dienstleisters mit dem Betrieb eines Lightning Nodes gleichzusetzen. LSP können daher in jeder Größenordnung ent- stehen, einzig und allein beschränkt durch die technischen Limitierungen eines einzelnen Nodes und den regulatorischen Rahmenbedingungen.

In der von Zabka et al. veröﬀentlichten empirischen Analyse zur Unterscheidung von Node-Implementierungen ﬁnden sich Muster zur Verteilung der Nodes. Auﬀällig ist, dass Nodes sich innerhalb eines Landes um die Städte herum gruppieren und generell meist in Ballungsgebieten vorzuﬁnden sind [21, S. 133]. Grund hierfür ist, dass die Infrastruktur bei der Verteilung von Nodes innerhalb eines Kontinents oder Landes eine wichtige Rolle spielt.

In der Analyse von Zabka et al. traten noch auﬀallendere Muster hervor, die Auf- schluss über die Topologie des Netzwerks und innerhalb dessen über die Vernetzung von LSP gibt. Eines der Muster sind die Häuﬁgkeit von Verbindungen zwischen bestimm- ten Ländern. Besonders in Ländern, so schlussfolgern Zabka et al., die entweder die gleiche oder ähnliche Sprache oder Ethnie teilen, häuft sich die Anzahl an Zahlungska- nalverbindungen [21, S. 133]. Beispielsweise haben ihre ersten Analysen ergeben, dass Argentinien 80% der Zahlungskanäle mit Paraguay teilt. Auf dem afrikanischen Konti- nent teilt Kenia mehr als 70% der Zahlungskanäle mit Südafrika. Im Reich der Mitte teilt China wiederum die meisten Zahlungskanäle mit Taiwan und einige Kanäle mit Japan und Hongkong. In Osteuropa teilt Slowenien die meisten Zahlungskanäle mit Kroatien, Tschechien und Bulgarien. In Zentralamerika teilt Mexiko mit anderen lateinamerikanischen Ländern wie Kolumbien, Chile, Puerto Rico und Argentinien die meisten Zahlungskanäle. Weiterführende Studien zur länderübergreifenden Vernetzung von Nodeverbindungen existieren nach aktuellem Stand bisher nicht.

5.3.2. Zentralität alsUnterscheidungskriterium

In einem im Januar 2022 veröﬀentlichten Forschungspapier mit dem Titel A Centra- lity Analysis of the Lightning Networkanalysierten Zabka et al. ferner die ungleiche Verteilung des Kapitals und des Routings innerhalb des Netzwerks [20]. Ziel der Forschungsarbeit war es das Lightning Netzwerk auf sein Versprechen als dezentrales Werteübertragungs-Netzwerk zu untersuchen [20, S. 2]. Ihren Erkenntnisse nach ist das Netzwerk im Zeitraum von April 2019 bis Januar 2021 stark von Zentralisierungsten- denzen und einem hohen Maß an Ungleichheit geprägt [20, S. 2, 5]. So ist in diesem Zeitraum die Zentralisierung des Netzwerks, gemessen anhand eines Gini-Koeﬃzienten,

Abb. In Leseprobe nicht enthalten.

Abbildung5.2:Wachsender Anteil der oberen 10% Nodes über das Routing im Netzwerk in Prozent im Zeitraum von April 2019 bis Januar 2021 [20, S. 2]

um 20% gestiegen [20, S. 8]. Weiterhin kontrollieren die 10% best platzierten Nodes eine

zunehmend hohe Anzahl aller gewählter Routing-Pfade, wie Abbildung aufzeigt [20,

S. 2].

Zabka et al. resultieren, dass zum aktuellen Zeitpunkt eine kleine Anzahl von Light- ning Nodes einen beträchtlichen Teil des Routings für sich beansprucht, was zu Macht- missbrauch führen kann [20, S. 1]. Beispielsweise fokussieren die vorgestellten DoS- Angriﬀe in Abschnitt 4.5.5 sich auf Schwächen im Routing-Mechanismus von Nodes und eine hohe Zentralität macht diesen Angriﬀsvektor langfristig wahrscheinlicher. Vie- le der heutigen einﬂussreichen Nodes waren bereits in der Vergangenheit dominant im Routing. Eine starke Position in der Vergangenheit ist ihren Messungen zufolge jedoch keine Garantie für zukünftige Einﬂussnahme im Netzwerk, da andererseits viele frühere Nodes in den oberen Rängen an Einﬂuss verloren haben [20, S. 9]. Ihrer Einschätzung nach ist ein Lösungsvorschlag die Entwicklung alternativer, anreizkompatibler Routing- Mechanismen.

Das Themenfeld der Routing-Dienstleistungen ist ein Hauptgeschäftsfeld von Light- ning Service Providern, welche im nächsten Abschnitt betrachtet werden.

5.4. Herausforderungen & Lösungsansätze

Wie aus der prototypischen Implementierung aus Kapitel 4 bereits hervorging, ist die Verwaltung der Liquidität in den Zahlungskanälen von enormen Aufwand. Die gleiche Erkenntnis ergab sich aus der Inhaltsanalyse der Interviews. Dadurch ist eine zunehmene Spezialisierung in diesem Bereich gegeben.

Neben dem Liquiditätsmanagement ist auch die Verwaltung von Nutzern eine Her- ausforderung für LSP. In diesem Abschnitt werden Lösungsansätze präsentiert, um das Liquiditätsmanagement zu vereinfachen und die eﬃziente Kapitalallokation für LSP zu maximieren. Ferner wird Open-Source-Software präsentiert, welche die Nutzerver- waltung innerhalb eines Lightning Nodes ermöglicht. Die Nutzerverwaltung greift die Forschungsfrage auf, wie die Integration und Skalierung einer unbegrenzten Anzahl an neuen Nutzern potentiell realisierbar ist.

5.4.1. Liquiditätsmanagement &Kapitalallokation

“Only liquid, ﬂowing capital generates a return. Unlike a bank account, capital on Lightning is productive when it is mobile, not at rest. That’s why ﬂow is so essential. The more capital ﬂows, the more liquid it is, the more incremental returns it generates.”

– Sheinfeld in Lightning Is a Liquidity Network(2022) [72]

Im Allgemeinen sind große Zahlungkanäle besser für das Routing von Zahlungen geeignet. Aber die Aufteilung des gesamten zur Verfügung stehenden Kapitals auf nur zwei oder drei große Zahlungskanäle löst die Frage nach der Liquiditätszuteilung nicht. Wenige große Kanäle können für einen LSP ungeeigneter sein als eine größere Anzahl von kleinen Zahlungskanälen.

Die Frage, wie man sein Kapital am eﬃzientesten einsetzt, ist eine der größten Herausforderungen, die nicht nur Routing Nodes, sondern jede Art von Unternehmung im Lightning Netzwerk betriﬀt. Es müssen Anreize geschaﬀen werden, damit Liquidität gegenseitig bereitgestellt wird. Die gegenseitige Bereitstellung von eingehender Zahlungskanalkapazität wird einerseits ohne Gegenleistung, andererseits beispielsweise durch Rendite für die Bereitstellung der Liquidität erzielt. Letztere verhindert, dass der Zahlungskanal zwischen zwei Parteien wieder geschlossen wird, weil er eine gewinnbringende Kapitalanlage darstellt.

Nodes nach Kriterien zu bewerten, wie im Abschnitt 4.7 Syllabus beschrieben, ist durchaus gängig. Jedoch ist es gleichwohl schwieriger eine Bewertung zu erstellen, die die Fähigkeit eines Nodes widerspiegelt, Zahlungen eﬀektiv weiterzuleiten. Wäre ein solches Kriterium transparent und leicht reproduzierbar, würden sich alle Nodes danach richten, wodurch das Netzwerk homogen und tendenziell funktionsunfähig wäre.

Auch der Unternehmer Roy Sheinfeld ging in einem Beitrag mit dem Titel LightningIs a Liquidity Networkder Frage nach, ob das Netzwerk lediglich mehr Liquidität oder besser verteilte Liquidität benötigt [72]. Er kommt zu der Auﬀassung, dass sich beides gegenseitig verstärkt. Wenn die Liquiditätszuteilung richtig gestaltet wird, entsteht seiner Ansicht nach eine positive Rückkopplungsschleife, in der die knappe Ressource des Netzwerks (Liquidität) zum Impulsgeber wird [72].

Im Lightning Netzwerk ist die eﬃziente Zuteilung von Liquidität der zentrale Pro- zess. Der Einsatzzweck der Liquiditätszuteilung ist ein funktionsfähiges Zahlungsnetz- werk. Je besser LSP ihren Prozess der Liquiditätszuteilung durchführen, desto eﬃzienter erfüllt das Netzwerk seinen Zweck, schnelle, grenzüberschreitende Peer-to-Peer- Zahlungen zu ermöglichen. Dieses zentrale Optimierungsproblem wird nach Meinung von Sheinfeld, den Unterschied zwischen Amateur-Nodebetreibern und aufstrebenden Unternehmen ausmachen [72].

Die nächsten Unterabschnitte zeigen das Konzept der Lightning Network Reference Rate auf und beleuchten zwei Marktplätze für die Verwaltung von Liquidität als LSP.

Bhatia’s Lightning Network Reference Rate

Nikhil Bhatia, tätig an der Wirtschaftshochschule der University of Southern Califor- nia als außerordentlicher Professor für Finanzen und Betriebswirtschaft, formalisierte erstmals das Konzept der sog. Lightning Network Reference Rate (LNRR) in einem Blog-Post [25]. Das Konzept der LNRR ist lediglich theoretischer Natur und bisher in keiner Lightning-Implementierung vorzuﬁnden. Es ist jedoch von besonderem Interesse, da es sich mit der Herausforderung der Liquiditätsverteilung im Lightning Netzwerk beschäftigt. Bhatia untergliedert das Konzept in drei Bestandteile.

Lightning Nodes erhalten für die Zahlungsweiterleitung eine Gebühr. Diese kumu- lierte Gebühr über ein fest deﬁnierten Zeitraum ﬂießt nach Bhatia in die Berechnung der sog. Node Accrual Rate(NAR) ein. Die Node Accrual Rate wird als Formel zur Berechnung der Rentabilität eines einzelnen Lightning Node verwendet, ausgedrückt als annualisierter Zinssatz.

Der zweite Bestandteil besteht in der Implementierung eines Austauschs der NAR unter Nodebetreibern. Bhatia argumentiert, dass Transparenz und ﬁnanzielle Oﬀenlegung Kernbestandteile der Kapitalmärkte sind und die gegenseitige Bereitstellung der NARs vorteilhaft für das Wachstum von Bitcoin als Anlageklasse ist.

Der dritte und letzte Vorschlag ist die Einführung eines Konzepts, in dem die NARs im gesamten Netzwerk aggregiert, gemittelt und als eine Rate, die LNRR, ausgewie- sen werden. Die so entstandene LNRR ebnet den Weg für eine Reihe von relativen Wertberechnungen und hilft bei der Preisgestaltung von Liquidität (z. B. für Inbound Capacity).

Eine weitreichende Einführung seines formalisierten Konzeptes würde nach Einschät- zung von Bhatia die Gelder in Zahlungskanälen als risikoarme Alternative von Zinserträgen klassiﬁzieren. Er speziﬁziert dies im Vergleich zur Oﬀ-Chain-Kreditvergabe, wie sie über Drittparteien üblich ist. Weiterhin würde die LNRR als Referenz für die Messung von Risikoprämien verwendet werden.

Bhatia präsentiert eine Formel zur Berechnung der individuellen Node NAR. Diese setzt sich aus dem durchschnittlichen Guthaben auf dem Node p, den erwirtschafteten Routing Gebühren f, der jährlichen Zeit gemessen in Bitcoin-Blöcken als normalisier- te Konstante mit dem Wert 52.560 und der etablierten Dauer der Zahlungskanäle in Blockzeit nzusammen. Die von Bhatia entworfene Formel setzt die einzelnen Werte zur Berechnung der NAR in Relation:

NAR= (p+f )

52. 560

−1

Ein Beispiel verdeutlicht die praxistaugliche Berechnung der NAR. Angenommen ein Node besitzt eine durchschnittliches Guthaben p von 10.000.000 Satoshi. Der Node hat 100.000 Satoshi in Routinggebühren erwirtschaftet (f). Die Zahlungskanäle waren

13.140 Blöcke aktiv, was ungefähr einem Vierteljahr entspricht (n). Nach Einsetzen der Werte in die Formel, beträgt die NAR des Beispiel-Nodes 0,0406, was einem Wert von 4,06 Prozent entspricht. Die annualisierte Rendite dieses Node beträgt in der Formel von Bhatia also in etwa 4%.

52. 560

10 000 000

NAR= (10.000.000+100. 000) 13.140 −1 = 0.04060401

Die Formel von Bhatia berücksichtigt die individuelle Laufzeit der Zahlungskanäle für die Berechnung der Rendite. Allerdings ist die Formel mit der gewählten Konstante zu statisch („normalisiert“), um die Realität perfekt abzubilden. So ist beispielsweise die Anzahl jährlicher Blöcke abhängig von der Schwierigkeitsanpassung der Blockchain (engl. sog. Diﬃculty-Adjustment), welche alle 2016 Blöcke stattﬁndet und somit die Anzahl absoluter Blöcke pro Jahr beeinﬂusst. Auch Bhatia verweist auf die inhärente Unschärfe seiner Formel, welche sich als Orientierungspunkt für zukünftige Arbeiten zu der Thematik eignet.

Marktplätze für Liquidität

Mehrere Ansätze zur Lösung der Liquiditätsfrage haben sich bereits herausgebildet. Lightning Loopund PeerSwapsind zwei Beispiele von diversen verfügbaren Dienstleis- tungen für die technische Umsetzung eines eﬃzienten Liquiditätsmanagements.

5.4.1.1. Lightning Loopist eine Dienstleistung, die von Lightning Labs angeboten wird [107]. Lightning Loop ist ein alleinstehender Dienst, der die Verbindung zwischen On-Chain und Oﬀ-Chain Bitcoin mittels sog. Submarine Swapsermöglicht [106]. Der Loop-Client kommt auf LND zum Einsatz. Es gibt zwei wählbare Funktionen von Loop: LoopInund LoopOut. Während LoopIn die Möglichkeit bietet On-Chain Gelder zu senden und diese anschließend Oﬀ-Chain als eingehende Zahlungska- nalkapazität zu erhalten, eröﬀnet LoopOut die inverse Möglichkeit. Der Dienst ﬁnanziert sich durch die Gebühren, welche für den Wechsel der Gelder in beide Richtungen erhoben werden. Von Vorteil ist, dass der Dienst über eine graﬁsche Oberﬂäche ermöglicht, mehrere Zahlungskanäle in einem Swap gleichzeitig neu zu balancieren. Nachteilig an der Implementierung ist, dass die Gelder Oﬀ-Chain erst über mehrere Hops geroutet werden müssen, bevor sie für den Swap gewechselt werden können. Mehrere Hops belasten Zahlungskanäle anderer Nodes und wirken sich somit negativ auf die Liquidität der involvierten Hop-Nodes aus.

5.4.1.2. PeerSwapbezeichnet sich als ein vertrauensloses Lightning/On-Chain Rebalan- cing Protokoll [114]. Laut Togami et al. ermöglicht es das Rebalancing der Zah- lungskanäle mit Hilfe von On-Chain Geldern und wird als Plug-In auf Lightning Nodes installiert [80]. Das Rebalancing läuft über Submarine Swaps auf Peer- to-Peer-Basis. Ziel dieses protokoll-basierten Marktplatzes für Liquidität ist das Rebalancing von Zahlungskanälen mit direkten Zahlungskanalpartnernodes. An- ders als bei anderen Rebalancing-Ansätzen ist in diesem Fall kein Rebalancing über mehrere Hops nötig. Gleichzeitig wird dadurch das wiederholte Auﬀüllen der

Kanäle bis zum gewünschten Gleichgewicht realisiert. PeerSwap beﬁndet sich noch im Beta-Stadium und wird für die Lightning-Implementierungen C-lightning und LND in der Sprache Go entwickelt [114].

5.4.2. Verwaltung vonNutzerkonten

LSP haben die Aufgabe eine Vielzahl an neuen Nutzern in das Lightning-Ökosystem zu integrieren. Abseits der technisch-ﬁnanziellen Problemstellung des Liquiditätsmanagement müssen LSP die Nutzerverwaltung organisieren.

Hierbei verfügen LSP über die Möglichkeit auf eine Auswahl an Open-Source-Pro- grammen zuzugreifen, welche explizit für die bestehenden Lightning-Implementierungen optimiert sind. Die enge Verzahnung der einzelnen Komponenten gewährleistet einen adaptierten und eﬃzienten Verwaltungsprozess der Nutzerkonten. In diesem Abschnitt werden exemplarisch zwei quelloﬀene Nutzerverwaltungsprogramme vorgestellt, welche bereits produktiv eingesetzt werden. Sie repräsentieren nur einen kleinen Ausschnitt der zu Verfügung stehenden Software-Landschaft und sind unter keinen Umständen als vollständiges Abbild der möglichen Lösungsansätze anzusehen. Die Accountverwal- tung eines LSP ﬁndet in der Regel auf einer Lightning Node Instanz statt, kann sich aber beispielsweise aus Redundanzgründen über eine Vielzahl von Nodes erstrecken. Die ausdrückliche Umsetzung, einschließlich die Wahl der Software-Bausteine, obliegt den Verantwortlichen und lässt sich nicht generalisieren.

Die in diesem Abschnitt exemplarisch vorgestellten Nutzerverwaltungsprogramme LNDHubund LNBitssind treﬀende Beispiele, um die Skalierungsfähigkeit von Nutzer- konten für Lightning Nodes realitätsnah zu demonstrieren.

LNDHub

LNDHub ist ein im Stil von Mikroservice-Architekturen entworfenes Programm zur Ver- waltung einer ﬂexiblen Anzahl von Nutzerkonten [87]. Es ist in Form eines kostenlosen und quelloﬀenen Plugins verfügbar, das auf der LND-Implementierung aufbaut [87]. Da- durch ermöglicht das LNDHub-Plugin, dass Nutzer verschiedene Konten mit nur einem Node in einem vertrauensminimierten Aufbau betreiben können.

Der Aufbau von LNDHub bedient sich einer geschickten Integration aus Blockchain- und Lightning-Schicht. Im Detail sendet ein Nutzer eine On-Chain Transaktion an eine spezielle „Auﬂadeadresse“ (Bitcoin-Adresse), und dieses Guthaben wird intern seinem Konto auf LNDhub gutgeschrieben [53]. Mit diesem internen Guthaben kann der Nutzer Lightning-Transaktionen tätigen. Tatsächlich tätigt jedoch der zugehörige Lightning Node die Transaktionen im Auftrag des LNDHub-Nutzerkontos. Auf die gleiche Art und Weise funktioniert der Empfang von Geldern über Lightning, welche wiederum stellvertretend durch den Node durchgeführt werden und lediglich intern dem Guthaben des Nutzer zugeschrieben werden.

Mittels dieses Verfahrens abstrahiert die LNDHub-Software die Komplexität des Lightning Nodes von den Nutzern und ermöglicht es dennoch, eine Partizipation am Lightning Netzwerk in einem vertrauensminimierten Zustand zu ermöglichen. Eine Vi- sualisierung der Funktionsweise von LNDHub ﬁndet sich in der Abbildung 5.3. Ent- wickelt wurde LNDHub durch die BlueWallet Services S. R. L.in Kooperation mit Open-Source-Entwicklern auf GitHub in der Sprache JavaScript [87]. Das gleichnami-

Abb. In Leseprobe nicht enthalten.

Abbildung 5.3:Oﬃzielle Graﬁk der Funktionsweise von LNDHub [53]

ge Bitcoin Wallet hat LNDHub integriert und ist für diverse Betriebssysteme, darunter Smartphones verfügbar [53]. Quantiﬁzierbare Daten zu den in Betrieb beﬁndlichen Nut- zerkonten ﬁnden sich nicht, jedoch kann der Lightning Node mit seiner Konﬁguration von LNDHub über die eigene Webseite teil-auditiert ⁷ werden [54].

LNBits

Die Software LNBits proklamiert sich als „free and open-source lightning-network wal- let/accounts system“ [92]. Die aktuelle Version (v0.3 beta) von LNBits ist in Python ge- schrieben und als solche als Server-Applikation einsetzbar. Weiterhin gibt es eine Umset- zung in der Programmiersprache Go. Sie ist sowohl mit der Lightning-Implementierung C-lightning als auch mit LND kompatibel. Zu den Funktionen der Anwendung zählen nach Angaben der Entwickler [92]:

• Ein Kontensystem mit integrierten eindeutigen API-Zugängen für jedes Nutzer- konto

• Eine erweiterbare Plattform über das LNBits-Extension-Framework

• Ein Entwicklungsstack über die LNbits-API

• Eine Unterstützung für das sog. LNURL-Schema ⁸

• Eine sofortiges Wallet für Lightning-Demonstrationen

LNBits ermöglicht analog wie LNDHub eine Kapselung der Nutzerkonten als Unterein- heit innerhalb eines Lightning Nodes. Zusätzlich ist über die Nutzung des Extension- Framework eine nach dem Baukasten-Prinzip erweiterbare Funktionalität vorhanden, wie z.B. einfaches Point-of-Sale-System, ein Echtzeit-Split von eingehenden Zahlungen auf mehrere Parteien oder die Akzeptanz von Geldern über eine dedizierte Spendenseite [35].

Nach eigenen Angaben beﬁndet es sich im aktiven Einsatz bei den Lightning-Zahl- ungsdienstleistern (LSP) OpenNodeund LNPay.co [35]. Mittels Docker-Integration kann es auch auf Full-Node-Architekturen wie Umbrel eingesetzt werden [94]. Eine Live- Version der Serverapplikation als eigenständiger LSP kann unter der Webseite lnurl.com abgerufen werden [34].

⁷Im Detail handelt es sich um öﬀentliche Informationen des Nodes so wie alle Zahlungskanäle und deren Rücklagen.

⁸Das LNURL-Schema ist ein Standard für die Vereinheitlichung von Lightning-Zahlungen. Das Sche- ma beﬁndet sich in noch in der Entwicklung und spielt für diese Arbeit keine weitere Rolle.

5.5. Vergleich von LSP und Neobank

Dieser Abschnitt beleuchtet eine Gegenüberstellung von Neobanken (CeFi) und LSP (DeFi) und orientiert sich dabei an einer verallgemeinernden Beschreibung der Ver- gleichskriterien.

5.5.1. Gegenüberstellung

Im Arbeitspapier DeFi Beyond the Hypehaben die Autoren der Wharton Business Schoolder University of Pennsylvania gemeinsam mit dem World Economic Forumdie Kernmerkmale des traditionellen Finanzwesens im Vergleich zum dezentralen Fi- nanzwesen tabellarisch herausgearbeitet [17]. In Anlehnung an ihr Modell ⁹ wird dieser Vergleich auf Neobanken im traditionellen Finanzwesen und auf LSP im dezentralen Finanzwesen angewandt. Der Vergleich ﬁndet sich in Tabelle 5.1. Zu den vergleichenden Kriterien zählen:

5.5.1.1. die Verwahrung der Mittel

5.5.1.2. die Denominierung der Mittel

5.5.1.3. die Art der Transaktionsverarbeitung

5.5.1.4. das Clearing und Settlement

5.5.1.5. die Governancestruktur

5.5.1.6. die Auditierbarkeit

5.5.1.7. die Anforderungen an die Besicherung

5.5.1.8. die Interoperabilität

5.5.1.9. der Zugang und die Privatsphäre

5.5.1.10. die Sicherheit

5.5.1.11. der Schutz der Kunden

Der hier vorgestellte Vergleich kann unter keinen Umständen als vollständig betrachtet werden und ist insbesondere im Hinblick auf traditionelle Neobanken vom regulato- rischen Rahmen eines Landes oder Wirtschaftsraums abhängig¹⁰. Die entsprechenden Inhalte von LSP beziehen sich wesentlich auf die aktuell unregulierte Tätigkeit eines prototypischen LSP und kann sich durch die rechtsgültige Anerkennung eines LSPs als Unternehmen/Finanzdienstleister drastisch ändern.

5.5.2. Vergleichskriterien

Lightning Service Provider werden gemeinsam mit dem Lightning Netzwerk zu dem Be- reich der DeFi-Zahlungsnetzwerke zugeordnet¹¹. Als Unterkategorie von DeFi erben sie die Eigenschaften, welche charakteristisch für DeFi-Dienstleister sind. Auf der anderen Seite repräsentieren Neobanken das CeFi-Modell bestehender Anbieter, sodass sie die Eigenschaften traditioneller Strukturen übernehmen. Das Wharton Modell umfasst ins- gesamt elf verschiedene Kriterien anhand derer traditionelle Finanzdienstleistungen und DeFi-Dienstleistungen verglichen werden. Nachfolgend werden die Unterschiede beider

⁹Übersetzt und angepasst

¹⁰Siehe Abschnitt

¹¹Siehe Abschnitt

Arten von Anbietern beschrieben und der Vergleich der Wharton Business School um die Inhalte der LSP erweitert, welche sich im Verlauf der Masterarbeit ergeben haben. Neobanken verwahren die Mittel ihrer Kunden entweder bei einem regulierten Dienstleistungsanbieter (Großbank) oder sind selbst als Verwahrstelle lizensiert, um Kundengelder verwahren zu dürfen. Die Mittel sind in der Regel in Fiat-Währung de- nominiert, abhängig vom jeweiligen Währungsraum, in welchem eine Neobank agiert. In der Welt der dezentralen Finanzen ist der Nutzer meist selbst für die Verwahrung der Mittel verantwortlich (non-custodial) oder verwendet eine vertrauensminimierte Lö- sung. Lightning Service Provider verwenden als Denominierung der Transaktionen die

Bitcoin-Währung.

Die Transaktionsausführungerfolgt bei einer Neobank über mehrstuﬁge Interme- diäre, wie dies im Kapitel 2 Stand gegenwärtiger Zahlungsinfrastrukturen verdeutlicht wurde. Zu dieser Transaktionsausführung zählen auch der Clearing- und der Settlement- Prozess. Hier kommen erneut Dienstleister als Intermediäre zum Tragen. Lightning Ser- vice Provider üben die Transaktionsausführung direkt vom Zahler zum Zahlungsemp- fänger (P2P) aus. Die direkte, protokollbasierte Transaktionsausführung zwischen zwei oder mehreren Nutzern ¹² ﬁndet mittels Clearing zwischen Lightning Nodes statt und der ﬁnale Settlement-Prozess vollzieht sich auf der Blockchain.

Die Führung/Verwaltung der Bank, die Governance-Struktur , ist bei Neobanken üblicherweise von diversen Stakeholdern abhängig. Einerseits legt die Organisation un- ternehmensinterne Strukturen selbst fest, andererseits ist die Governance durch externe Parteien wie die Regulierungsbehörde maßgeblich beeinﬂusst¹³. Bisherige Ansätze für Lightning Service Provider richten sich oft nach der Verfahrensweise von Open-Source- Governance-Strukturen, wie dies beispielsweise bei der Lightning-Protokoll-Entwicklung der Fall ist. Besonderen Einﬂuss genießen in diesem Umfeld vor allem die Entwickler, da sie den softwareseitigen Unterbau schaﬀen.

Die Auditierbarkeit, die Oﬀenlegung und Rechenschaftspﬂicht gegenüber berech- tigen Interessensgruppen, ﬁndet im Umfeld der Neobank entweder durch Audits von beispielsweise Wirtschaftsprüfungsgesellschaften oder Regulierungsbehörden statt. LSP garantieren durch Settlement-Transaktionen und den Open-Source-Entwicklungsansatz einen hohen Grad an Transparenz. Ebenso sind Lightning Nodes und ihre Kapazitäten und Zahlungskanäle öﬀentlich einsehbar. Standards zur Auditierung von LSP existieren bisher nicht.

Neobanken wickeln wie die meisten Akteure gegenwärtiger Zahlungsinfrastrukturen ihre Transaktionen über schwebende Kreditgeschäfte ab, sodass eine Deckung der Mittel nur im Bedarfsfall notwendig ist. Jedoch sind für die Anforderungen an die Besi- cherung rechtliche Auﬂagen vorhanden, die je nach Rechtsrahmen andere Prozesse vor- schreiben. Üblicherweise handelt es sich um Rücklagen im einstelligen Prozentbereich. Transaktionen, die von LSP im Lightning Netzwerk abgewickelt werden, können pro- tokollseitig keine Abwicklungen auf Kredit ermöglichen, sodass eine hundertprozentige Deckung der Mittel jederzeit softwareseitig garantiert ist.

Neobanken sind wesentlich im Laufe der Open-Banking-Regulierung entstanden ¹⁴ und sind durch ihren „Open Finance“-Ansatz in der Lage über moderne Schnittstel-

¹²Je nach Transaktionsart, ob sie On-Chain oder Oﬀ-Chain erfolgt

¹³Siehe Abschnitt

¹⁴Siehe Abschnitt

len zu kommunizieren. Dennoch ist der Interoperabilitätsgrad aufgrund fehlender Homogenität der Schnittstellen limitiert. Begründen lässt sich die eingeschränkte Inter- operabiliät in der Segmentierung verschiedenster Zahlungsnetzwerke¹⁵, welche heutzu- tage in Betrieb sind und sich je nach Währungsraum und Regulatorik unterscheiden. Im Kontrast hierzu sind LSP wesentlich auf die gleichen Standards im Bitcoin- und Lightning-Ökosystem optimiert, sodass alle LSP die gleichen internationalen Protokoll- kommunikationsstandards implementiert haben¹⁶. Professionelle LSP können, sobald sie als rechtliches Konstrukt in Form eines regulierten Unternehmens agieren, auch Schnitt- stellen zu Banken etablieren und so eine neue, hybride Form der Interoperabilität beider Welten bieten.

Der Zugang und die Privatsphäre, welcher auch die ﬁnanzielle Inklusion um- fasst, ist bei einer Neobank maßgeblich durch die rechtlichen Vorgaben zu Identiﬁ- kationsverfahren ¹⁷ bestimmt. Die Privatsphäre der Zahlungsdaten wird beispielsweise im Euroraum durch Legislaturen wie die Datenschutzgrundverordnung gewahrt, jedoch sind bekannte 3- und 4-Parteien-Zahlungsinfrastrukturen regelmäßig Gegenstand von Datenhandel¹⁸. Im starken Gegensatz sind LSP unregulierte Anbieter, die ohne Identi- ﬁkationsverfahren Nutzern den Zugang zum Kryptotransaktionssystem ermöglichen. Sie sind unabhängig jeglicher Restriktionen für jeden frei (im Sinne der „Kontoeröﬀnung“) über die entsprechende Nutzersoftware zugänglich. Die Zahlungsdaten werden nur für die Transaktionsausführung verwertet und eignen sich aufgrund fehlender weiterer In- formationen nicht für den Datenhandel.

Die technische Sicherheitverlagert sich im Bereich der dezentralen Finanzen zu- nehmend auf Protokollrisiken. Die genannte Interoperabilität, welche eine hohe Standar- disierung ermöglicht, ist gleichzeitig anfällig für Infrastrukturrisiken. Allgemein gilt die Bitcoin-Blockchain als sicherstes dezentrales Netzwerk und die Lightning-Technologie erbt in Teilen diese Sicherheitsarchitektur. LSP müssen sich deshalb wesentlich um ope- rative Risiken kümmern ¹⁹ und sind wie Neobanken anfällig für Fehler innerhalb ihrer eigenen IT-Systeme.

Der Aspekt der Schutz der Kundenwird im klassischen Finanzwesen durch staat- lich verordnete Oﬀenlegungspﬂichten, einen geregelten Verbraucherschutz, umfassenden Maßnahmen zur Betrugsbekämpfung und festgelegte Verfügungslimits sowie Versiche- rungspolicen geregelt. Für Lightning Service Provider gibt es solche Möglichkeiten bisher nicht. In den meisten Fällen sind die Nutzer/Kunden für ihrer Gelder selbst verantwort- lich. Im Falle des Verlust des Zugangs zum LSP (bspw. LNDHub-Konto) oder dem Ver- lust der Zugangsdaten (privater Schlüssel) besteht keine Option auf Wiederherstellung der Kundengelder.

¹⁷Meist durch sog. Know-Your-Customer-Verfahren

¹⁸Siehe Abschnitt

¹⁹Siehe Abschnitt

5.6. Neobank Lightning Service Provider

Abb. In Leseprobe nicht enthalten.

Tabelle 5.1:Tabellarischer Vergleich von LSP und Neobanken in Anlehnung

an das DeFi-Vergleichsmodell der Wharton Business Schoolder University of Pennsylvania [17]

Kapitel 6

Ergebnisse & Fazit

In diesem Kapitel werden die Ergebnisse zusammengefasst und reﬂektiert sowie die Im- plikationen für die Praxis kritisch betrachtet. Als Letztes werden weitere Forschungs- schwerpunkte genannt, die sich für zukünftige wissenschaftliche Untersuchungen eignen.

6.1. Reﬂexion der Ergebnisse

Das zentralamerikanische Land El Salvador wagt als weltweit erstes Land die Adoption von Bitcoin als legales Zahlungsmittel. Die Regierung des Landes verspricht sich von der Einführung des Kryptotransaktionssystems eine langfristig bessere und kostenlose Zahlungsinfrastruktur für Inlands- und Auslandsüberweisungen. Dank der alltagstaug- lichen Lightning-Erweiterung des Bitcoin-Protokolls, die das sichere Bezahlen in Sekun- denschnelle ermöglicht, lassen sich auch niedrige Beträge nahezu kostenfrei versenden. Hierfür wurde ein staatliches Wallet entwickelt, welches den Bürgern des Landes zur Verfügung steht. Da es sich bei Bitcoin jedoch um ein oﬀenes System handelt, ist eine applikationsspeziﬁsche Bindung für die Verwendung der Währung nicht vorgeschrieben. Lediglich die Netzwerkprotokolle des Kryptotransaktionssystems regeln die einheitliche Abwicklung von Zahlungen untereinander ab. Abseits der staatlichen Initiative El Sal- vadors bleibt das Bitcoin-System ein freiwilliges „Graswurzelprojekt“. So gibt es diverse Möglichkeiten neuen Nutzern den Zugang zu der Kryptowährung zu ermöglichen.

Neben der steigenden Akzeptanz beﬁndet sich auch die technische Entwicklung einer fortwährenden Dynamik. Die davon ausgehende, wahrscheinlich disruptive Konkurrenz für etablierte Strukturen war der Anknüpfpunkt für diese Masterarbeit. Es stellte sich die Frage, ob die neu entstehenden Lightning Service Provider eine echte Alternative zu Neobanken in der FinTech-Branche darstellen. Ausgehend hiervon wurden zwei For- schungsunterfragen deﬁniert, die sich einerseits mit der Integration von neuen Nutzern und andererseits mit der technischen Vorgehensweise für den reibungslosen Betrieb der Zahlungsinfrastruktur beschäftigten.

In Kapitel 2der Arbeit wurde zu Beginn der Status quo der bestehenden Zahlungs- landschaft analysiert. Es wurde die themeneingrenzende Historie zusammenfassend be- schrieben und der Verlauf der Technik in einer größeren Zeitdimension veranschaulicht. Der Fokus lag wesentlich auf den Beschränkungen der gegenwärtigen Zahlungsinfra- strukturen, an welche traditionelle Zahlungsdienstleister jedweder Art angebunden sind.

Daraus resultieren fünf bedeutsame Limitierungen, die sich im Kern aus der zentralen Architektur des globalen Finanzsystems herleiten. Zu Ihnen zählen die Politisierung und die fehlende Neutralität des Zahlungsverkehrs, die einhergehenden kreditbasierten Systemrisiken, das Fehlen ﬁnanzieller Inklusion für einen Großteil der Weltbevölkerung, die Unwirtschaftlichkeit von Kleinstbetragszahlungen und der permanente Handel von Zahlungsdaten.

Als Gegensatz zu den zentralen Finanzstrukturen wurde in Kapitel 3ein Teilbereich der dezentralen Finanztechnologien behandelt. Innerhalb der dezentralen Finanzen spie- len Zahlungskanalnetzwerke eine bedeutsame Rolle. Auf technischer Ebene werden die alltagstauglichen Zahlungen der Bitcoin-Währung auf den Lightning Nodes abgewickelt. Die verschiedenen Arten der Node Implementierung und gemeinsame Protokollstan- dards wurden ebenso herausgearbeitet wie die populärsten Full-Node-Architekturen. Erkenntlich wurde, wie der ausgiebig aufgezeigte Trend zu mehr Miniaturisierung von Informations- und Kommunikationstechnologie auch maßgeblich Antriebskraft dieses Bereichs ist. Mit Hilfe weniger Hardwarekomponenten kann in Kombination mit quell- oﬀener und frei verfügbarer Software ein Lightning Node konstruiert werden, der an- schließend weitestgehend automatisiert als Zahlungsdienstleister tätig ist.

Nach Auswahl eines der Full-Node-Betriebssysteme wurde in Kapitel 4 der Proto- typ eines Lightning Nodes praxisnah implementiert. Dafür wurde ein bekanntes Full- Node-Betriebssystem in seine einzelnen Komponenten aufgeschlüsselt und die software- seitige Logik zur Orchestrierung skizziert. Die Konﬁguration sowie zugehörige Szenari- en wurden erarbeitet. Ein Kriterienkatalog des führenden Lightning-Entwickler-Studios für den reibungslosen Betrieb eines routingfähigen Nodes wurde übernommen und ange- wandt. Anhand der operativen Tätigkeiten wurden Risiken und Sicherheitseinstellungen zur Prävention erörtert. Die zweite Forschungsunterfrage nach dem reibungslosen tech- nischen Betrieb wurde durch einen induktiven Ansatz ausführlich beantwortet und die Ergebnisse aus der Umsetzung im Syllabus des Kapitels validiert.

Aufbauend auf den gesammelten Erkenntnissen wurden in Kapitel 5 das Lighting Service Provider Modell vorgestellt. Für eine treﬀende Einordnung wurden die gesam- melten Erkenntnisse der bisherigen Kapitel mit den Inhalten von Experteninterviews zusammengeführt und mit weiterer Literatur von Vordenkern der Materie kombiniert. Zum derzeitigen Stand gibt es abseits der eigens vorgenommenen Schematisierung bis- her keine wissenschaftliche Literatur zur Thematik der LSP. Aus der prototypischen Implementierung wurden deshalb Herausforderungen und Lösungsansätze abgeleitet, welche als Hürden für die Adoption von Bitcoin Lightning und im Speziellen für die Verbreitung von LSP gelten. Zu diesen zählt auch die erste Forschungsunterfrage nach der Integration von einer hohen Anzahl an neuen Nutzern. Über zwei bereits bestehende Softwarelösungen wurde ein Einblick in die massive Skalierbarkeit der Nutzerintegration gegeben, sodass die Transaktionslimits der Bitcoin-Blockchain keine Hürde für die Adop- tion des Kryptotransaktionssystems mehr darstellen. Zum Schluss wurde ein Vergleich zwischen den Konzepten Neobank und LSP anhand mehrerer Kriterien aufgestellt. Im nächsten Abschnitt wird die Forschungsfrage, ob LSP eine Alternative zu Neobanken in der FinTech-Branche sind, beantwortet.

6.2. Ausblick & Implikationen für die Praxis

Die FinTech-Revolution der letzten Jahre hat Neobanken als neue Innovationskraft im Bereich des Retail Bankings hervorgebracht. Das Merkmal einer Neobank ist, dass sie vollständig virtuell existiert und ihre Dienste ausschließlich online über entsprechende Anwendungen bereitstellt. Die Ausrichtung auf ein rein online-basiertes Geschäftsmo- dell hilft Neobanken erhebliche Kosten zu sparen, weshalb sie Finanzdienstleistungen kostengünstig an Kunden weitergeben können. Die digitalen Dienstleistungen sind in vielerlei Hinsicht ein Novum für den Bankensektor, so dass Neobanken gerne als Vor- reiter innovativer Prozesse genannt werden.

Allerdings wird ihr Dienstleistungsangebot weitgehend durch den Umfang bestimmt, der in Zusammenarbeit mit zugelassenen traditionellen Instituten und im Rahmen der jeweiligen Aufsichtsbehörden festgelegt wird. Die strukturelle Abhängigkeit führt da- zu, dass auch die systemischen Probleme gegenwärtiger Zahlungsinfrastrukturen auf die Beschaﬀenheit einer Neobank auswirken. Diese Limitierungen der gegenwärtigen Zahlungsinfrastrukturen sind meist historisch gewachsen und Neobanken adaptieren lediglich den vorherrschenden Status quo der gegebenen Infrastruktur. Hierzu zählt un- ter anderem das weltweite Interbanken-Kommunikationsnetzwerk SWIFT als auch die diversen Ebenen der vorgestellten Clearing- und Settlement-Systeme. Allgemein gespro- chen sind Neobanken trotz ihres innovativen Charakters Teil des Centralized Finance .

Nahezu parallel seit dem Aufkommen von Neobanken Ende der 2000er Jahre hat sich synchron das dezentrale Bitcoin-System immer weiter für Transaktionsszwecke eta- bliert. Ungefähr ein Jahrzehnt nach seiner Erﬁndung hat sich mit der Entwicklung des Lightning Netzwerks eine P2P-Infrastruktur aufgetan, die ein neuartiges Zahlungsnetz- werk geschaﬀen hat. Dieses Netzwerk wird dem Teilbereich von Decentralized Finance zugeordnet. Die Layer-2-Skalierungslösung hat wiederum einen neuen Markt für Dienst- leister eröﬀnet. Lightning Service Provider sind analog wie Neobanken im traditionellen Finanzwesen rein virtuelle Dienstleister. Ihr Geschäftstätigkeit basiert ebenso auf der vollkommenen Digitalisierung der Dienstleistungen, die es unter anderem ermöglicht jederzeit international Transaktionen über das Lightning Netzwerk abzuwickeln. Sie können sich im B2B-Bereich als Infrastruktur-Anbieter etablieren oder auch im Zah- lungsverkehr (Retail-Banking) tätig sein, ähnlich wie eine Neobank die beispielsweise Zahlungen im Euroraum abwickelt.

Doch wie diese Arbeit ausführlich aufgezeigt hat, beﬁndet sich die Entwicklung von LSP noch in einer frühen Phase. Der näher beschriebene Prototyp hat diverse Konﬁgu- rationen und Möglichkeiten implementiert, um einen aktuellen Stand der Entwicklung praxisnah abzubilden. Jedoch ist nach ausführlicher Analyse zu erwarten, dass wegen der hohen Komplexität der Materie eine gefestigte Infrastruktur vor allem von profes- sionellen Anbietern ausgebaut werden wird. Nicht zuletzt spielen hier die technische Expertise als auch eine Mindestanforderung an verfügbarem Kapital eine Rolle. Profes- sionelle LSP repräsentieren letztendlich das Gegenstück zu Neobanken im traditionellen Finanzwesen. Bisher liegt der Fokus der Branche noch auf dem Ausbau des Netzwerks und der Etablierung von bewährten Branchenpraktiken. In dieser Arbeit wurden dies- bezüglich mehrere Vorgehensweisen für den Einstieg in den Nodebetrieb demonstriert. Inwiefern die Wirtschaftlichkeit von LSP zu bewerten ist, lässt sich an den Prognosen der Experteninterviews ablesen. Aktuell besteht die Monetarisierung aus der Erhebung

von Transaktionsgebühren für Nutzer von Lightning Wallets oder der Weiterleitung von Zahlungen zwischen mehreren Parteien. Im Falle eines weiteren rasanten Wachstums des Kryptotransaktionssystems wird dies zukünftig zu mehr betriebswirtschaftlichen Chan- cen führen.

Ungeachtet dessen ist zu berücksichtigen, dass Neobanken eine weitaus breitere Pa- lette an Dienstleistungen als lediglich den reinen Zahlungsverkehr bieten. Inwiefern LSP neben der Transaktionsausführung noch weitere Dienstleistungen ausbilden werden, ist zum aktuellen Zeitpunkt lediglich spekulativer Natur.

Gemeinsam ist Ihnen, dass sowohl Neobanken als auch LSP sich in den aufgezeig- ten Trend zu mehr Demokratisierung im Finanzwesen, genauer zu mehr Demokrati- sierung im Zahlungsverkehr, einfügen. Dieser Trend lässt sich hauptsächlich durch die Miniaturisierung der Informations- und Kommunikationstechnologie begründen. Den- noch unterscheiden sie sich in ihrer Herangehensweise dieses Ziel zu erreichen. Während Neobanken im regulatorischen Umfeld mit Fiat-Währungen agieren, üben LSP ihre Ge- schäftstätigkeit in einem bis dato unregulierten Umfeld mit der Bitcoin-Währung aus. Während Neobanken durch Kapitalgeber wie Großbanken in einem vordeﬁnierten Rah- men entstehen, sind LSP das Ergebnis eines organischen Wachstums einer neuartigen Technologie. Inwiefern den zentralen und dezentralen Banking-as-a-Service-Anbietern ihr Demokratisierungsanspruch zukünftig weiter gelingt, hängt nicht nur von der tech- nologischen Entwicklung, sondern auch von den gesellschaftspolitischen Rahmenbedin- gungen ab. Lightning Service Provider haben das Potential zu einer echten Alternative zu Banken außerhalb des Spektrums bestehender Finanzstrukturen zu werden.

6.3. Weitere Forschungsarbeiten

Ziel dieser Arbeit war eine geeignete Bestandsaufnahme zu erstellen und das Modell von Lightning Service Providern zu untersuchen. Mithilfe des Prototypen ist es gelungen, die softwareseitigen Details des Zahlungssystems intensiv zu beleuchten und vorteilhafte Vorgehensweisen für den reibungslosen Betrieb abzuleiten.

Ferner wurden erste Ansätze präsentiert, wie die technische Umsetzung von ska- lierbaren Nutzerkonten aktuell erfolgt. Allerdings ist die Forschungsliteratur zu diesem Thema ebenso wie verfügbare Online-Quellen nicht besonders ausgereift. Zwar helfen die derzeit präsenten Softwarelösungen (Lightning Wallets) zahlreichen Nutzern, aber diese sind nicht gut dokumentiert und wissenschaftlich evaluiert worden. Die verschiedenen Möglichkeiten zur reibungslosen Integration von Nutzern eignen sich daher als geson- derter zukünftiger Forschungsschwerpunkt. Im Detail können hier die unterschiedlichen Branchen herausgearbeitet werden, in welcher LSP tätig sind und wie diese im Spezi- ellen den Integrationsprozess ihrer Nutzer gestalten. Von Interesse ist zunehmend auch die regulatorische Sicherheit und wie sich der Rechtsrahmen auf das Geschäftsmodell von LSP auswirken wird.

Ein weiteres Thema ist der Verbraucherschutz innerhalb des Kryptotransaktionssys- tems. Da die Demokratisierung des Zahlungsverkehrs dem Nutzer mehr Freiheiten und Möglichkeiten einräumt, ist auch die zukünftige Monetarisierung der Daten von Bedeu- tung. Hierzu zählen z.B. die verbraucherorientierte Buchhaltung der Zahlungsdaten und wie diese auf freiwilliger Basis für den persönlichen Vorteil monetisiert werden können.

Anhang A

LND-Konﬁgurationsdatei

Datei lnd.conf, abgerufen aus dem oﬃziellen Repository ¹ [111]

; Example configuration for lnd.

;

; The default location for this file is in ~/.lnd/lnd.conf on POSIX OSes,

; $LOCALAPPDATA/Lnd/lnd.conf on Windows,

; ~/Library/Application Support/Lnd/lnd.conf on Mac OS and $home/lnd/lnd.conf on

; Plan9.

; The default location of this file can be overwritten by specifying the

; --configfile= flag when starting lnd.

;

; Boolean values can be specified as true/false or 1/0.

[Application Options]

; The directory that lnd stores all wallet, chain, and channel related data

; within The default is ~/.lnd/data on POSIX OSes, $LOCALAPPDATA/Lnd/data on

; Windows, ~/Library/Application Support/Lnd/data on Mac OS, and $home/lnd/data

; on Plan9. Environment variables are expanded so they may be used. NOTE:

; Windows environment variables are typically %VARIABLE%, but they must be

; accessed with $VARIABLE here. Also, ~ is expanded to $LOCALAPPDATA on Windows.

; datadir=~/.lnd/data

; The directory that logs are stored in. The logs are auto-rotated by default.

; Rotated logs are compressed in place.

; logdir=~/.lnd/logs

; Number of logfiles that the log rotation should keep. Setting it to 0 disables deletion of old log files.

; maxlogfiles=3

;

; Max log file size in MB before it is rotated.

; maxlogfilesize=10

; Time after which an RPCAcceptor will time out and return false if

; it hasn't yet received a response.

; acceptortimeout=15s

¹Stand: 20.01.2022

; Path to TLS certificate for lnd's RPC and REST services.

; tlscertpath=~/.lnd/tls.cert

; Path to TLS private key for lnd's RPC and REST services.

; tlskeypath=~/.lnd/tls.key

; Adds an extra ip to the generated certificate. Setting multiple tlsextraip= entries is allowed.

; (old tls files must be deleted if changed)

; tlsextraip=

; Adds an extra domain to the generate certificate. Setting multiple tlsextradomain= entries is allowed.

; (old tls files must be deleted if changed)

; tlsextradomain=

; If set, then all certs will automatically be refreshed if they're close to

; expiring, or if any parameters related to extra IPs or domains in the cert

; change.

; tlsautorefresh=true

; The duration from generating the self signed certificate to the certificate

; expiry date. Valid time units are {s, m, h}.

; The below value is about 14 months (14 * 30 * 24 = 10080)

; tlscertduration=10080h

; Do not include the interface IPs or the system hostname in TLS certificate,

; use first --tlsextradomain as Common Name instead, if set.

; tlsdisableautofill=true

; A list of domains for lnd to periodically resolve, and advertise the resolved

; IPs for the backing node. This is useful for users that only have a dynamic IP,

; or want to expose the node at a domain.

; externalhosts=my-node-domain.com

; Sets the directory to store Let's Encrypt certificates within

; letsencryptdir=~/.lnd/letsencrypt

; The IP:port on which lnd will listen for Let's Encrypt challenges. Let's

; Encrypt will always try to contact on port 80. Often non-root processes are

; not allowed to bind to ports lower than 1024. This configuration option allows

; a different port to be used, but must be used in combination with port

; forwarding from port 80. This configuration can also be used to specify

; another IP address to listen on, for example an IPv6 address.

; letsencryptlisten=localhost:8080

; Request a Let's Encrypt certificate for this domain. Note that the certicate

; is only requested and stored when the first rpc connection comes in.

; letsencryptdomain=example.com

; Disable macaroon authentication. Macaroons are used are bearer credentials to

; authenticate all RPC access. If one wishes to opt out of macaroons, uncomment

; the line below.

; no-macaroons=true

; Enable free list syncing for the default bbolt database. This will decrease

; start up time, but can result in performance degradation for very large

; databases, and also result in higher memory usage. If "free list corruption"

; is detected, then this flag may resolve things.

; sync-freelist=true

; Path to write the admin macaroon for lnd's RPC and REST services if it

; doesn't exist. This can be set if one wishes to store the admin macaroon in a

; distinct location. By default, it is stored within lnd's network directory.

; Applications that are able to read this file, gain admin macaroon access.

; adminmacaroonpath=~/.lnd/data/chain/bitcoin/simnet/admin.macaroon

; Path to write the read-only macaroon for lnd's RPC and REST services if it

; doesn't exist. This can be set if one wishes to store the read-only macaroon

; in a distinct location. The read only macaroon allows users which can read

; the file to access RPCs which don't modify the state of the daemon. By

; default, it is stored within lnd's network directory.

; readonlymacaroonpath=~/.lnd/data/chain/bitcoin/simnet/readonly.macaroon

; Path to write the invoice macaroon for lnd's RPC and REST services if it

; doesn't exist. This can be set if one wishes to store the invoice macaroon in

; a distinct location. By default, it is stored within lnd's network directory.

; The invoice macaroon allows users which can read the file to gain read and

; write access to all invoice related RPCs.

; invoicemacaroonpath=~/.lnd/data/chain/bitcoin/simnet/invoice.macaroon

; The strategy to use for selecting coins for wallet transactions. Options are

; 'largest' and 'random'.

; coin-selection-strategy=largest

; A period to wait before for closing channels with outgoing htlcs that have

; timed out and are a result of this nodes instead payment. In addition to our

; current block based deadline, if specified this grace period will also be taken

; into account. Valid time units are {s, m, h}.

; payments-expiration-grace-period=30s

; Specify the interfaces to listen on for p2p connections. One listen

; address per line.

; All ipv4 on port 9735:

; listen=0.0.0.0:9735

; On all ipv4 interfaces on port 9735 and ipv6 localhost port 9736:

; listen=0.0.0.0:9735

; listen=[::1]:9736

; Disable listening for incoming p2p connections. This will override all

; listeners.

; nolisten=true

; Specify the interfaces to listen on for gRPC connections. One listen

; address per line.

; Only ipv4 localhost on port 10009:

; rpclisten=localhost:10009

; On ipv4 localhost port 10009 and ipv6 port 10010:

; rpclisten=localhost:10009

; rpclisten=[::1]:10010

; On an Unix socket:

; rpclisten=unix:///var/run/lnd/lnd-rpclistener.sock

; Specify the interfaces to listen on for REST connections. One listen

; address per line.

; All ipv4 interfaces on port 8080:

; restlisten=0.0.0.0:8080

; On ipv4 localhost port 80 and 443:

; restlisten=localhost:80

; restlisten=localhost:443

; On an Unix socket:

; restlisten=unix:///var/run/lnd-restlistener.sock

; A series of domains to allow cross origin access from. This controls the CORs

; policy of the REST RPC proxy.

; restcors=https://my-special-site.com

; Adding an external IP will advertise your node to the network. This signals

; that your node is available to accept incoming channels. If you don't wish to

; advertise your node, this value doesn't need to be set. Unless specified

; (with host:port notation), the default port (9735) will be added to the

; address.

; externalip=

;

; Instead of explicitly stating your external IP address, you can also enable

; UPnP or NAT-PMP support on the daemon. Both techniques will be tried and

; require proper hardware support. In order to detect this hardware support,

; `lnd` uses a dependency that retrieves the router's gateway address by using

; different built-in binaries in each platform. Therefore, it is possible that

; we are unable to detect the hardware and `lnd` will exit with an error

; indicating this. This option will automatically retrieve your external IP

; address, even after it has changed in the case of dynamic IPs, and advertise

; it to the network using the ports the daemon is listening on. This does not

; support devices behind multiple NATs.

; nat=true

; Disable REST API.

; norest=true

; Disable TLS for the REST API.

; no-rest-tls=true

; The ping interval for REST based WebSocket connections, set to 0 to disable

; sending ping messages from the server side. Valid time units are {s, m, h}.

; ws-ping-interval=30s

; The time we wait for a pong response message on REST based WebSocket

; connections before the connection is closed as inactive. Valid time units are

; {s, m, h}.

; ws-pong-wait=5s

; Shortest backoff when reconnecting to persistent peers. Valid time units are

; {s, m, h}.

; minbackoff=1s

; Longest backoff when reconnecting to persistent peers. Valid time units are

; {s, m, h}.

; maxbackoff=1h

; The timeout value for network connections in seconds, default to 120 seconds.

; Valid uints are {ms, s, m, h}.

; connectiontimeout=120s

; Debug logging level.

; Valid levels are {trace, debug, info, warn, error, critical}

; You may also specify <global-level>,<subsystem>=<level>,<subsystem2>=<level>,...

; to set log level for individual subsystems. Use lncli debuglevel --show to

; list available subsystems.

; debuglevel=debug,PEER=info

; Write CPU profile to the specified file.

; cpuprofile=

; Enable HTTP profiling on given port -- NOTE port must be between 1024 and

; 65536. The profile can be access at: http://localhost:<PORT>/debug/pprof/.

; profile=

; DEPRECATED: Allows the rpcserver to intentionally disconnect from peers with

; open channels. THIS FLAG WILL BE REMOVED IN 0.10.0.

; unsafe-disconnect=false

; Causes a link to replay the adds on its commitment txn after starting up, this

; enables testing of the sphinx replay logic.

; unsafe-replay=true

; The maximum number of incoming pending channels permitted per peer.

; maxpendingchannels=1

; The target location of the channel backup file.

; backupfilepath=~/.lnd/data/chain/bitcoin/simnet/channel.backup

; The maximum capacity of the block cache in bytes. Increasing this will result

; in more blocks being kept in memory but will increase performance when the

; same block is required multiple times.

; The example value below is 40 MB (1024 * 1024 * 40)

; blockcachesize=41943040

; Optional URL for external fee estimation. If no URL is specified, the method

; for fee estimation will depend on the chosen backend and network. Must be set

; for neutrino on mainnet.

; feeurl=https://nodes.lightning.computer/fees/v1/btc-fee-estimates.json

; If true, then automatic network bootstrapping will not be attempted. This

; means that your node won't attempt to automatically seek out peers on the

; network.

; nobootstrap=true

; If true, NO SEED WILL BE EXPOSED -- EVER, AND THE WALLET WILL BE ENCRYPTED

; USING THE DEFAULT PASSPHRASE. THIS FLAG IS ONLY FOR TESTING AND SHOULD NEVER

; BE USED ON MAINNET.

; noseedbackup=true

; The full path to a file (or pipe/device) that contains the password for

; unlocking the wallet; if set, no unlocking through RPC is possible and lnd

; will exit if no wallet exists or the password is incorrect; if

; wallet-unlock-allow-create is also set then lnd will ignore this flag if no

; wallet exists and allow a wallet to be created through RPC.

; wallet-unlock-password-file=/tmp/example.password

; Don't fail with an error if wallet-unlock-password-file is set but no wallet

; exists yet. Not recommended for auto-provisioned or high-security systems

; because the wallet creation RPC is unauthenticated and an attacker could

; inject a seed while lnd is in that state.

; wallet-unlock-allow-create=true

; Removes all transaction history from the on-chain wallet on startup, forcing a

; full chain rescan starting at the wallet's birthday. Implements the same

; functionality as btcwallet's dropwtxmgr command. Should be set to false after

; successful execution to avoid rescanning on every restart of lnd.

; reset-wallet-transactions=true

; The smallest channel size (in satoshis) that we should accept. Incoming

; channels smaller than this will be rejected, default value 20000.

; minchansize=

; The largest channel size (in satoshis) that we should accept. Incoming

; channels larger than this will be rejected. For non-Wumbo channels this

; limit remains 16777215 satoshis by default as specified in BOLT-0002.

; For wumbo channels this limit is 1,000,000,000 satoshis (10 BTC).

; Set this config option explicitly to restrict your maximum channel size

; to better align with your risk tolerance

; maxchansize=

; The target number of blocks in which a cooperative close initiated by a remote

; peer should be confirmed. This target is used to estimate the starting fee

; rate that will be used during fee negotiation with the peer. This target is

; is also used for cooperative closes initiated locally if the --conf_target

; for the channel closure is not set.

; coop-close-target-confs=10

; The maximum time that is allowed to pass between receiving a channel state

; update and signing the next commitment. Setting this to a longer duration

; allows for more efficient channel operations at the cost of latency.

; channel-commit-interval=50ms

; The maximum number of channel state updates that is accumulated before signing

; a new commitment.

; channel-commit-batch-size=10

; The default max_htlc applied when opening or accepting channels. This value

; limits the number of concurrent HTLCs that the remote party can add to the

; commitment. The maximum possible value is 483.

; default-remote-max-htlcs=483

; The duration that a peer connection must be stable before attempting to send a

; channel update to reenable or cancel a pending disables of the peer's channels

; on the network. (default: 19m0s)

; chan-enable-timeout=22m

; The duration that must elapse after first detecting that an already active

; channel is actually inactive and sending channel update disabling it to the

; network. The pending disable can be canceled if the peer reconnects and becomes

; stable for chan-enable-timeout before the disable update is sent.

; (default: 20m0s)

; chan-disable-timeout=22m

; The polling interval between attempts to detect if an active channel has become

; inactive due to its peer going offline. (default: 1m0s)

; chan-status-sample-interval=2m

; Disable queries from the height-hint cache to try to recover channels stuck in

; the pending close state. Disabling height hint queries may cause longer chain

; rescans, resulting in a performance hit. Unset this after channels are unstuck

; so you can get better performance again.

; height-hint-cache-query-disable=true

; The polling interval between historical graph sync attempts. Each historical

; graph sync attempt ensures we reconcile with the remote peer's graph from the

; genesis block. (default: 1h0m0s)

; historicalsyncinterval=2h

; If true, will not reply with historical data that matches the range specified

; by a remote peer's gossip_timestamp_filter. Doing so will result in lower

; memory and bandwidth requirements.

; ignore-historical-gossip-filters=true

; If true, lnd will not accept channel opening requests with non-zero push

; amounts. This should prevent accidental pushes to merchant nodes.

; rejectpush=true

; If true, lnd will not forward any HTLCs that are meant as onward payments. This

; option will still allow lnd to send HTLCs and receive HTLCs but lnd won't be

; used as a hop.

; rejecthtlc=true

; If true, will apply a randomized staggering between 0s and 30s when

; reconnecting to persistent peers on startup. The first 10 reconnections will be

; attempted instantly, regardless of the flag's value

; stagger-initial-reconnect=true

; The maximum number of blocks funds could be locked up for when forwarding

; payments. (default: 2016)

; max-cltv-expiry=2016

; The maximum percentage of total funds that can be allocated to a channel's

; commitment fee. This only applies for the initiator of the channel. Valid

; values are within [0.1, 1]. (default: 0.5)

; max-channel-fee-allocation=0.9

; The maximum fee rate in sat/vbyte that will be used for commitments of

; channels of the anchors type. Must be large enough to ensure transaction

; propagation (default: 10)

; max-commit-fee-rate-anchors=5

; A threshold defining the maximum amount of dust a given channel can have

; after which forwarding and sending dust HTLC's to and from the channel will

; fail. This amount is expressed in satoshis. (default: 500000)

; dust-threshold=1000000

; If true, lnd will abort committing a migration if it would otherwise have been

; successful. This leaves the database unmodified, and still compatible with the

; previously active version of lnd.

; dry-run-migration=true

; If true, option upfront shutdown script will be enabled. If peers that we open

; channels with support this feature, we will automatically set the script to

; which cooperative closes should be paid out to on channel open. This offers the

; partial protection of a channel peer disconnecting from us if cooperative

; close is attempted with a different script.

; enable-upfront-shutdown=true

; If true, spontaneous payments through keysend will be accepted.

; This is a temporary solution until AMP is implemented which is expected to be soon

; This option will then become deprecated in favor of AMP.

; accept-keysend=true

; If non-zero, keysend payments are accepted but not immediately settled. If the

; payment isn't settled manually after the specified time, it is canceled

; automatically. [experimental]

; keysend-hold-time=true

; If true, spontaneous payments through AMP will be accepted. Payments to AMP

; invoices will be accepted regardless of this setting.

; accept-amp=true

; If true, we'll attempt to garbage collect canceled invoices upon start.

; gc-canceled-invoices-on-startup=true

; If true, we'll delete newly canceled invoices on the fly.

; gc-canceled-invoices-on-the-fly=true

; If true, our node will allow htlc forwards that arrive and depart on the same

; channel.

; allow-circular-route=true

; Time in milliseconds between each release of announcements to the network

; trickledelay=180000

; The number of peers that we should receive new graph updates from. This option

; can be tuned to save bandwidth for light clients or routing nodes. (default: 3)

; numgraphsyncpeers=9

; If true, lnd will start the Prometheus exporter. Prometheus flags are

; behind a build/compile flag and are not available by default. lnd must be built

; with the monitoring tag; `make && make install tags=monitoring` to activate them.

; prometheus.enable=true

; Specify the interface to listen on for Prometheus connections.

; prometheus.listen=0.0.0.0:8989

; The alias your node will use, which can be up to 32 UTF-8 characters in

; length.

; alias=My Lightning

; The color of the node in hex format, used to customize node appearance in

; intelligence services.

; color=#3399FF

[Bitcoin]

; If the Bitcoin chain should be active. Atm, only a single chain can be

; active. bitcoin.active=true

; The directory to store the chain's data within.

; bitcoin.chaindir=~/.lnd/data/chain/bitcoin

; Use Bitcoin's main network.

; bitcoin.mainnet=true

; Use Bitcoin's test network.

; bitcoin.testnet=true

;

; Use Bitcoin's simulation test network bitcoin.simnet=true

; Use Bitcoin's regression test network

; bitcoin.regtest=false

; Use Bitcoin's signet test network

; bitcoin.signet=false

; Connect to a custom signet network defined by this challenge instead of using

; the global default signet test network -- Can be specified multiple times

; bitcoin.signetchallenge=

; Specify a seed node for the signet network instead of using the global default

; signet network seed nodes

; bitcoin.signetseednode=123.45.67.89

; Use the btcd back-end bitcoin.node=btcd

; Use the bitcoind back-end

; bitcoin.node=bitcoind

; Use the neutrino (light client) back-end

; bitcoin.node=neutrino

; The default number of confirmations a channel must have before it's considered

; open. We'll require any incoming channel requests to wait this many

; confirmations before we consider the channel active.

; bitcoin.defaultchanconfs=3

; The default number of blocks we will require our channel counterparty to wait

; before accessing its funds in case of unilateral close. If this is not set, we

; will scale the value according to the channel size.

; bitcoin.defaultremotedelay=144

; The maximum number of blocks we will limit the wait that our own funds are

; encumbered by in the case when our node unilaterally closes. If a remote peer

; proposes a channel with a delay above this amount, lnd will reject the

; channel.

; bitcoin.maxlocaldelay=2016

; The smallest HTLC we are willing to accept on our channels, in millisatoshi.

; bitcoin.minhtlc=1

; The smallest HTLC we are willing to send out on our channels, in millisatoshi.

; bitcoin.minhtlcout=1000

; The base fee in millisatoshi we will charge for forwarding payments on our

; channels.

; bitcoin.basefee=1000

; The fee rate used when forwarding payments on our channels. The total fee

; charged is basefee + (amount * feerate / 1000000), where amount is the

; forwarded amount.

; bitcoin.feerate=1

; The CLTV delta we will subtract from a forwarded HTLC's timelock value.

; bitcoin.timelockdelta=40

; The seed DNS server(s) to use for initial peer discovery. Must be specified as

; a '<primary_dns>[,<soa_primary_dns>]' tuple where the SOA address is needed

; for DNS resolution through Tor but is optional for clearnet users. Multiple

; tuples can be specified, will overwrite the default seed servers.

; The default seed servers are:

; mainnet:

; bitcoin.dnsseed=nodes.lightning.directory,soa.nodes.lightning.directory

; bitcoin.dnsseed=lseed.bitcoinstats.com

; testnet:

; bitcoin.dnsseed=test.nodes.lightning.directory,soa.nodes.lightning.directory

;

; Example for custom DNS servers:

; bitcoin.dnsseed=seed1.test.lightning

; bitcoin.dnsseed=seed2.test.lightning,soa.seed2.test.lightning

[Btcd]

; The base directory that contains the node's data, logs, configuration file,

; etc.

; btcd.dir=~/.btcd

; The host that your local btcd daemon is listening on. By default, this

; setting is assumed to be localhost with the default port for the current

; network.

; btcd.rpchost=localhost

; Username for RPC connections to btcd. By default, lnd will attempt to

; automatically obtain the credentials, so this likely won't need to be set

; (other than for simnet mode).

; btcd.rpcuser=kek

; Password for RPC connections to btcd. By default, lnd will attempt to

; automatically obtain the credentials, so this likely won't need to be set

; (other than for simnet mode).

; btcd.rpcpass=kek

; File containing the daemon's certificate file. This only needs to be set if

; the node isn't on the same host as lnd.

; btcd.rpccert=~/.btcd/rpc.cert

; The raw bytes of the daemon's PEM-encoded certificate chain which will be used

; to authenticate the RPC connection. This only needs to be set if the btcd

; node is on a remote host.

; btcd.rawrpccert=

[Bitcoind]

; The base directory that contains the node's data, logs, configuration file,

; etc.

; bitcoind.dir=~/.bitcoin

; The host that your local bitcoind daemon is listening on. By default, this

; setting is assumed to be localhost with the default port for the current

; network.

; bitcoind.rpchost=localhost

; Username for RPC connections to bitcoind. By default, lnd will attempt to

; automatically obtain the credentials, so this likely won't need to be set

; (other than for a remote bitcoind instance).

; bitcoind.rpcuser=kek

; Password for RPC connections to bitcoind. By default, lnd will attempt to

; automatically obtain the credentials, so this likely won't need to be set

; (other than for a remote bitcoind instance).

; bitcoind.rpcpass=kek

; ZMQ socket which sends rawblock and rawtx notifications from bitcoind. By

; default, lnd will attempt to automatically obtain this information, so this

; likely won't need to be set (other than for a remote bitcoind instance).

; bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332

; bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333

; Fee estimate mode for bitcoind. It must be either "ECONOMICAL" or "CONSERVATIVE".

; If unset, the default value is "CONSERVATIVE".

; bitcoind.estimatemode=CONSERVATIVE

; The maximum number of peers lnd will choose from the backend node to retrieve

; pruned blocks from. This only applies to pruned nodes.

; bitcoind.pruned-node-max-peers=4

[neutrino]

; Connect only to the specified peers at startup. This creates a persistent

; connection to a target peer. This is recommended as there aren't many

; neutrino compliant full nodes on the test network yet.

; neutrino.connect=

; Max number of inbound and outbound peers.

;

; NOTE: This value is currently unused.

; neutrino.maxpeers=

; Add a peer to connect with at startup.

; neutrino.addpeer=

; How long to ban misbehaving peers. Valid time units are {s, m, h}. Minimum 1

; second.

;

; NOTE: This value is currently unused.

; neutrino.banduration=

; Maximum allowed ban score before disconnecting and banning misbehaving peers.

;

; NOTE: This value is currently unused.

; neutrino.banthreshold=

; DEPRECATED: Use top level 'feeurl' option. Optional URL for fee estimation. If

; a URL is not specified, static fees will be used for estimation.

; neutrino.feeurl=

; Optional filter header in height:hash format to assert the state of neutrino's

; filter header chain on startup. If the assertion does not hold, then the

; filter header chain will be re-synced from the genesis block.

; neutrino.assertfilterheader=

; Used to help identify ourselves to other bitcoin peers (default: neutrino).

; neutrino.useragentname=neutrino

; Used to help identify ourselves to other bitcoin peers (default: 0.11.0-beta).

; neutrino.useragentversion=0.11.0-beta

; The amount of time to wait before giving up on a transaction broadcast attempt.

; neutrino.broadcasttimeout=5s

; Whether compact filters fetched from the P2P network should be persisted to disk.

; neutrino.persistfilters=true

; Validate every channel in the graph during sync by downloading the containing

; block. This is the inverse of routing.assumechanvalid, meaning that for

; Neutrino the validation is turned off by default for massively increased graph

; sync performance. This speedup comes at the risk of using an unvalidated view

; of the network for routing. Overwrites the value of routing.assumechanvalid if

; Neutrino is used. (default: false)

; neutrino.validatechannels=false

[Litecoin]

; If the Litecoin chain should be active. Atm, only a single chain can be

; active.

; litecoin.active=true

; The directory to store the chain's data within.

; litecoin.chaindir=~/.lnd/data/chain/litecoin

; Use Litecoin's main network.

; litecoin.mainnet=true

; Use Litecoin's test network.

; litecoin.testnet=true

;

; Use Litecoin's simulation test network

; litecoin.simnet=true

; Use Litecoin's regression test network

; litecoin.regtest=false

; Litecoin does not support the signet test network. The options

; litecoin.signet, litecoin.signetchallenge and litecoin.signetseednode are

; only defined because the data structure is shared with bitcoind.

; Use the ltcd back-end. litecoin.node=ltcd

; Use the litecoind back-end.

; litecoin.node=litecoind

; The default number of confirmations a channel must have before it's considered

; open. We'll require any incoming channel requests to wait this many

; confirmations before we consider the channel active.

; litecoin.defaultchanconfs=3

; The default number of blocks we will require our channel counterparty to wait

; before accessing its funds in case of unilateral close. If this is not set, we

; will scale the value according to the channel size.

; litecoin.defaultremotedelay=144

; The maximum number of blocks we will limit the wait that our own funds are

; encumbered by in the case when our node unilaterally closes. If a remote peer

; proposes a channel with a delay above this amount, lnd will reject the

; channel.

; litecoin.maxlocaldelay=2016

; The smallest HTLC we are willing to accept on our channels, in millisatoshi.

; litecoin.minhtlc=1

; The smallest HTLC we are willing to send out on our channels, in millisatoshi.

; litecoin.minhtlcout=1000

; The base fee in millisatoshi we will charge for forwarding payments on our

; channels.

; litecoin.basefee=1000

; The fee rate used when forwarding payments on our channels. The total fee

; charged is basefee + (amount * feerate / 1000000), where amount is the

; forwarded amount.

; litecoin.feerate=1

; The CLTV delta we will subtract from a forwarded HTLC's timelock value.

; litecoin.timelockdelta=576

; The seed DNS server(s) to use for initial peer discovery. Must be specified as

; a '<primary_dns>[,<soa_primary_dns>]' tuple where the SOA address is needed

; for DNS resolution through Tor but is optional for clearnet users. Multiple

; tuples can be specified, will overwrite the default seed servers.

; The default seed servers are:

; mainnet:

; litecoin.dnsseed=ltc.nodes.lightning.directory,soa.nodes.lightning.directory

;

; Example for custom DNS servers:

; litecoin.dnsseed=seed1.test-ltc.lightning

; litecoin.dnsseed=seed2.test-ltc.lightning,soa.seed2.test-ltc.lightning

[Ltcd]

; The base directory that contains the node's data, logs, configuration file,

; etc.

; ltcd.dir=~/.ltcd

; The host that your local ltcd daemon is listening on. By default, this

; setting is assumed to be localhost with the default port for the current

; network.

; ltcd.rpchost=localhost

; Username for RPC connections to ltcd. By default, lnd will attempt to

; automatically obtain the credentials, so this likely won't need to be set

; (other than for simnet mode).

; ltcd.rpcuser=kek

; Password for RPC connections to ltcd. By default, lnd will attempt to

; automatically obtain the credentials, so this likely won't need to be set

; (other than for simnet mode).

; ltcd.rpcpass=kek

; File containing the daemon's certificate file. This only needs to be set if

; the node isn't on the same host as lnd.

; ltcd.rpccert=~/.ltcd/rpc.cert

; The raw bytes of the daemon's PEM-encoded certificate chain which will be used

; to authenticate the RPC connection. This only needs to be set if the ltcd

; node is on a remote host.

; ltcd.rawrpccert=

[Litecoind]

; The base directory that contains the node's data, logs, configuration file,

; etc.

; litecoind.dir=~/.litecoin

; The host that your local litecoind daemon is listening on. By default, this

; setting is assumed to be localhost with the default port for the current

; network.

; litecoind.rpchost=localhost

; Username for RPC connections to litecoind. By default, lnd will attempt to

; automatically obtain the credentials, so this likely won't need to be set

; (other than for a remote litecoind instance).

; litecoind.rpcuser=kek

; Password for RPC connections to litecoind. By default, lnd will attempt to

; automatically obtain the credentials, so this likely won't need to be set

; (other than for a remote litecoind instance).

; litecoind.rpcpass=kek

; ZMQ socket which sends rawblock and rawtx notifications from litecoind. By

; default, lnd will attempt to automatically obtain this information, so this

; likely won't need to be set (other than for a remote litecoind instance).

; litecoind.zmqpubrawblock=tcp://127.0.0.1:28332

; litecoind.zmqpubrawtx=tcp://127.0.0.1:28333

; Fee estimate mode for litecoind. It must be either "ECONOMICAL" or "CONSERVATIVE".

; If unset, the default value is "CONSERVATIVE".

; litecoind.estimatemode=CONSERVATIVE

; The maximum number of peers lnd will choose from the backend node to retrieve

; pruned blocks from. This only applies to pruned nodes.

; litecoind.pruned-node-max-peers=4

[autopilot]

; If the autopilot agent should be active or not. The autopilot agent will

; attempt to automatically open up channels to put your node in an advantageous

; position within the network graph.

; autopilot.active=true

; The maximum number of channels that should be created.

; autopilot.maxchannels=5

; The fraction of total funds that should be committed to automatic channel

; establishment. For example 0.6 means that 60% of the total funds available

; within the wallet should be used to automatically establish channels. The total

; amount of attempted channels will still respect the maxchannels param.

; autopilot.allocation=0.6

; Heuristic to activate, and the weight to give it during scoring. (default:

; top_centrality:1)

; autopilot.heuristic=preferential:1

; The smallest channel that the autopilot agent should create (default: 20000)

; autopilot.minchansize=20000

; The largest channel that the autopilot agent should create (default: 16777215)

; autopilot.maxchansize=20000

; Whether the channels created by the autopilot agent should be private or not.

; Private channels won't be announced to the network.

; autopilot.private=true

; The minimum number of confirmations each of your inputs in funding transactions

; created by the autopilot agent must have. (default: 1)

; autopilot.minconfs=2

; The confirmation target (in blocks) for channels opened by autopilot. (default:

; 3)

; autopilot.conftarget=2

[tor]

; Allow outbound and inbound connections to be routed through Tor

; tor.active=true

; 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

; The port that Tor's exposed SOCKS5 proxy is listening on. Using Tor allows

; outbound-only connections (listening will be disabled) -- NOTE port must be

; between 1024 and 65535

; tor.socks=9050

; The DNS server as IP:PORT that Tor will use for SRV queries - NOTE must have

; TCP resolution enabled. The current active DNS server for Testnet listening is

; nodes.lightning.directory

; tor.dns=nodes.lightning.directory

; Enable Tor stream isolation by randomizing user credentials for each

; connection. With this mode active, each connection will use a new circuit.

; This means that multiple applications (other than lnd) using Tor won't be mixed

; in with lnd's traffic.

;

; This option may not be used while direct connections are enabled, since direct

; connections compromise source IP privacy by default.

; tor.streamisolation=true

; The host:port that Tor is listening on for Tor control connections (default:

; localhost:9051)

; tor.control=localhost:9091

; IP address that Tor should use as the target of the hidden service

; tor.targetipaddress=

; The password used to arrive at the HashedControlPassword for the control port.

; If provided, the HASHEDPASSWORD authentication method will be used instead of

; the SAFECOOKIE one.

; tor.password=plsdonthackme

; Automatically set up a v2 onion service to listen for inbound connections

; tor.v2=true

; Automatically set up a v3 onion service to listen for inbound connections

; tor.v3=true

; The path to the private key of the onion service being created

; tor.privatekeypath=/path/to/torkey

;The path to the private key of the watchtower onion service being created

; tor.watchtowerkeypath=/other/path/

[watchtower]

; Enable integrated watchtower listening on :9911 by default.

; watchtower.active=true

; Specify the interfaces to listen on for watchtower client connections. One

; listen address per line. If no port is specified the default port of 9911 will

; be added implicitly.

; All ipv4 on port 9911:

; watchtower.listen=0.0.0.0:9911

; On all ipv4 interfaces on port 9911 and ipv6 localhost port 9912:

; watchtower.listen=0.0.0.0:9911

; watchtower.listen=[::1]:9912

; Configure the external IP address of your watchtower. Setting this field does

; not have any behavioral changes to the tower or enable any sort of discovery,

; however it will make the full URI (pubkey@host:port) available via

; WatchtowerRPC.GetInfo and `lncli tower info`.

; watchtower.externalip=1.2.3.4

; Configure the default watchtower data directory. The default directory is

; data/watchtower relative to the chosen lnddir. This can be useful if one needs

; to move the database to a separate volume with more storage. In the example

; below, the database will be stored at:

; /path/to/towerdir/bitcoin/<network>/watchtower.db.

; watchtower.towerdir=/path/to/towerdir

; Duration the watchtower server will wait for messages to be received before

; hanging up on client connections.

; watchtower.readtimeout=15s

; Duration the watchtower server will wait for messages to be written before

; hanging up on client connections

; watchtower.writetimeout=15s

[wtclient]

; Activate Watchtower Client. To get more information or configure watchtowers

; run `lncli wtclient -h`.

; wtclient.active=true

; Specify the fee rate with which justice transactions will be signed. This fee

; rate should be chosen as a maximum fee rate one is willing to pay in order to

; sweep funds if a breach occurs while being offline. The fee rate should be

; specified in sat/byte, the default is 10 sat/byte.

; wtclient.sweep-fee-rate=10

; (Deprecated) Specifies the URIs of private watchtowers to use in backing up

; revoked states. URIs must be of the form <pubkey>@<addr>. Only 1 URI is

; supported at this time, if none are provided the tower will not be enabled.

; wtclient.private-tower-uris=

[healthcheck]

; The number of times we should attempt to query our chain backend before

; gracefully shutting down. Set this value to 0 to disable this health check.

; healthcheck.chainbackend.attempts=3

; The amount of time we allow a call to our chain backend to take before we fail

; the attempt. This value must be >= 1s.

; healthcheck.chainbackend.timeout=10s

; The amount of time we should backoff between failed attempts to query chain

; backend. This value must be >= 1s.

; healthcheck.chainbackend.backoff=30s

; The amount of time we should wait between chain backend health checks. This

; value must be >= 1m.

; healthcheck.chainbackend.interval=1m

; The minimum ratio of free disk space to total capacity that we require.

; healthcheck.diskspace.diskrequired=0.1

; The number of times we should attempt to query our available disk space before

; gracefully shutting down. Set this value to 0 to disable this health check.

; healthcheck.diskspace.attempts=2

; The amount of time we allow a query for our available disk space to take

; before we fail the attempt. This value must be >= 1s.

; healthcheck.diskspace.timeout=5s

; The amount of time we should backoff between failed attempts to query

; available disk space. This value must be >= 1s.

; healthcheck.diskspace.backoff=1m

; The amount of time we should wait between disk space health checks. This

; value must be >= 1m.

; healthcheck.diskspace.interval=6h

; The number of times we should attempt to check for certificate expiration before

; gracefully shutting down. Set this value to 0 to disable this health check.

; healthcheck.tls.attempts=2

; The amount of time we allow a query for certificate expiration to take

; before we fail the attempt. This value must be >= 1s.

; healthcheck.tls.timeout=5s

; The amount of time we should backoff between failed attempts to query

; certificate expiration. This value must be >= 1s.

; healthcheck.tls.backoff=1m

; The amount of time we should wait between certificate expiration health checks.

; This value must be >= 1m.

; healthcheck.tls.interval=1m

; The number of times we should attempt to check our tor connection before

; gracefully shutting down. Set this value to 0 to disable this health check.

; healthcheck.torconnection.attempts=3

; The amount of time we allow a call to our tor connection to take before we

; fail the attempt. This value must be >= 1s.

; healthcheck.torconnection.timeout=10s

; The amount of time we should backoff between failed attempts to check tor

; connection. This value must be >= 1s.

; healthcheck.torconnection.backoff=30s

; The amount of time we should wait between tor connection health checks. This

; value must be >= 1m.

; healthcheck.torconnection.interval=1m

; The number of times we should attempt to check our remote signer RPC

; connection before gracefully shutting down. Set this value to 0 to disable

; this health check.

; healthcheck.remotesigner.attempts=1

; The amount of time we allow a call to our remote signer RPC connection to take

; before we fail the attempt. This value must be >= 1s.

; healthcheck.remotesigner.timeout=1s

; The amount of time we should backoff between failed attempts to check remote

; signer RPC connection. This value must be >= 1s.

; healthcheck.remotesigner.backoff=30s

; The amount of time we should wait between remote signer RPC connection health

; checks. This value must be >= 1m.

; healthcheck.remotesigner.interval=1m

[signrpc]

; Path to the signer macaroon.

; signrpc.signermacaroonpath=~/.lnd/data/chain/bitcoin/simnet/signer.macaroon

[walletrpc]

; Path to the wallet kit macaroon.

; walletrpc.walletkitmacaroonpath=~/.lnd/data/chain/bitcoin/simnet/walletkit. macaroon

[chainrpc]

; Path to the chain notifier macaroon.

; chainrpc.notifiermacaroonpath=~/.lnd/data/chain/bitcoin/simnet/chainnotifier. macaroon

[routerrpc]

; Minimum required route success probability to attempt the payment (default:

; 0.01)

; routerrpc.minrtprob=1

; Assumed success probability of a hop in a route when no other information is

; available. (default: 0.6)

; routerrpc.apriorihopprob=0.2

; Weight of the a priori probability in success probability estimation. Valid

; values are in [0, 1]. (default: 0.5)

; routerrpc.aprioriweight=0.3

; Defines the duration after which a penalized node or channel is back at 50%

; probability (default: 1h0m0s)

; routerrpc.penaltyhalflife=2h

; The (virtual) fixed cost in sats of a failed payment attempt (default: 100)

; routerrpc.attemptcost=90

; The (virtual) proportional cost in ppm of the total amount of a failed payment

; attempt (default: 1000)

; routerrpc.attemptcostppm=900

; The maximum number of payment results that are held on disk by mission control

; (default: 1000)

; routerrpc.maxmchistory=900

; The time interval with which the MC store state is flushed to the DB.

; routerrpc.mcflushinterval=1m

; Path to the router macaroon

; routerrpc.routermacaroonpath=~/.lnd/data/chain/bitcoin/simnet/router.macaroon

[workers]

; Maximum number of concurrent read pool workers. This number should be

; proportional to the number of peers. (default: 100)

; workers.read=200

; Maximum number of concurrent write pool workers. This number should be

; proportional to the number of CPUs on the host. (default: 8)

; workers.write=8

; Maximum number of concurrent sig pool workers. This number should be

; proportional to the number of CPUs on the host. (default: 8)

; workers.sig=4

[caches]

; Maximum number of entries contained in the reject cache, which is used to speed

; up filtering of new channel announcements and channel updates from peers. Each

; entry requires 25 bytes. (default: 50000)

; caches.reject-cache-size=900000

; Maximum number of entries contained in the channel cache, which is used to

; reduce memory allocations from gossip queries from peers. Each entry requires

; roughly 2Kb. (default: 20000)

; caches.channel-cache-size=9000000

; The duration that the response to DescribeGraph should be cached for. Setting

; the value to zero disables the cache. (default: 1m)

; caches.rpc-graph-cache-duration=10m

[protocol]

; If set, then lnd will create and accept requests for channels larger than 0.16

; BTC

; protocol.wumbo-channels=true

; Set to disable support for anchor commitments. If not set, lnd will use anchor

; channels by default if the remote channel party supports them. Note that lnd

; will require 1 UTXO to be reserved for this channel type if it is enabled.

; (Deprecates the previous "protocol.anchors" setting.)

; protocol.no-anchors=true

; Set to disable support for script enforced lease channel commitments. If not

; set, lnd will accept these channels by default if the remote channel party

; proposes them. Note that lnd will require 1 UTXO to be reserved for this

; channel type if it is enabled.

; protocol.no-script-enforced-lease=true

[db]

; The selected database backend. The current default backend is "bolt". lnd

; also has experimental support for etcd, a replicated backend.

; db.backend=bolt

; The maximum interval the graph database will wait between attempting to flush

; a batch of modifications to disk. Defaults to 500 milliseconds.

; db.batch-commit-interval=500ms

; Don't use the in-memory graph cache for path finding. Much slower but uses

; less RAM. Can only be used with a bolt database backend.

; db.no-graph-cache=true

[etcd]

; Etcd database host.

; db.etcd.host=localhost:2379

; Etcd database user.

; db.etcd.user=userscopedforlnd

; Password for the database user.

; db.etcd.pass=longandsekrit

; Etcd namespace to use.

; db.etcd.namespace=lnd

; Whether to disable the use of TLS for etcd.

; db.etcd.disabletls=false

; Path to the TLS certificate for etcd RPC.

; db.etcd.cert_file=/key/path

; Path to the TLS private key for etcd RPC.

; db.etcd.key_file=/a/path

; Whether we intend to skip TLS verification

; db.etcd.insecure_skip_verify=true

; Whether to collect etcd commit stats.

; db.etcd.collect_stats=true

; If set LND will use an embedded etcd instance instead of the external one.

; Useful for testing.

; db.etcd.embedded=false

; If non zero, LND will use this as client port for the embedded etcd instance.

; db.etcd.embedded_client_port=1234

; If non zero, LND will use this as peer port for the embedded etcd instance.

; db.etcd.embedded_peer_port=1235

; If set the embedded etcd instance will log to the specified file. Useful when

; testing with embedded etcd.

; db.etcd.embedded_log_file=/path/etcd.log

; The maximum message size in bytes that we may send to etcd. Defaults to 32 MiB.

; db.etcd.max_msg_size=33554432

[postgres]

; Postgres connection string.

; db.postgres.dsn=postgres://lnd:lnd@localhost:45432/lnd?sslmode=disable

; Postgres connection timeout. Valid time units are {s, m, h}. Set to zero to

; disable.

; db.postgres.timeout=

; Postgres maximum number of connections. Set to zero for unlimited. It is

; recommended to set a limit that is below the server connection limit.

; Otherwise errors may occur in lnd under high-load conditions.

; db.postgres.maxconnections=

[bolt]

; If true, prevents the database from syncing its freelist to disk.

; db.bolt.nofreelistsync=1

; Whether the databases used within lnd should automatically be compacted on

; every startup (and if the database has the configured minimum age). This is

; disabled by default because it requires additional disk space to be available

; during the compaction that is freed afterwards. In general compaction leads to

; smaller database files.

; db.bolt.auto-compact=true

; How long ago the last compaction of a database file must be for it to be

; considered for auto compaction again. Can be set to 0 to compact on every

; startup. (default: 168h)

; db.bolt.auto-compact-min-age=0

; Specify the timeout to be used when opening the database.

; db.bolt.dbtimeout=60s

[cluster]

; Enables leader election if set.

; cluster.enable-leader-election=true

; Leader elector to use. Valid values: "etcd" (default).

; cluster.leader-elector=etcd

; Election key prefix when using etcd leader elector. Defaults to "/leader/".

; cluster.etcd-election-prefix=/leader/

; Identifier for this node inside the cluster (used in leader election).

; Defaults to the hostname.

; cluster.id=example.com

[rpcmiddleware]

; Enable the RPC middleware interceptor functionality.

; rpcmiddleware.enable=true

; Time after which a RPC middleware intercept request will time out and return

; an error if it hasn't yet received a response.

; rpcmiddleware.intercepttimeout=2s

; Add the named middleware to the list of mandatory middlewares. All RPC

; requests are blocked/denied if any of the mandatory middlewares is not

; registered. Can be specified multiple times.

; rpcmiddleware.addmandatory=my-example-middleware

; rpcmiddleware.addmandatory=other-mandatory-middleware

[remotesigner]

; Use a remote signer for signing any on-chain related transactions or messages.

; Only recommended if local wallet is initialized as watch-only. Remote signer

; must use the same seed/root key as the local watch-only wallet but must have

; private keys.

; remotesigner.enable=true

; The remote signer's RPC host:port.

; remotesigner.rpchost=remote.signer.lnd.host:10009

; The macaroon to use for authenticating with the remote signer.

; remotesigner.macaroonpath=/path/to/remote/signer/admin.macaroon

; The TLS certificate to use for establishing the remote signer's identity.

; remotesigner.tlscertpath=/path/to/remote/signer/tls.cert

; The timeout for connecting to and signing requests with the remote signer.

; Valid time units are {s, m, h}.

; remotesigner.timeout=5s

; If a wallet with private key material already exists, migrate it into a

; watch-only wallet on first startup.

; WARNING: This cannot be undone! Make sure you have backed up your seed before

; you use this flag! All private keys will be purged from the wallet after first

; unlock with this flag!

; remotesigner.migrate-wallet-to-watch-only=true

[gossip]

; Specify a set of pinned gossip syncers, which will always be actively syncing

; whenever the corresponding peer is online. A pinned syncer does not count

; towards the configured `numgraphsyncpeers` since pinned syncers are not

; rotated. Configuring a pinned syncer does not ensure a persistent connection

; to the target peer, they will only be pinned if the connection remains active

; via some other mechanism, e.g. having an open channel.

;

; This feature is useful when trying to ensure that a node keeps its

; routing table tightly synchronized with a set of remote peers, e.g. multiple

; lightning nodes operated by the same service.

;

; Each value should be a hex-encoded pubkey of the pinned peer. Multiple pinned

; peers can be specified by setting multiple flags/fields in the config.

; gossip.pinned-syncers=pubkey1

; gossip.pinned-syncers=pubkey2

; The maximum number of updates for a specific channel and direction that lnd

; will accept over the channel update interval.

; gossip.max-channel-update-burst=10

; gossip.channel-update-interval=1m

[invoices]

; If a hold invoice has accepted htlcs that reach their expiry height and are

; not timed out, the channel holding the htlc is force closed to resolve the

; invoice's htlcs. To prevent force closes, lnd automatically cancels these

; invoices before they reach their expiry height.

;

; Hold expiry delta describes the number of blocks before expiry that these

; invoices should be canceled. Setting this value to 0 will ensure that hold

; invoices can be settled right up until their expiry height, but will result

; in the channel they are on being force closed if they are not resolved before

; expiry.

;

; Lnd goes to chain before the expiry for a htlc is reached so that there is

; time to resolve it on chain. This value needs to be greater than the

; DefaultIncomingBroadcastDelta set by lnd, otherwise the channel will be force

; closed anyway. A warning will be logged on startup if this value is not large

; enough to prevent force closes.

;

; invoices.holdexpirydelta=15

[routing]

; DEPRECATED: This is now turned on by default for Neutrino (use

; neutrino.validatechannels=true to turn off) and shouldn't be used for any

; other backend!

; routing.assumechanvalid=true

; If set to true, then we'll prune a channel if only a single edge is seen as

; being stale. This results in a more compact channel graph, and also is helpful

; for neutrino nodes as it means they'll only maintain edges where both nodes are

; seen as being live from it's PoV.

; routing.strictgraphpruning=true

Anhang B

Interview Transkript

Für einen besseren Leseﬂuss werden die beiden Gesprächsparteien jeweils abgekürzt. Die zu befragende Person wird jeweils mit A(Answer) und die fragende Person jeweils mit Q(Question) im Interviewtext gekennzeichnet. Inhalte, die Rückschlüsse auf das Unternehmen beinhalten, wurden mit einer doppelten eckigen Klammer gekennzeichnet und auf Wunsch des Interviewpartners entfernt.

Q:What motivated you to fund [company name]?

A:After quitting my old job, I ﬁrst dived into it as a hobby and started to play around with lightning nodes. I noticed how novel the industry is and that’s is still pretty hard to manage a routing node professionally. It’s a business opportunity.

Q:In general, what is the value added preposition?

A:Finally, bitcoin becomes usable for transactions. The speed, to send millions of transactions over lightning and to have one generalised network. And also small tran- sactions.

Q:From a business perspective, where do you see most applications being built? Or is it more about new applications we cannot imagine right now?

A:My guess is that in the next four to eight years most adoption will take place in eSports, gaming, anything like that.

Q:What is your view on the current regulatory environment?

A:My take is that because of the permissionsless property of the network its going to be hard to ban companies. There’s also less counterparty risk, because for example in the gaming industry where you have platforms like Steam today, this won’t be the case on lightning. You can link players directly on a protocol level. There will be regulation of course, especially for gambling, but it will take several years for regulation to catch up.

Q:A lot of people operate their nodes on Raspberry Pi’s. Would you recommend this as a business environment? And if that’s not the case, why not?

A:Its excellent for starting and experimenting. I recommend on premise larger ser- vers or cloud based or oﬀ premise servers. The balance between them depends on how this market will be regulated. Large companies will run large nodes so there will be

some kind of regulation. Right now, most nodes are operated by Bitcoiner’s, regardless of proﬁtability.

Q:What are your thought on node centralisation?

A:I think like we saw with the Bitcoin network, during the China ban, there was a lot of mining from that area, but basically just kept on running, you can have to hash power just plummeted really fast. That wasn’t problem, even though they were service, centralization of mining equipment there, I think we will see the same with the routing of there will always be a mix. Even tough some countries ban it, the fees in the network will spike, it gets more proﬁtable and some other nodes will spin up. If as long as there are nodes spread across the world, in diﬀerent local data centres or across diﬀerent data centres in the world, and some on-premise routing nodes, there’s still no problem because of the fee market. So if let’s say that ﬁfty percent of routing nodes, are just taken down in two weeks or something right or on one day then what will happen is that the fee will increase massively, if the volumes is same, and then there will be a really big return on investment

Q:So to sum it up, you would say the permissionlessness of the network always leads to some sort of natural competition or fee market where it will be fully balanced on the long term?

A:Yeah. You can stop the whole world from participating.

Q:What’s your take on routing node proﬁtability?

A:Right now the turnover for the capital invested is very low due to the low tran- saction volume. Also the capacity in the network is much higher than the transaction volume. It’s still unclear how to calculate the risk vs return ratio and what a sustainable fee rate is. Currently there’s less demand than supply on lightning liquidity. To sum- marise it, it depends upon the transaction volume and the capacity of routing nodes.

Q:If one is an investor, would you say like there will be multiple participants and routing nodes, so they have some sort of predictable return on investment, while ha- ving low risk? And what would be like the best way to achieve a low risk ? Would you outsource the key management? So if like participative investors still hold their own keys while providing liquidity on a lightning routing node? Is this some sort of future business model? Or is it highly speculative?

A:Absolutely, there’s future business models. The space around security and partial custody is developing real fast, but maybe not fast enough. So it’s hard to say that, like how much of this is going to be investments going through channels and methods that are non custodial, and how much is going to be custodial in the sense that I as a professional, normal investor, who doesn’t know anything about routing nodes invests in a routing node, because I see a lot of potential there and returning investment. But then trust around, you know, to not get hacked, right.

Q:But there are no solutions right now how to provide some sort of key manage- ment for participants of a routing node, like if they would provide capital, they cannot hold their keys on their behalf. So you always have to some sort of trust issue between

you and the routing node provider, and you have to trust them with your funds, right? A:I’m actually not completely sure, due to sort of sidecar channels, and pool - the sort of lightning labs is working with. I guess you can create a application service where you just download it. It’s not really a routing node. it’s just sort of a thing that you run places this might in diﬀerent ways. I’m not completely sure if you can actually place the channel between two nodes, I think that you can place channels between two nodes that you don’t know, or resolve the interest on sort of renting out that capacity. Because you’re essentially lending out Bitcoin to somebody, you know, a way that’s custodial. I

must be honest, I don’t know this completely.

Q:I saw just one tool, which is like, going this direction, and it’s called lightning pool. But to me, it does not seem so attractive for someone who thinks they could provide liquidity because ﬁrst you have to have some very good position in the network that somebody wants to buy your liquidity. So it’s not only about providing funds, it’s more about providing infrastructure, right?

A:Yeah, I actually used that for my node. So I think I got the highest ranking, I opened two channels, actually, to the same point, it reduced the capacity massively in a short amount of time then stopped. So I presume that was sort of selling tickets to a conference or something. And return like, what’s interesting is that return rate for loaning out the capacity in that time was not very high. Because a lot of the costs, like the model that I think I got 15,000 Satoshis for what I rented out, and then I paid 10,000 Satoshis to lightning labs for the market. Which is just a bad deal. Nevertheless, there will be better marketplaces for it as the protocol allows for custom messages to send to each other now. So you can embed arbitrary data which can be read by other software. This could store a message on swapping liquidity for example. It enables peo- ple to create secondary or third layer protocols. A good example for this is PeerSwap by Blockstream, which creates a liquidity market for LND and c-lightning implementation. So I think the product by that loop, so to be partially replaced by a lot of diﬀerent nodes oﬀering that diﬀerent compartments, this is a new market.

Q:What is the minimum requirement for deploying a successful node? Is a business model regardless of lightning essential? What would you advise someone who wants to start in the routing node industry?

A:I think you’ve deﬁnitely need a bit of liquidity. Because you need to be connected to a given node. But what you can say says that you can ﬁnd a niche just like in any business. The deﬁnition I use now is that you need at least ﬁve channels and a capacity of 0.3 Bitcoin. And the reason for that is you can spread 0.3 Bitcoin across ﬁve nodes that are very large and generate traﬃc. And because of the low amount of capital, you can actually get a decent return on. But still, if you’re too small, I think you will struggle and the less capacity you have right now the harder it is to see. Commonly the people with a lot of capacity just naturally make more money. Routing, but relative to the capacity is probably still really bad deal and return on investment expected right now.

Q:What do you see as the main challenge for for mass adoption?

A:Mass adoption can happen really quickly through custodial routing nodes. But

of course, that leads to problems with custody. When it comes to non custodial stuﬀ, like Breez playing around with, and sort of running your own node in sort of a plug and play fashion print, just buy a small thing and plug in the wall, then becomes clear there’s some way to go. Right? But it has to be much simpler than this. But we got to remember that this is three years old, basically. In the next 10 years, you’re going to see some massive, massive changes and improvements. And because of how this proto- col is built, I think we’re going to be much faster than Bitcoin, especially the sort of second or third layer, or fourth layer. I mean protocols like Peerswap allow for examp- les. Also channels which are sort of channels with liquidity that’s not actually on the blockchain, but its just sort proven that node that does it has the liquidity. Essentially to request payouts and stuﬀ like that where theres sort of a mix of custody and trust. So there are solutions like that popping up all the time. It’s impossible to talk about some mysterious software in referred to any of these facilities, but its said that they’re playing around with a concept that makes it possible to create channels to parties wi- thout putting the capacity on the channel. I think that was referring to hosted channels.

Q:And you also see some potential in asset issuance on lightning like the RGB stan- dards. Do you think this will be also key to mass adoption of lightning technology or will the use case limited to being money?

A:Honestly, I don’t know enough about it.

Q:How do you see the adoption of Bitcoin lightning in El Salvador?

A:It’s I think it’s going to be huge. But again, it takes some time people have to wrap their head around what this is and how they can use it. Securely interesting.

Q:Regarding DeFi in general, have you been diving into other payment channel net- work concepts? Like for example xDAI, they’re also using payment channel networks. And if you have looked at it, how do you compare it to lightning?

A:I thinks its just not the right area to develop it on. You get the area’s just more vulnerable, that’s irreliable to do stuﬀ like that on. And they have a huge problem that everybody wants its own token, because there’s so much money to gain from it. And then also go to VCs and stuﬀ like that. So there’s less of an eﬀort to create this huge shared protocols that bitcoin have. So I think there’s a separate market for Ethereum. Bitcon is going to win against the sort of obligation, I don’t think countries want to roll out some of the secondary protocol for payments across the country. Like we saw in El Salvador.

Q:Coming to my ﬁnal question, maybe you can share vision. How do you imagine it in three to ﬁve years what would be your your guess about the Lightning Network?

A:A scenario is one we saw from 2017 to 2019, during this time the transaction volume was very similar on Bitcoin. Until the next cycle began and we run from 670 Billion to 4.6 trillion in transaction volume on a one year period. That was massive. If we see something similiar in the next four years, so in 2026, we’re at 18 trillion. Right now we see 2% to 3% increase on a weekly basis in capacity on the network. Now, if that continues only 2% We’re at 200 something billion. I think 3% every week, we are at far over 2.6 trillion. So because there is exponential growth. So yeah, I think it’s

possible. And this is sort of some the case I’m building for my company. And if we have

2.6 trillion in direct volume, like the fee market combined, can be really, really big.

Quellenverzeichnis

Literatur

[1] Dilanthi Amaratunga u. a. „Quantitative and qualitative research in the built environment: application of “mixed” research approach“. Work Study 51.1 (Jan. 2002). Publisher: MCB UP Ltd, S. 17–31. url:

(besucht am 14. 01. 2022) (siehe S.

[2] Hendrik Amler u. a. DeFi-ning DeFi: Challenges & Pathway. 2021. arXiv: (siehe S. 24).

[3] Andreas M Antonopoulos, René Pickhardt und Olaoluwa Osuntokun. Mastering the Lightning Network: A Second Layer Blockchain Protocol for Instant Bitcoin Payments . English. OCLC: 1202057411. S.l.: O’Reilly Media Inc., USA, Dez. 2021 (siehe S. 27–30, 32, 33, 49, 52–54, 56, 57).

[4] Conrad Burchert, Christian Decker und Roger Wattenhofer. „Scalable funding of Bitcoin micropayment channel networks“. en. Royal Society Open Science 5.8 (Aug. 2018), S. 180089. url:

(siehe S. 39, 46).

[5] Yannic Fraebel. Das Lightning Netzwerk als Grundlage für die Kryptoökonomie . German. OCLC: 1138071327. GRIN Publishing, Deutschland, 2019 (siehe S. 39).

[6] Jona Harris und Aviv Zohar. „Flood & Loot: A Systemic Attack On The Light- ning Network“. arXiv:2006.08513 [cs](Aug. 2020). arXiv: 2006.08513. url:

(siehe S. 55).

[7] Robert Kaiser. Qualitative Experteninterviews. de. Wiesbaden: Springer Fachme- dien Wiesbaden, 2014. url:

(siehe S. 62, 63).

[8] Mikko Ketokivi und Thomas Choi. „Renaissance of case research as a scientiﬁc method“. en. Journal of Operations Management32.5 (2014), S. 232–240. url:

(siehe S. 62).

[9] Ponemon Institute LLC und IBM Security. Cost of a Data Breach Report 2020 . en. Aug. 2020, S. 82 (siehe S. 20).

[10] Peter Mandl. TCP und UDP Internals: Protokolle und Programmierung . ger. Lehrbuch. Wiesbaden [Heidelberg]: Springer Vieweg, 2018 (siehe S. 26, 28).

[11] Ayelet Mizrahi und Aviv Zohar. „Congestion Attacks in Payment Channel Net- works“. arXiv:2002.06564 [cs](Jan. 2021). arXiv: 2002.06564. url:

(siehe S. 55).

[12] Satoshi Nakamoto. „Bitcoin: A Peer-to-Peer Electronic Cash System“. en (2008) (siehe S. 24).

[13] Maurizio Pompella und Roman Matousek, Hrsg. The Palgrave Handbook of Fin-

Tech and Blockchain. en. Cham: Springer International Publishing, 2021. url: h

(siehe S. 7–9).

[14] J. Poon und T. Dryja. „The bitcoin lightning network: Scalable oﬀ-chain instant payments“. The Bitcoin Lightning Network: Scalable Oﬀ-Chain Instant Payments (2015) (siehe S. 26).

[15] Sonbol Rahimpour und Majid Khabbazian. „Hashcashed Reputation with Ap- plication in Designing Watchtowers“. arXiv:2012.10825 [cs](Dez. 2020). arXiv:

2012.10825. url: (siehe S. 57).

[16] Didier Rullière, Diana Dorobantu und Areski Cousin. „An extension of Davis

and Lo’s contagion model“ (2010). arXiv: (siehe S. 18).

[17] Wharton Business School und World Economic Forum. „DeFi Beyond the Hype“.

[18] Springer Fachmedien Wiesbaden, Hrsg. Kompakt-Lexikon Wirtschaft: 5.400 Be- gri ﬀe nachschlagen, verstehen, anwenden. de. Wiesbaden: Springer Fachmedien Wiesbaden, 2014. url:

(siehe S. 11, 12, 15).

[19] Victor Tiberius und Christoph Rasche, Hrsg. FinTechs. de. Wiesbaden: Springer Fachmedien Wiesbaden, 2017. url:

(siehe S. 8).

[20] Philipp Zabka u. a. „A Centrality Analysis of the Lightning Network“. en. ar- Xiv:2201.07746 [cs](Jan. 2022). arXiv: 2201.07746. url:

(siehe S. 67, 68).

[21] Philipp Zabka u. a. „Node Classiﬁcation and Geographical Analysis of the Light- ning Cryptocurrency Network“. en. In: International Conference on Distributed Computing and Networking 2021 . Nara Japan: ACM, Jan. 2021, S. 126–135. url:

(siehe S. 36, 37, 67).

Online-Quellen

[22]

https:// www.aljazeera.com/economy/2021/8/25/central-american-nations-ask-can-bitcoin-cut-remittance-costs (besucht am 01. 09. 2021) (siehe S. 1).

Central American nations ask: Can Bitcoin cut remittance costs? en. Aug. 2021. url:

[23]

https://www.gabler-banklexikon

9. 08. 2021) (siehe S. 8).

Prof. Dr. Rainer Alt. Deﬁnition: Open Banking. de. Publisher: Springer Fachme- dien Wiesbaden GmbH Section: economy.

[24] European Central Bank. Glossary. en. Juli 2021. url: https://www.ecb.europa.e

(besucht am 10. 11. 2021) (siehe S. 13).

[25]

https

://timevalueofbtc.medium.com/the-lightning-network-reference-rate-98e41a9dadf

(besucht am 03. 09. 2021) (siehe S. 70).

Nik Bhatia. The Lightning Network Reference Rate. en. März 2019. url:

[26] BIS und Raynor de Best. Most traded currency pairs in forex 2020 . en. Feb. 2021. url: https://www.statista.com/statistics/1203453/most-traded- currency- pairs/ (besucht am 27. 10. 2021) (siehe S. 14).

[27]

https://www.bundesbank.de/de/aufgaben/unbarer-zahlungsverkehr/ueberwachung/individual

zahlungsverkehrssysteme-603584 (besucht am 19. 10. 2021) (siehe S. 12).

Deutsche Bundesbank. Individualzahlungsverkehrssysteme. de. url:

[28] Deutsche Bundesbank. Massenzahlungsverkehr | Glossar . de. url:

[29]

https:// www.bundesbank.de/de/aufgaben/unbarer- zahlungsverkehr/psd2/psd2- 775434 (besucht am 15. 10. 2021) (siehe S. 8).

[30]

Capgemini. Cashless transactions by region 2023. en. Nov. 2021. url: https://www.statista.com/statistics/265767/number-of-cashless-transactions-worldwide-by -region/ (besucht am 11. 11. 2021) (siehe S. 21).

[31] Mayank Chhabra. Umbrel — a personal server for everyone . en. url: (besucht am 09. 12. 2021) (siehe S. 36).

[32] Mayank Chhabra. Umbrel raises $3M in seed round to get a server in every home . en. Okt. 2021. url: https://blog.getumbrel.com/seed-6d09aa08f8ac (besucht am 09. 12. 2021) (siehe S. 36).

[33] Lightning Developers. Lightning Network In-Progress Speciﬁcations . Nov. 2021. url: https://github.com/lightning/bolts/blob/0dc3af80ce33dea1ab61204f19bb36 ddff9fa407/00-introduction.md (besucht am 18. 11. 2021) (siehe S. 28).

[34] LNBits Developers. LNbits. url: (siehe S. 73).

(besucht am 22. 03. 2022)

[35] LNBits Developers. LNBits - Free Open Source Bitcoin Lightning Wallet Ac-

counts System. en. url:

S. 73).

(besucht am 22. 03. 2022)

[36]

Jake Frankenﬁeld. Micropayment Deﬁnition. en. März 2021. url:

(besucht am 02. 11. 2021)

[37]

Umbrel Developers. Automatic Encrypted Backups. März 2022. url: https://git hub.com/getumbrel/umbrel/blob/master/scripts/backup/README.md (besucht am 07. 03. 2022) (siehe S. 54).

[38] International Monetary Fund. Currency Composition of Oﬃcial Foreign Ex- change Reserves (COFER) . Abrufbar nur über Universitäts-VPN. Sep. 2021. url: https://data.imf .org/?sk=E6A5F467- C14B- 4AA8- 9F6D- 5A09EC4E62A4 (besucht am 29. 10. 2021) (siehe S. 17, 18).

[39] Bibliographisches Institut GmbH. Clearing | Duden. de. 2021. url: https://ww

(besucht am 10. 11. 2021) (siehe S. 12).

[40] Fulmo GmbH. Building the Lightning Network. en-US. url: (besucht am 09. 12. 2021) (siehe S. 35).

[41] Chivo Wallet gov. Inicio|Chivo Wallet. es. 2021. url: (besucht am 01. 09. 2021) (siehe S. 2).

[42]

https://sites.krieger.jhu.edu/iae/files/2021

/11/Bukeles-Bitcoin-Blunder-Final.pdf (besucht am 31. 12. 2021) (siehe S. 1).

Steve H. Hanke, Nicolas Hanlon und Mihir Chakravarthi. BUKELE’S BITCOIN BLUNDER . No. 185. Juni 2021.

[43] Dr. Heldt u. a. Deﬁnition: Clearing. de. Publisher: Springer Fachmedien Wiesba- den GmbH Section: economy. u

[44] IMFBlog. Cryptoassets as National Currency? A Step Too Far . eng. Juli 2021.

https://blogs.imf.org/2021/07/26/cryptoassets-as-national-currency-a-step

-too-far/

(besucht am 31. 08. 2021) (siehe S.

1).

[45] Lightning Labs Inc. Conﬁguring Watchtowers. url:

eering/lightning- network- tools/lnd/watchtower (besucht am 08. 03. 2022) (siehe

S. 57).

[46] Lightning Labs Inc. Lightning Terminal. en. url: (besucht am 31. 01. 2022) (siehe S. 48).

[47]

https://docs.lightning.engineering/lightning-network-tools/lnd/recovery-planning-for-failure#static-chann

el-backups-scb (besucht am 07. 03. 2022) (siehe S. 54).

Lightning Labs Inc. Recovery: Planning for failure. url:

[48]

[49] Lightning Labs Inc. simplecrypto.app-learning.com | Lightning Terminal . en.

url: https://terminal.lightning.engineering (besucht am 07. 03. 2022) (siehe S. 60).

[50] Lightning Labs Inc. und Lightning Developers. What Makes a Good Routing

[51] PayPal Inc. List of Third Parties (other than PayPal Customers) with Whom Personal Information May be Shared . en-IE. Okt. 2021.

(besucht am 03. 11. 2021) (siehe

[52]

[53] BlueWallet Services S. R. L. LndHub - A Lightning Hub for Service providers.

en. url: (besucht am 21. 03. 2022) (siehe S. 72, 73).

[54] BlueWallet Services S. R. L. lndhub.io. url:

22. 03. 2022) (siehe S. 73).

[55] Michael Maharrey. How America’s Use of Economic Warfare Could Spark a Cur- rency Crisis . en. Okt. 2018. url: https://fee.org/articles/swift-and-the-weaponiz

(besucht am 29. 10. 2021) (siehe S. 17).

[56] Annerton Rechtsanwaltsgesellschaft mbH. 3-Parteien-System |Glossar|Pay-

TechLaw | FinTechLawyers. de-DE. url: https://paytechlaw.com/glossary/3-par

(besucht am 18. 10. 2021) (siehe S. 16).

[57] Annerton Rechtsanwaltsgesellschaft mbH. 4-Parteien-System |Glossar|Pay-

TechLaw | FinTechLawyers. de-DE. Sep. 2019. url: https://paytechlaw.com/glo

(besucht am 18. 10. 2021) (siehe S. 15).

[58]

https://wirtschaftsl

Jochen Metzger. Deﬁnition: elektronischer Zahlungsverkehr. de. Publisher: Sprin- ger Fachmedien Wiesbaden GmbH Section: economy. url: exikon.gabler.de/definition/elektronischer- zahlungsverkehr- 36793/version- 260240 (besucht am 13. 10. 2021) (siehe S. 11).

[59] Jochen Metzger. Deﬁnition: SWIFT. de. Publisher: Springer Fachmedien Wies- baden GmbH Section: economy. url: https://wirtschaftslexikon.gabler.de/definit

(besucht am 20. 10. 2021) (siehe S. 13, 14).

[60] Jochen Metzger. Deﬁnition: TARGET2. de. Publisher: Springer Fachmedien Wiesbaden GmbH Section: economy. url: https://wirtschaftslexikon. gabler. de

(besucht am 13. 10. 2021) (siehe S. 12).

[61] Jochen Metzger. Deﬁnition: Zahlungsinstrumente. de. Publisher: Springer Fach- medien Wiesbaden GmbH Section: economy. url: https :// wirtschaftslexikon

. gabler . de / definition / zahlungsinstrumente - 47544 / version - 270808 (besucht am 27. 10. 2021) (siehe S. 15).

[62]

https://wirtschaftslexikon.gabler.de

/definition/zahlungskarte-50036/version-273262

(besucht am 27. 10. 2021) (siehe

Jochen Metzger. Deﬁnition: Zahlungskarte. de. Publisher: Springer Fachmedien Wiesbaden GmbH Section: economy.

S. 15).

[63] Jochen Metzger. Deﬁnition: Zahlungsverkehr. de. Publisher: Springer Fachmedi- en Wiesbaden GmbH Section: economy. url:

(besucht am 13. 10. 2021)

[64] MyNodeBTC. myNode - The easiest way to run Bitcoin and Lightning! url:

(besucht am 09. 12. 2021) (siehe S. 35).

[65] United Nations. #Envision2030 Goal 8: Decent Work and Economic Growth | United Nations Enable . url: https://www.un.or g/development/desa/disabilities

(besucht am 02. 11. 2021) (siehe S. 18, 19).

[66]

https://population.un.or

(besucht am 02. 09. 2021) (siehe S. 2).

[67] Trendstorm Pte. Bitcoin Lightning Capacity. en. url: https://www.lookintobitco

(besucht am 01. 09. 2021) (siehe S. 2).

[68] Trendstorm Pte. Bitcoin Lightning Nodes. en. url: https://www.lookintobitcoin

(besucht am 01. 09. 2021) (siehe S. 3).

[69]

https://www.reuters.com/technology/el-salvador

-congress-backs-150-mln-fund-bitcoin-ahead-adoption-2021-08-31/ (besucht am

01. 09. 2021) (siehe S.

1).

El Salvador Congress backs $150 mln fund for bitcoin ahead of adoption . en. Aug. 2021. url:

[70] Dr. Matthäus Schindele. WiefunktionierteineKreditkartenzahlung? PayTech-

Law klärt auf.de-DE. Section: Infograﬁk. Apr. 2019. url: https://paytechlaw.co

(besucht am 27. 10. 2021) (siehe S. 15).

[71]

htt

ps://medium.com/breez-technology/introducing-lightning-service-providers-fe9fb1

665d5f (besucht am 18. 08. 2021) (siehe S. 65, 66).

Roy Sheinfeld. Introducing Lightning Service Providers. en. Aug. 2019.

[72]

[73] Emily Sorensen. What is a neobank? How does it diﬀer from traditional banks?

en-GB. Section: Business accounts. Sep. 2019. url: https://www.mobiletransacti

(besucht am 16. 10. 2021) (siehe S. 10).

[74] Statista. Credit cards worldwide. en. 2021. url:

(besucht am 27.

[75] Statista. Neobanking - Europe| Statista Market Forecast. en. url:

.statista.com/outlook/dmo/fintech/neobanking/europe (besucht am 18. 10. 2021)

(siehe S. 10).

[76] Malte Stöfen. Deﬁnition: Zahlungsdienst. de. Publisher: Springer Fachmedien Wiesbaden GmbH Section: economy. url:

(besucht am 27. 10. 2021) (siehe

[77] Amboss Technologies. Amboss Space - Lightning Network Explorer . en. 2021.

url: (besucht am 13. 02. 2022) (siehe S. 51).

[78] Breez Technology. About Breez Technology. url:

(besucht am 08. 03. 2022) (siehe S.

[79] Breez Technology. Technology. en. url:

l (besucht am 16. 03. 2022) (siehe S. 65).

[80] Warren Togami und Konstantin Nick. PeerSwap - Decentralized P2P LN Balan-

[81] Luca Ventura. Global Finance Magazine - World’s Most Unbanked Countries

[82] Worldbank. The unbanked | Global Findex. 2017. url: https://globalfindex.worl

(besucht am 02. 11. 2021) (siehe S. 18).

[83] Society for Worldwide Interbank Financial Telecommunication. About Us . en.

url: (besucht am 20. 10. 2021) (siehe S. 14).

[84] Society for Worldwide Interbank Financial Telecommunication. Most used cur- rencies in the world 2020 . en. Nov. 2020. url: https:// www.statista.com/stati stics/1189498/share- of- global- payments- by- currency/ (besucht am 27. 10. 2021)

(siehe S. 14).

[85] Society for Worldwide Interbank Financial Telecommunication. SWIFT over- sight . en. url: https://www.swi ft.com/about-us/organisation-governance/swift-o

(besucht am 19. 10. 2021) (siehe S. 14).

Software

[86] Bitcoin Core Developers. Bitcoin Core. Nov. 2021. url: (besucht am 18. 11. 2021) (siehe S. 28).

[87] BlueWallet Developers. LndHub. März 2022. url: (besucht am 21. 03. 2022) (siehe S. 72).

[88] Charge-LND Developers. charge-lnd. Jan. 2022. url: https://github.com/accum

(besucht am 21. 01. 2022) (siehe S. 50).

[89] Chiang Mai LN developers. LND Neutrino Switch Contrainer . Sep. 2021. url:

https://github.com/lncm/docker- lnd- neutrino- switch (besucht am 08. 01. 2022)

(siehe S. 41).

[90] LDK Developers. Lightning Dev Kit. en. url:

t (besucht am 01. 12. 2021) (siehe S. 32).

[91] LDK Developers. Rust-Lightning. Nov. 2021. url: https://github.com/rust-bitco

(besucht am 18. 11. 2021) (siehe S. 31).

[92] LNBits Developers. LNbits. März 2022. url: (besucht am 22. 03. 2022) (siehe S. 73).

[93] mynodebtc Developers. myNode. Nov. 2021. url: (besucht am 01. 12. 2021) (siehe S. 35).

[94] Umbrel Developers. LNbits on Umbrel. März 2022. url: https://github.com/g etumbrel / umbrel / blob / master / apps / lnbits / docker - compose . yml (besucht am 22. 03. 2022) (siehe S. 73).

[95] Umbrel Developers. Umbrel — a personal server for everyone . Jan. 2022. url:

https://github.com/getumbrel/umbrel

42)

(besucht am 08. 01. 2022)

[96] Umbrel Developers. Umbrel App Framework. en. url: https://github.com/getum

(besucht am 20. 01. 2022) (siehe S. 43).

[97] Umbrel Developers. Umbrel dashboard. Dez. 2021. url: https://github.com/getu

(besucht am 08. 01. 2022) (siehe S. 41).

[98] Umbrel Developers. Umbrel LND Sample. Jan. 2022. url:

tumbrel/umbrel/blob/master/templates/lnd-sample.conf (besucht am 20. 01. 2022)

(siehe S. 43).

[99] Umbrel Developers. Umbrel manager. Nov. 2021. url:

(besucht am 08. 01. 2022) (siehe

[100] Umbrel Developers. Umbrel middleware. Dez. 2021. url: https://github.com/ge

(besucht am 08. 01. 2022) (siehe S. 41).

[101] Umbrel Developers. Umbrel Security Disclosure . Feb. 2022. url:

.com/getumbrel/umbrel/blob/master/SECURITY.md (besucht am 15. 02. 2022)

(siehe S. 53, 54).

[102] Wikimedia Foundation. Raspberry Pi. en. Page Version ID: 1064054781. Jan. 2022. url: https://en.wikipedia.org/w/index.php?title=Raspberry_Pi&oldid=106

(besucht am 08. 01. 2022) (siehe S. 42).

[103] Fulmo GmbH. Raspiblitz. Dez. 2021. url: (besucht am 09. 12. 2021) (siehe S. 35).

[104] Blockstream Corporation Inc. c-lightning: A speciﬁcation compliant Lightning Network implementation in C . Nov. 2021. url: https://github.com/ElementsPro

(besucht am 18. 11. 2021) (siehe S. 31).

[105] Lightning Labs Inc. btcd. Nov. 2021. url: (besucht am 18. 11. 2021) (siehe S. 28).

[106] Lightning Labs Inc. Lightning Loop. Feb. 2019. url:

(besucht am 20. 03. 2022) (siehe S. 71).

[107] Lightning Labs Inc. Lightning Loop gRPC API Reference. Feb. 2019. url:

s://lightningloop.io/#lightning-loop-grpc-api-reference (besucht am 20. 03. 2022)

(siehe S. 71).

[108] Lightning Labs Inc. Lightning Network Daemon. Nov. 2021. url:

(besucht am 18. 11. 2021) (siehe S. 31).

[109] Lightning Labs Inc. Neutrino: Privacy-Preserving Bitcoin Light Client . Dez. 2021. url: https://github.com/lightninglabs/neutrino (besucht am 04. 01. 2022)

(siehe S. 27).

[110] Lightning Labs Inc. Remote Signing. Jan. 2022. url:

(besucht am 19. 02. 2022)

[111] Lightning Labs Inc. sample-lnd.conf. Jan. 2022. url:

[112] Joost Jager. Circuit Breaker. Feb. 2022. url: https://github.com/lightningequip

(besucht am 19. 02. 2022) (siehe S. 58).

[113] Altangent Labs. Node-Lightning (formerly LNTools). Nov. 2021. url:

(besucht am 20. 11. 2021) (siehe S.

[114] Konstantin Nick und Peter Neuroth. PeerSwap. März 2022. url: https://github

(besucht am 18. 03. 2022) (siehe S. 71, 72).

[115] Carsten Otto. rebalance-lnd. Feb. 2022. url: (besucht am 13. 02. 2022) (siehe S. 52).

[116] ACINQ SAS. eclair. Nov. 2021. url: am 18. 11. 2021) (siehe S. 31).

(besucht

[117] Umbrel. Umbrel OS. Jan. 2022. url: https://github.com/getumbrel/umbrel- os

(besucht am 31. 01. 2022) (siehe S. 40).

Frequently asked questions

What is the abstract about?

The abstract discusses the rapid changes in global financial structures due to advances in technology, particularly the digitization of financial services driven by information and communications technology. It highlights the emergence of neobanks and decentralized financial systems like Bitcoin and its Lightning Network. The thesis explores Lightning Service Providers as an alternative to neobanks in the FinTech industry, detailing their implementation and operational challenges.

What are the keywords associated with this document?

The keywords include Bitcoin, Lightning Network, Lightning Service Provider, Lightning Node, Routing Node, Node Operation, Crypto Transaction System, Payment Infrastructure, Miniaturization, CeFi, DeFi, Blockchain, Cryptocurrency, Neobank, and Financial Technology.

What is the "Kurzfassung" about?

The "Kurzfassung" is a German abstract which outlines the rapid changes in global financial structures due to technological progress, specifically the digitization of financial services. It mentions neobanks as pioneers of innovative financial technology and the decentralized financial world emerging with internet currencies like Bitcoin. The abstract discusses Lightning Nodes and Lightning Service Providers as an alternative to neobanks and focuses on the operational challenges and interdisciplinary approach for integrating new users into the system.

What are the keywords for the "Kurzfassung"?

The keywords are Bitcoin, Lightning Netzwerk, Lightning Service Provider, Lightning Node, Routing Node, Nodebetrieb, Kryptotransaktionssystem, Zahlungsverkehr, Zahlungsinfrastruktur, Miniaturisierung, CeFi, DeFi, Blockchain, Kryptowährung, Neobank, Finanztechnologie.

What is the purpose of Chapter 1, "Einleitung" (Introduction)?

Chapter 1 provides an introduction to the thesis, discussing the motivation behind the study, the research questions and objectives, and the methodologies employed. It touches upon El Salvador's adoption of Bitcoin, criticisms from international financial bodies, and the potential of the Lightning Network for facilitating transactions.

What are some topics that will be explored in this thesis?

The topics cover the current state of payment infrastructures, including the history, evolution, and limitations; Lightning Nodes, covering architecture, terminology, and software implementation; Node Implementation covering Configuration, Security and syllabus; and the Lightning Service Provider Model covering Interviews, wortherkunft, and how they compare to Neobanks.

What are Lightning Nodes and how are they categorized?

A Lightning Node is a software application implementing the Lightning protocol. They enable digital payments akin to cash, differing from traditional payment methods. Nodes can be categorized as Inbound Nodes (receiving more payments), Outbound Nodes (mostly paying), or Routing Nodes (forwarding payments and balancing channels).

What is the purpose of LND and the Bolt specifications?

LND (Lightning Network Daemon) is a popular software implementation. The BOLT (Basis of Lightning Technology) are open standard specifications for the Lightning Network protocol. They exist to ensure compatibility between various Lightning Network implementations.

What are the basic hardware requirements for running a lightning node?

The minimum hardware requirements include adequate CPU power (2-4 core), at least 4GB of RAM, a suitable storage medium (SSD is preferred), a permanent internet connection, a reliable power supply, and automated backups.

What are some risks associated with running lightning nodes?

Operating risks include hot wallet risks, hardware risks, operationg system risks, loss of the SCB, and DoS attacks.

What is the function of Lightning Service Providers (LSPs)?

LSPs connect users to the Lightning Network, managing payment channels, providing liquidity, routing transactions, rebalancing channels, and ensuring reliability.

What is the Lightning Network Reference Rate (LNRR)?

LNRR is a conceptual metric used to determine the profitability of a lightning node.

What is the difference between Neobanks and Lightning Service Providers?

Neobanks operate in the traditional financial ecosystem (CeFi), dealing with fiat currencies and regulated by authorities, whereas Lightning Service Providers are part of the decentralized finance (DeFi) ecosystem, using Bitcoin, and operating with lesser regulatory control.

Final del extracto de 129 páginas - subir

Detalles

Título: Lightning Dienstleister als Alternative zu Neobanken?
Subtítulo: Lightning service providers as an alternative to neobanks?
Universidad: University Of Applied Sciences Munich
Calificación: 1,0
Autor: Yannic Fraebel (Autor)
Año de publicación: 2022
Páginas: 129
No. de catálogo: V1331445
ISBN (PDF): 9783346818492
Idioma: Alemán
Etiqueta: Bitcoin Lightning LSP Neobank DeFi Zahlungsinfrastrukturen Disruption Community Banking Dezentralisierung Zentralbank Kryptowährung Lightning Node Lightning Netzwerk Routing Node Nodebetrieb Kryptotransaktionssystem Zahlungsverkehr Miniaturisierung CeFi Blockchain Finanztechnologie
Seguridad del producto: GRIN Publishing Ltd.

Citar trabajo: Yannic Fraebel (Autor), 2022, Lightning Dienstleister als Alternative zu Neobanken?, Múnich, GRIN Verlag, https://www.grin.com/document/1331445

Lightning Dienstleister als Alternative zu Neobanken?

Lightning service providers as an alternative to neobanks?

Extracto

Abstract

Kurzfassung

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Kapitel 1

Einleitung

1.1. Motivation

1.2. Sind Lightning Service Provider eine Alternative zu Neobanken in der FinTech-Branche?

1.3. Aufgabenstellung & Ziel

1.4 Methodik & Durchführung

Kapitel 2

Stand gegenwärtiger Zahlungsinfrastrukturen

2.1. Entstehungsgeschichte

2.2. Wichtige Begriﬀe & Deﬁnitionen

2.3. Einschränkungen gegenwärtiger Finanz-/Zahlungsinfrastrukturen

2.4. Quintessenz heutiger Strukturen

Kapitel 3

Lightning Nodes

3.1. Abgrenzung & Analogie

3.2. Node-Architektur & Terminologien

3.3. Populäre Node-Architekturen

3.4. Verbreitung verschiedener Nodearten

Kapitel 4

Node Implementierung

4.1. Zahlungskanäle

4.2. Ausgewählte Software-Architektur

4.3. Konﬁguration

4.4. Inbetriebnahme

4.5. Operative Risiken

4.6. Sicherheit & Prävention

4.7. Syllabus

Kapitel 5

Lightning Service Provider Modell

5.1. Interview

5.2. Wortherkunft

5.3. Unterschiede von LSP

5.4. Herausforderungen & Lösungsansätze

5.5. Vergleich von LSP und Neobank

5.6. Neobank Lightning Service Provider

Kapitel 6

Ergebnisse & Fazit

6.1. Reﬂexion der Ergebnisse

6.2. Ausblick & Implikationen für die Praxis

6.3. Weitere Forschungsarbeiten

Anhang A

LND-Konﬁgurationsdatei

Anhang B

Interview Transkript

Quellenverzeichnis

Literatur

Online-Quellen

Software

Frequently asked questions

What is the abstract about?

What are the keywords associated with this document?

What is the "Kurzfassung" about?

What are the keywords for the "Kurzfassung"?

What is the purpose of Chapter 1, "Einleitung" (Introduction)?

What are some topics that will be explored in this thesis?

What are Lightning Nodes and how are they categorized?

What is the purpose of LND and the Bolt specifications?

What are the basic hardware requirements for running a lightning node?

What are some risks associated with running lightning nodes?

What is the function of Lightning Service Providers (LSPs)?

What is the Lightning Network Reference Rate (LNRR)?

What is the difference between Neobanks and Lightning Service Providers?

Detalles