Ein herzliches Hallo in die Runde!
Ich hab mir erlaubt mal eine Experimente, Erfahrungen, Recherchen und Überlegungen zu teilen. Vorab gleich mal ein „Sorry“ für den englisch/deutsch Mix im Text, aber irgendwie sind englische Begriffe in einigend Fällen einfach griffiger und dann ist es auch einfach Gewohnheit. Des weiteren ist folgendes nicht als Weisheit letzter Schluss zu betrachten, sondern ein versuch wie ich die Dinge verstanden habe, strukturieren wider zugeben. Das ganze wurde etwas länger als anfangs Gedacht.
Viel Spaß beim Lesen, Kritik, Anregungen, Richtigstellungen erwünscht!
Allgemein:
Eine Node ist eine Hotwallet somit immer am Netz und online, der Privatkey liegt auf der Node. Das soll keine Panik verbreiten nur es ins Bewusstsein holen. Im Normalfall und im Gegensatz zu einer Bitcoin Onchain Transaktion wird nicht an eine Lightning Wallet Adresse gesendet. Sondern von der Empfangende Seite eine Rechnung (Invoice) gestellt. Das heißt das die satoshis werden „gezogen“. Es gibt so etwas wie ein Lightningwallet Adresse nicht im klassischen Sinne nur die Public-Adresse der Node. An die auch unter gewissen Umstände „gesendet“ wird (KeySend) hier werden satoshis von der lokalen Seite eines Kanals in auf Gegenseite geschoben. Oder LNUrlPay wo der Node aufgefordert wird eine Rechnung zu stellen.
Channel:
Eine P2P Verbindung zwischen 2 Nodes. Wie eine Rohrleitung die mit einer bestimmten Menge an satoshi gefüllt wird und diese Volumen kann hin und her fließen.
Limits:
• minimum 20000 satoshi
• maximum 2^24 - 1 satoshi (0.16777215 BTC)
• Single Transaktionslimit 2^32 millisatoshis (0.042949672
Wumbo-Protokol
Muss eigens aktiviert werden und ist alles größer als 0.16 BTC
soweit keine Limits mehr. Soft Limits default 10 BTC Größe und 0,5 BTC Payment.
Beim öffnen eines Kanals (Funding) wird Guthaben auf eine Multisig-Adresse eingezahlt die von beiden Teilnehmern kontrolliert wird. Es werden 3 Transaktionen erstellt und signiert aber nur eine dem Netzwerk bekannt gegeben. Die eine Transaktion, die gesendet wird, finanziert den Kanal und gibt eine Multisig-Output aus. Es wird von jedem unterschrieben, der den Kanal finanziert. Wenn diese Finanzierungstransaktion eine ausreichende Bestätigung erhält, gilt der Kanal als offen.
Die verbleibenden zwei Transaktionen, die erstellt, aber nicht veröffentlicht werden, sind Commitment-Transaktionen. Diese werden von beiden Zahlungskanal-Partner signiert, und jeder Peer speichert seine eigenen Commitment-Transaktionen zur späteren Verwendung in einer möglichen zukünftigen Closing-Transaktion. Die Commitment Transkation wir von beiden Seiten benutzt um quasi den Kontostand zu führen da jeder die Signatur des anderen hat. Wird der Kanal geschlossen und die Multisig-Adresse an das Netz bekannt begeben bekommt jeder seinen letzten vereinbarten Kontostand.
Normal wird kooperativ geschlossen. Wird ein schließen erzwungen weil z.B. der andere Node ewig offline ist und die Liquidität blockiert wird die freigab auf die Onchain verzögert. Sobald das Schließen eingeleitet wird kann der Kanal nicht mehr verwendet werden. Die schließende Seite trägt die OnChain Gebühren in beiden fällen. Edit 24.08.21 Falsch: Die Schließungskosten bezahlt IMMER derjenige der den Kanal eröffnet hat.
Inbound:
Liquidität auf der Remote Seite des Kanals ergo eingehende Liquidität/Zahlungen erhalten
Outbound:
Liquidität auf der lokalen Seite des Kanals ergo ausgehende Liquidität /Zahlungen versenden
Die Überlegung welchen Zweck der Node erfüllen soll, legt dann fest was einem wichtiger ist. Bin Ich Händler und verwende eine Node um Zahlung meines Webshops anzunehmen bin ich eher bestrebt mehr Inbound zu haben. Bin ich Einkäufer dann natürlich eher Outbound.
Soll der Node hauptsächlich Zahlungen weiterleiten ist man versucht die Balance des Kanals auf 50% (Optimal) zu haben (Balancing von 1). Damit der Kanal am effizientesten genutzt werden kann.
Die maximale Menge die Versenden oder Empfange werden kann, ist auf die Größe des Größten Kanals begrenzt nicht die Summe. ( Ausnahme Multipath-Payments).
Wenn man das Beispiel vom Bild nimmt heißt das es können maximal 3M versendet aber 9.8 M empfangen bzw. erhalten werden. Dies ändert sich dann natürlich wie die Balance steht.
Routing:
Hier muss man wissen das die Gesamtsumme links und rechts abzüglich Routing-gebühren gleicht bleibt, das heißt es ist trotz der hohen Inbound-Menge nicht möglich mehr als 3M weiterzuleiten. Sprich das was rein kommt muss auch wieder raus gehen. Ich kann also nur die Menge weiterleiten die ich in einen anderen Kanal als Outbound habe.
Überarbeitung 06.05.2021: (Muss diesen Abschnitt korrigieren da nicht ganz klar)
##Begin
Routing-Gebühren bekommt man nur für das weiterleiten von Liquidität. (PushOut) Zur verrechung werden die werte am outbound channel genommen. Es ändert aber an der ganzen vorgehensweise nicht viel. Speziell wenn man zu beginn überall die gleichen gebühren setzt. Man weis auch am anfang gar nicht welche richtungen und routen gut gehen. Dh man wird im nach hinnein dort wo viel volumen raus geht langsam die Gebühren anziehen.
##END
Das Bringt mich zu den Gebühren im allgemeinen, es ist scheinbar so das sehr viele die Standard Einstellungen belassen. Hat aber so scheine Schattenseiten. Es folgen ein paar Überlegungen.
Base Fee:
Grund Betrag unabhängig von der weiter geleitet Menge an Satoshis, Standard Wert 1000mSat = 1Sat das scheint es nicht viel zu rütteln zu geben hab aber auch schon krumme werte wie 300mSat oder 3624mSat oder auch 0 gesehen.
Fee Rate:
In ppm (parts per million) der Standardwert ist hier 1 ppm was unter normalen Umständen viel zu wenig ist. (meine Ansicht)
Wie berechnen sich nun die Gebühren. {satoshi* FeeRate+BaseFee] mit dem Werten von oben nun ein Beispiel:
Gesendet werden 1M Sat: 0,000199sat1 000 000sat+1sat=200Sat→ 200 000mSat*
Also pro Million Satoshi die der Kanal weiterleitet bekommt man 200 Sat. Für den der die Zahlung macht ist das aber nicht alles sonder die gebühren pro Node (HOP) werden addiert. Läuft so eine Zahlung von 1MSat über 3 Nodes, die der Einfachheit halber jetzt die selben Gebühren verlangen sind die Gebühren 600Sat von dem man 200Sat abbekommt.
Der Sender kann allerdings die Gebühren bestimmen die er bereit ist zu zahlen und so wird die Günstigste Route gesucht. Möchte hier hinzufügen das aber ein Stabiler Node mit großen Kanälen ein bessere Reputation hat als günstige Routing gebühren. Zugverlässlichkeit und Alter wiegt also stärker. (Reputation – BOS Score – von Lightning Labs)
Jetzt kommt man zu der Überlegung welche Gebühren sind Sinnvoll und vielleicht auch wirtschaftlich. 1ppm als Standard ist es definitiv nicht. In eine Speziellen Verbund von Nodes natürlich schon zweit Geschäftspartner z.B. in einem Privaten Kanal die sich Gegenseitige keine Gebühren verrechnen oder nur sehr wenig. Und man merkt sofort das Ganze ist stark abhängig von der Größe des Kanals und der Dauer diesen offen zu halten.
Ein Betrachtung wäre:
(Eröffnungskosten + zu erwartende Schließkosten) / Kapazität x1 000 000 =ppm
Nehmen wir hier nun auch ein Beispiel was das konkret an Gebühren bedeuten würde.
Der Einfachheit wieder, gerade Zahlen und die optimistischen annahmen die Schließkosten sind gleich wie die Eröffnungskosten
(1500sat + 1500sat) / 10 000 000 Sat x1 000 000 = 300ppm
Das heißt man bekommt seine OnChain kosten gedeckt, wenn einmal der Kanal komplett gefüllt wird. Bei einem Kanal mit 10M scheint das auch noch schön zu passen und durchaus realistische Betriebsparameter. Ist der Kanal jedoch nur mehr 1M groß (bei gleichen kosten) wären die nötigen Gebühren dafür schon 3000ppm was definitiv zu hoch ist weil es genug andere Routen geben wird die weit günstiger sind. Lässt man die Gebühr bei 300ppm muss ich zehn mal die 1M empfangen.
Hier sieht man schon das das ganze eine gesunde Balance benötigt zwischen Kanal Größe und Dauer. Auf alle fälle läuft man mit zu niedrigen Gebühren Gefahr das einem ständig der Kanal leer gezogen wird weil die billige Liquidität abgezogen wird. Ja, sie kommt auf einem anderen Kanal wieder rein aber zerstört evtl. den Balance werte. Die Gebühr von 199ppm hab ich gewählt weil das nach diesen Überlegung bei diesem spezifischen Kanal 3 mal das Volumen weitergeleitet werden muss bis zum break even, der bei vielen kleine Bewegung durch die base fee früher eintritt.
Eine Weitere Möglichkeit: Dynamische Gebühren
Die Idee hierbei ist die Gebühren gering zu halten solang der Kanal gefüllt ist um Liquidität aus den Kanal zu bekommen und zu erhöhen wenn die Liquidität fällt um den Abfluss zu „bremsen“ Angebot nach frage. Um So eine Balance im Kanal zu „steuern“. Oder man staffelt andersrum. Also um den Zufluss zu bremsen wenn der Kanal zu voll wird.
Als Beispiel ein Kanal mit 10M Größe bremst das leeren (deplete)
- Local Balance 10-7M – 50ppm
- Local Balance 7M-3M – 100ppm
- Local Balance 3M-0M – 200ppm
Als Beispiel ein Kanal mit 10M Größe bremst das füllen (supply)
- Local Balance 10-7M – 200ppm
- Local Balance 7M-3M – 100ppm
- Local Balance 3M-0M – 50ppm
Das kann natürlich über Skripte automatisiert werden, hier wäre zu erwähnen das ein zu häufiges ändern der Gebühren beim routing „abgestraft“ wird also eigentlich ein zu häufiges erhöhen weil beim es beim routing zu Fehlschlägen kommen kann. Das kann dann zu ähnlich Fehlern führen das nicht geroutet werden kann wegen zu wenig Kapazität. Routen schlägt fehl weil ständig die Gebühren erhöht werden.
Hier noch als Beispiel einer Preisliste:
Es gibt noch zwei weitere Werte in den Einstellung zum Kanal die ich auch beleuchten möchte.
Die Passagen sind von mir aus dem Englischen übersetzt.
CLTV Delta
TimeLockDelta (oder cltv_expiry_delta) ist die Mindestanzahl von Blöcken, die ein Node zum Ablauf von HTLCs hinzufügen muss. Mit anderen Worten, dieser Wert repräsentiert die erforderliche Lücke zwischen den Zeitsperren der eingehenden und ausgehenden HTLC zu diesem Knoten . Sobald eine HTLC-Zeitüberschreitung vorliegt, kann sie entweder erfüllt oder abgelaufen sein. Dies bedeutet, dass der Node darauf achten muss, diesen Zeitpunkt zu umgehen und sowohl die angebotenen als auch die empfangenen HTLCs zu erfüllen. Wenn der Knoten dies nicht rechtzeitig erfüllt, kann der Peer sein Geld zurückerhalten, indem er die Timeout-Transaktion ausgibt.
Die Zeitsperre kann bis zu 14 * 144 = 2016 betragen oder die erwartete Anzahl von Blöcken, die innerhalb von 14 Tagen abgebaut werden sollen. Im Allgemeinen ist das CLTV-Delta ein abwegen von:
Je höher Sie diesen Wert wählen, desto länger kann Ihr Knoten offline sein, ohne dass Sie aufsteigen, um Geld zu verlieren. Andere Nodes entscheiden sich jedoch möglicherweise dafür, Zahlungen nicht als Routing-Prozess über Sie weiterzuleiten, wenn die Einstellung der Kette technisch so lange dauern kann wie das CLTV-Delta.
Der Grund, warum im (Gossip Protocol update_channel (die 1 ml darstellt) verschiedene Werte angezeigt werden, liegt wahrscheinlich darin, dass Implementierungen unterschiedliche Standardwerte verwenden und die Standardeinstellungen mit verschiedenen Versionen geändert haben. Ich denke, es war 144 für eine der Implementierungen und es kam auf 6 oder 9. Eclair Mobile Wallet, das hauptsächlich private Kanäle erstellt, die Sie bei 1-ml-Benutzern nicht sehen 2016 da Mobiltelefone möglicherweise längere Ausfallzeiten haben
Ich hab allerdings auch die Information das der kleinste Wert 18 sein soll und nicht wie oben 6.
Momentan scheint ein gängiger Standard Wert 40 zu sein ich habe 144 gewählt weil das ca. 24h in Blockzeit bedeutet. Bei all den technischen Details von oben ist aber mein Hauptanliegen hier zu verstehen das die Uhr bzw. der Taktgeber für das Lightning Protokoll wieder die Blockzeit der Mainchain ist und hier noch mal auf Bitcoin ist Zeit verweisen. Für mich eine sehr erhellender Artikel.
Der MAX/MIN HTLC Size wert dient angeblich nur zur Unterstützung der Pfadfindung Hilfreich beim Mobiltelefonen. Es gibt auch noch einen unterschied zwischen Pfad finden und dem Routing selbst. Also wenn ein Pfad zwischen mehren Nodes gefunden wird heißt es noch nicht das auch eine Zahlung geroutet werden kann. Beim Rebalacing starte ich einen Versuch darauf näher einzugehen.
Rebalance:
Damit das überhaupt klappen kann braucht man mindestens 2 Kanäle einen mit genug Outbound und eine mit Genug Inbound. Bei einem Rebalance ist das ein Versuch eine Zahlung an sich selbst zu stellen. Und dadurch Lokales Gut haben aus einem Kanal zu schieben und auf einem anderen Lokalen Kanal zu empfangen. Optimal wäre natürlich ein Dreieck und ein Gebühr von 0 für diesen Vorgang. (Es gibt koordinierte Rebalacing Vorgänge in Gruppen die die Gebühren für eine weile senken alle beteiligen ihre Zahlungen durch führen und danach wieder heben) Aber meist fallen einfach gebühren dafür an ist eben auch ein Geschäft.
Hier habe ich versucht 10k Sat zu senden. Man wählt den Kanal der viel lokales Guthaben hat und den Kanal der Empfangen soll. Bei Schritt zwei wird eine Gebühr geschätzt und die Anzahl der Nodes. Das heißt es gibt mal einen Pfad das ist ein gutes Zeichen. Ich hab hier allerdings die Erfahrung gemacht das man mit der Schätzung nie hin kommt. Bei CLI Tools wie BOS bekommt man zumindest eine Fehlermeldung meist ist es zu wenig Gebühr oder die Route ist einfach nicht möglich weil auf den Nodes dazwischen nicht genügen Kapazität auf der richten Seite des Kanals liegt.
Die Schätzung mal 10 hilft schon mal das ein Versuch zum Routen überhaupt unternommen wird sonst bricht der Vorgang gleich ab. Hier wurden 1,5 Sat für den Vorgang vorgeschlagen was für 7 Hops ohne hin unrealistisch ist. Ich hab gleich 20 Sat als Maximum Gesetz. Das hört sich jetzt extrem an aber am Ende gelingt das Routing dann mit 3 Hops und 5,2Sat Gebühr ist doch voll Ok oder nicht ?
Warum die Schätzung und die echte Durchführung so stark von einander abweichen ist mir noch ein Rätsel. Ach ja und um so höher der Betrag desto schwieriger wird es mit mehr als 100K gelingt mir das sehr selten.
Liquidität ,Pool und Marktplätze:
Nun jetzt da ich euch schon Lange auf die Folter gespannt habe, die große Frage: Wie kommt man selbst oder jemand anders zu Liquidität. Meist ist man ja auf der suche nach Inbound also Teilnehmern die bereit sind einen Kanal zu öffnen. Hier lohnt es sich zu sagen das vom Autopilot abgeraten wird.
Lösung 1: Ausgeben
Du hast einen Kanal geöffnet und kannst eigentlich sofort beginnen sie auszugeben, d.h. So bekommt man automatisch inbound Liquidität. Hier kann man auch den „Trick“ verwenden eine Kanal zu einer Node einer Custodial Wallte zu öffnen wie „Wallet of Satoshi“ oder LNTXBOT. Eine Rechnung stellen und sich selbst auf der andere Seite zu bezahlen.
Lösung 2: Nach Kanälen fragen
Passiert ja auch hier im Forum. Hier kann es so weit gehen das man sich Gegenseite soweit Vertraut, das die eine Partei per KeySend 50% des Kanales pusht und die andere eine BTC TX sendet und somit die Rechnung begleicht. Ist die Schnellste Möglichkeit 50/50 herzustellen.
Lösung 3: Exchanges
Ja klingt verrückt mit LN Bitcoins Onchain Bitcoins kaufen. z.B. zigzag.io, fixedfloat.com
Lösung 4:LOOP and POOL
Loop ein Services von Lightning Labs, inverse submarine swaps um Satoshis off oder On-Chain zum nehmen. Der Vorteil, der Vorgang ist non-custodial, der Nachteil, teuer, es fallen Onchain, Service und Routing Gebühren an, da ist man schnell bei 50-60kSat.
Loop In – On chain BTC ins LN senden Outbound Liquidität.
Loop Out – In Remote Kanäle LN Liquidität schieben und On-Chain BTC erhalten. Damit mit kann man auch BTC abschöpfen ohne den Kanal zu schließen.
Pool auch ein Service von Lightning Labs ein non-custodial Markplatz.
Hier kann man entweder auf Eingehende Liquidität bieten [BID], Ausgehende Liquidität verkaufen [ASK].
Das besondere an den Marktplatz ist das es sich um sealed-bids handelt das heißt es gibt kein Oderbruch. Das einzige das man sieht ist die Vergangenheit ob Orders durch geführt wurden oder nicht. Wie ein Ebay Auktion nur sieht man eben nicht wie die anderen Gebote stehen auch die Gegenseite sieht nicht wie hoch geboten wird.
Es gibt jetzt zumindest auch schone eine GUI, über die CLI hat man noch mehr Einfluss auf gewisse Einstellungen. Weil das auf den ersten blick alles sehr verlockend klingt Beschreibe ich den Ablauf etwas genauer. Wie läuft das ganze nun ab, zu erst muss man eine Account eröffnen um die PoolWallet zu befüllen. Das ist hier wieder eine Multisig Adresse Zwischen dem Pool Service und der LND Wallet. Hier fallen schon mal On-Chain gebühren an.
Der Account hat ein Ablaufdatum Standard 2016 Blöcke. Nach Ablauf der Zeit muss man die Lebensdauer entweder verlängern oder ihn schließen. Hier fallen auch OnChain gebühren an.
Will man Liquidität Verkaufen muss man natürlich die Menge der geplante Kanalgrößen + OnChain Gebühren auf die Wallet senden. Um Einzukaufen zumindest die Prämie die man gewillt ist zu bezahlen + OnChain Gebühren.
Alle 10 Minuten gibt es eine Batch/Stapel der versucht Nachfrage und Angebot zu bedienen. Alle erfüllten Orders werden dann in einer einzigen Transaktion durch geführt sprich es können mit einer TX tausende Kanäle Gleichzeitig geöffnet werden. (Die TX muss allerdings in einem Block sein) Wer es genauer wissen will. Batch Execution
DESIRED INBOUND
Höhe der gewünschten Liquidität Es wird in Units gehandelt 1 Unit = 100.000 sat oder ein mehrfaches davon. (Info das GUI hat einen Bug wenn der Browser nicht auf Englisch ist beim parsen des Eingabefeldes und den Umgang mit . und , bug fix ist im master branch schon gemacht, am besten mit copy paste arbeiten oder CLI)
DESIRED OUTBOUND
Höhe der Liquidität die man Anbieten möchte es gilt analog obiges.
BID PREMIUM
Höher der sat die man bereits ist als Prämie zu zahlen
ASK PREMIUM
Höhe der sat die man als Prämie erhalten möchte
MINIMUM CHANNEL SIZE
Die Minimum Kapazität pro Kanal in den die Units zusammen gefasst werden.
So steurt man ob man eher mehr Kanäle haben möchte oder größeres Volumens
MAX BATCH FEE
Die maximal OnChain Kosten die der Batch Block haben soll
MIN NODE TIER
T1 ist jeder node der schon mal ein BOS Scoring hatte, T0 alles anderen.
Das Ganze Wird dann auf Ertrag pro Block umgerechnet und ergibt eine APR rate aliquot für die Mietdauer umgerechnet.
Channel Duration
Die Mietdauer von 2016 Blöcken also 2 Wochen ist ein Standard wert in der GUI kann der nicht verändert werden (zumindest bis jetzt)
sie bestimmt die Vertragsdauer, die der Hersteller/Maker (ASK Order) und der Abnehmer/Taker (Bid Order) eingeben, wenn sie vom Auktionator abgeglichen werden. Dies bedeutet, dass der Hersteller die angebotene Liquidität mindestens für die ausgewählte Anzahl von Blöcken bereitstellen muss. Der Hersteller darf den Kanal nicht vor Ablauf der vereinbarten Mietdauer schließen. Der Hersteller kann den Kanal nach Ablauf der Dauer schließen, ist jedoch nicht dazu verpflichtet. Wenn ein Kanal wirtschaftlich ist, können weitere Routing-Gebühren erhoben werden, wenn der Kanal offen bleibt.
LightningPool Info Channel Diese Telegram Channel sendet regelmäßig ausgeführte Orders.
Lösung 5: Bots und andere Dienste die noch kommen oder es schon gibt und man nichts weis.
@LightningLiquidityBot Auch ein Service um Seine Liquidität zu verkaufen der Bot handhabt die Zahlung mit KeySend.
Adaption und freie Gedanken meiner Seite:
Nun Abschließend ein paar Gedanken zum Thema Onboarding und Zugang. Weil man jetzt immer öfter hört. Es wird immer schwieriger Onchain TX günstig zu machen neue die hinzukommen können sich das nicht leisten usw.
Wenn man den 2nd Layer als Dienstleistung sieht und auch annimmt und ja, die kann auch zentraler organisiert sein, mal mit mehr oder weniger Vertrauen einher gehen, wird es immer Entitäten geben die ins Geschäft kommen wollen. Wie so soll es nicht interessant sein für jemand eine Kanal zu dir zu öffnen, genau so wie dir jetzt die Bank eben eine Kreditkarte anbietet. Und als Gegenleistung eben die Onchain Fee hat.
Zusätzlich noch das Interesse den Kanal lange zu betreiben um nicht zu früh wieder Schließkosten zu haben. Und so bekommt man die Möglichkeit LND Zahlungen anzunehmen ohne hohe Initialisierungsaufwand. Und Das ist nur ein Beispiel ich, ich kenne auch schon jemanden der bietet Onboarding mit Fiat DCA an.
Die Power der Dezentralisiertet liegt nicht darin das unbedingt jedes Individuum dezentral agieren muss sondern das es eine Gegenkraft zu Zentralen Einheiten gibt (was bis jetzt undenkbar war) Und Individuen sich auf ein faires und transparenteres monetäre System verlassen können, egal welche granuläre Einheiten dann drauf abgebildet oder verschoben werden.
Es liegt in der Natur der Sache das Early adopters eine Vorteil haben in dem sie Risiken eingehen und das gilt ja nicht nur für Bitcoin. Das verhält sich meiner Ansicht nach auch proportional um so früher desto höher das Risiko. Und so ehrlich muss man sein, eine Portion Glück gehört manchmal mal auch dazu.
Das heißt um vielleicht mal eine andre Perspektive darzulegen. Zu spät? Wofür ? Ja um dem nächsten satoshi Stack oder 100x pump Nachzulaufen möglicherweise, um Sich mit dem Space zu befassen, zu lernen zu experimentieren ? Bei weitem nicht. Ich sehe es als Investment, meine Zeit, das Lernen und das Verstehen und Benutzen der verschiedenen Wehrzeuge. Irgendwie oder wann wird dieses Wissen von Wert sein der vielleicht auch in satoshi beglichen wird.
Ein Chinesisches Sprichwort Lautet:
„mögest du in interessanten Zeiten leben!“
und das tun wir, definitiv.
Quellen:
Welcome to our Lightning Wiki:zap: - ION Lightning Network Wiki
LND Overview and Developer Guide
Till it’s lightning-fast — Uncover the Lightning Network Transactions | by Y. | Medium
Lightning Node Management - Lightning Node Management
1ML - Lightning Network Search and Analysis Engine - Bitcoin mainnet
Mit BTCPay Lightning Zahlungen akzeptieren
Tip me;-)
LNURL1DP68GURN8GHJ7MRWW3UXYMM59E3XJEMNW4HZU7RE0GHKCMN4WFKZ7URP0YLH2UM9WFHXZMT984D82MN00QY60VNH