Vor kurzem bekam ich einen kleinen Schreck, als ich meine Kanäle in Thunderhub betrachtete. Ich musste feststellen, dass bei einigen die Gesamtsumme des Kanals nicht mehr stimmte. Kanäle die vorher 1M Satoshis hatten, besaßen auf einmal eine lokalen Betrag(Local Balance) von 0.5M Sats und einen entfernen Betrag (Remote Balance) von 0.1M Sats, ein 2M Kanal hatte auf einmal nur noch 1.1M Geldwerte, ein Moment Verwunderung und seichte Panik setzte ein.

Was ist ein Kanal?

Denn im Grunde sollte genau das mit LN überhaupt nicht möglich sein, sprich die Verkleinerung eines Kanals. Da, die Größe des Kanals beim Erstellen(channelopen) festgelegt wird. Dabei werden Fees und Rücklagen für das Schließen des Kanals subtrahiert. Das Resultat ist dann die unabänderliche Größe eben jener Verbindung, die man auch als eine Art Rohr zum nächsten Knoten verstehen kann. Stellen wir uns also dieses Rohr vor, in dem sich Wasser befindet und in der Mitte eine Art Membran die nach Links oder Rechts verschoben wird, wenn Wasser (Satoshis) reinkommt oder rausgeht. Ist die Membran ganz Links, haben wir 100% Local Balance, das heißt, wir können keine Zahlungen mehr empfangen, denn weiter als an die Kante des Rohrs geht die Membran nunmal nicht. Ist die Membran ganz Rechts haben wir 100% remote balance (sämtliche Zahlungsmittel liegen auf der Seite der Partnernode), wir können also keine Zahlungen mehr senden. Für Routing-Nodes interessant, ist das viel beschworene ⁵⁰⁄₅₀ Verhältnis, sodass Payments in beide Richtungen möglich sind. Da die Menge des Wassers, anhand des Durchmessers und der Länge des Rohrs bestimmt werden kann, die in ebendiesem fließt, kommen wir zu dem Schluss, dass das Rohr insgesamt ~2M Satoshis hat. Dies ist über die Lebensdauer des Kanals, sprich solange dieser nicht geschlossen wird, dessen unveränderliche Größe.

Dieses Prinzip verstanden zu haben, beruhigte meine Stimmung direkt. Dennoch blieb die Frage: Aber was ist passiert? Daher begann ich nachzuforschen, was es mit dem Ganzen auf sich hat. Schnell wurde ich, durch die Hilfe von Bekannten in einem Chat darauf hingewiesen, dass es sich um “Pending HTLCs” handeln könnte. Dies war tatsächlich der Fall.

Was sind HTLCs?

HTLC steht für Hash-Time-Lock-Contract und ist ein Smart Contract. Dieser wird im Bitcoin respektive Lightning Netzwerk zur Zahlung von Geldwerten genutzt und besteht aus zwei Komponenten:
* Hash-Lock
* Time-Lock
Vereinfacht gesagt werden die Sats nur ausgezahlt wenn die Gegenseite das richtige Passwort eingibt (Hash-Lock) oder die Werte gehen an den Sender zurück, falls dies nicht innerhalb eines gewissen Zeitraums (Time-Lock) passiert. Solange keine der beiden Bedingungen, richtiges Passwort eingegeben oder Zeit abgelaufen, erfüllt sind, befinden sich die Werte in einem schwebenden (pending) Zustand. Dies führt dazu, dass Thunderhub die möglichen Sats aus dem Kanal nimmt, da sie zum aktuellen Zeitpunkt nicht für eine Zahlung oder Routing verwendet werden können.

Schwebende HTLCs in Thunderhub

Um herauszufinden ob und wie viele Sats genau im schwebenden Zustand sind, ist es notwendig auf den entsprechenden Kanal zu gehen und dort unter Node Public Key und Transaction Id, nach dem Eintrag Pending HTLCS zu suchen:

Pending HTLCS
Total Amount 1
Total Tokens 369992
Outgoing Tokens 369992
Outgoing Amount 1

Daraus lässt sich ableiten, es gibt eine HTLC mit einer Größe von ca. 370.000 Satoshis. Als nächstes ist natürlich spannend, was für eine Transaktion das ist und ob sich vielleicht auch herausfinden lässt, wohin sie ging oder wann der wartende Zustand beendet wird.

Für diesen Zweck habe ich mich dem Kommandozeilen-Werkzeug von LND bedient: lncli. Zum einen lässt sich damit herausfinden, wie viele Sats tatsächlich gerade in einem Wartezustand sind, wir erhalten also eine Gesamtübersicht zum anderen kann man damit weitere Informationen einsehen.

$ lncli channelbalance
...
{    "unsettled_local_balance": {
        "sat": "0",
        "msat": "0"
    },

    "unsettled_remote_balance": {
        "sat": "2402639",
        "msat": "2402639987"
    },
}
...

Der Befehl gibt mehrere Informationen aus, die obere Ausgabe wurde auf unser Thema beschränkt. Unter den Feldern: unsettled_local_balance und unsettled_remote_balance, können wir die Menge des noch offenen Token einsehen. In meinem Fall sind es ungefähr 2.4M. Wir sehen außerdem, dass es HTLCs gibt die lokal oder remote sein können, also an uns gehen oder von uns versendet werden. In meinem Fall wurden alle HTLCs gesendet.

Wie wir wissen, verteilen sich die oben genannten 2.4M Sats auf verschiedene Kanäle. Mit dem Befehl listchannels lassen sich weitere Informationen erlangen. Da wir die Daten jeweils auf entsprechende Nodes beschränken wollen, arbeite ich mit der extra Option “peer”. Diese Option erwartet den öffentlichen Schlüssel der Node oder einfach dem: Node Key. In diesem Fall nehme ich den Key von dem System Tatooine:

$ lncli listchannels --peer 03011e480a671ac71dbc3fc3e8fe0db32bb9a10cc4d824663e09557d446ef80679

            "capacity": "2000000",
            "local_balance": "1511698",
            "remote_balance": "116967",
    	    ...
            "unsettled_balance": "369992",
            ...
	    "pending_htlcs": [
                {
                    "incoming": false,
                    "amount": "369992",
                    "hash_lock": "181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b",
                    "expiration_height": 696472,
                    "htlc_index": "5417",
                    "forwarding_channel": "0",
                    "forwarding_htlc_index": "0"
                }
            ]

Wie bereits beschrieben, ist der obere Kanal 2M Sats groß. Dies erkennt man ebenfalls an dem Feld “capacity”. Rechnet man jetzt jedoch die beiden Felder “local_balance” und “remote_balance” zusammen, kommt man lediglich auf 1.628.665 Sats. Es fehlen also über 300.000 unserer geliebten Währung! Der Wert in “unsettled_balance” scheint ganz die Menge zu sein, rechnen wir sie einmal zusammen: 1.628.665 + 369.992 = 1.998.657. Dies sind nun fast unsere 2M Sats. Der Rest wird vorgehalten für die Schließung des Kanals bzw. wurde bereits für die Eröffnung abgezogen. Schauen wir etwas weiter. In der Kategorie “pending_htlcs” gibt es tatsächlich einen Eintrag, dieser hat mehrere interessante Felder. Gehen wir einige durch:

• incoming - handelt es sich um ein htlc das zu uns geschickt worden ist, in dem Fall haben wir versendet also ist das Feld: False
• amount - ist ganz klar die Menge an Satoshis die hier auf den Weg gebracht wurden
• hash_lock - ist der hash mit dem das Schloß verschlossen worden ist
• expiration_height - dies ist die Laufzeit

Soweit so spannend. Mit den vorhandenen Informationen lässt sich jetzt also auch sagen, wie lange es maximal dauert, bis die Satoshis wieder freigegeben werden und der Kanal zu seiner vollen stärke, wenn auch unterschiedlich auf der lokalen und der Seite der Partner-Node, zurückkommen wird. Zum Zeitpunkt der Abfrage mit lncli war der Block 696472 im Bitcoin Netzwerk noch nicht gefunden. Bei einer angenommenen Dauer von 10m pro Block und der aktuellen Blockzeit, kam ich auf ca. 720m also 12h Wartezeit, falls der Hash nicht an den Adressaten weitergegeben werden würde.

Nach Ablauf der Zeit, kamen alle Satohis zurück und eine erneute Ausgabe des Kanals mit lncli sah dann so aus:

	    "capacity": "2000000",
            "local_balance": "1882272",
            "remote_balance": "116967",
            ...
	    "unsettled_balance": "0",
            ...
            "pending_htlcs": [
            ],

Wir sehen, dass die lokale und partnerbalance zwar nicht gut ausgeglichen aber Nahe an unseren 2M Sats ist, des weiteren ist die “unsettled_balance” gleich null und wir haben keinen Eintrag in “pending_htlcs”.

Ende

Ich hoffe euch hat der Beitrag gefallen und ihr habt einen besseren Einblick in Bitcoin und Lightning erhalten.