Close Channels hängt wegen zu geringer Gebühr

Fragen Technik
1

Hallo, kann mir bitte jemand helfen?
Ich habe einen Lightning Kanal geschlossen, aber die Transaktion wird wegen zu geringer Gebühr nicht verarbeitet.
Ich habe diese Doku gelesen:

aber mir ist nicht klar wie ich da die richtige Transaktion und den richtigen Output Index finde.

So sieht das bei mir aus:

$ umbrel/scripts/app compose lightning exec lnd lncli pendingchannels
{
    "total_limbo_balance":  "496530",
    "pending_open_channels":  [],
    "pending_closing_channels":  [],
    "pending_force_closing_channels":  [],
    "waiting_close_channels":  [
        {
            "channel":  {
                "remote_node_pub":  "0242a4ae0c5bef18048fbecf995094b74bfb0f7391418d71ed394784373f41e4f3",
                "channel_point":  "e43f9ee90dcdf993a9899c7cf0b8a2acc8369837acb288efbe37b31f7c70c858:1",
                "capacity":  "500000",
                "local_balance":  "496530",
                "remote_balance":  "0",
                "local_chan_reserve_sat":  "5000",
                "remote_chan_reserve_sat":  "5000",
                "initiator":  "INITIATOR_LOCAL",
                "commitment_type":  "ANCHORS",
                "num_forwarding_packages":  "0",
                "chan_status_flags":  "ChanStatusBorked|ChanStatusCommitBroadcasted|ChanStatusLocalCloseInitiator",
                "private":  false,
                "memo":  ""
            },
            "limbo_balance":  "496530",
            "commitments":  {
                "local_txid":  "643edc422caa007a9a59c3ee4c087390ccae7d74bd39e338747cd3eb47af952c",
                "remote_txid":  "3e05557e155160ccf7033addab55d932797cfc1e7d5a11630d819d431a40c57f",
                "remote_pending_txid":  "",
                "local_commit_fee_sat":  "2810",
                "remote_commit_fee_sat":  "2810",
                "remote_pending_commit_fee_sat":  "0"
            },
            "closing_txid":  "643edc422caa007a9a59c3ee4c087390ccae7d74bd39e338747cd3eb47af952c"
        }
    ]
}
2

Mit technischen Details kann ich nicht dienen. Aber ich hatte das auch mal, in der Phoenix-App.

Ich hab dann den Support angemailt - und wie von Zauberhand haben die dann die seit 3 Wochen hängende Kanalschließung durchgeführt…

3

Vorweg: Ich habe selbst noch kein CPFP benutzt, also ist das hier mit Vorsicht zu genießen. Technisch bin ich allerdings im Prinzip ganz gut im Thema und denke, es verstanden zu haben.

Hier sieht man deine Closing TX im mempool: mempool - Bitcoin Explorer

→ Es ist erkennbar, dass es neben der Fee zwei Outputs gibt und der 2. (und Größere, mit 496530 sats) gehört dir - das ist klar, weil:

Der output index wird ab 0 (und nicht ab 1) gezählt, also musst du den 2. Output Index mit „1“ angeben. Informatiker fangen meistens bei 0 an zu zählen, das kann verwirrend sein - einfach hinnehmen.
Der Befehl lncli wallet bumpfee kann jetzt mit verschiedenen Parametern verwendet werden, das wird in der von dir verlinkten Doku ja auch erklärt. Allerdings würde ich statt sat_per_byte lieber sat_per_vbyte nehmen. Laut aktuellen mempool-Daten würdest du mit einer Feerate von 28 sats/vB in den nächsten Block kommen. Prüf das selbst neu, bevor du den Befehl im Terminal absetzt.
ACHTUNG: Die Gebühr muss glaube ich noch höher sein, weil du bei CPFP eine weitere Transaktion erzeugst und die GESAMTSUMME (für die Closing TX und die neue) muss so hoch sein, dass sie für Miner attraktiv genug ist, beide TXs in einen Block einzubauen!

Der Befehl, um deine Closing TX per CPFP zu beschleunigen, wäre dann z.B. (Gebühr unklar):
lncli wallet bumpfee --sat_per_vbyte 40 643edc422caa007a9a59c3ee4c087390ccae7d74bd39e338747cd3eb47af952c:1

Viel Erfolg!

4

Danke für die Erklärung. Werde sie beim nächsten Mal sicher brauchen. Seit 50 Minuten ist die Transkation jetzt nämlich seltsamerweise mit der ursprünglichen Gebühr bestätigt worden, nachdem sie über 2 Wochen im mempool stand.
Allerdings habe ich meine Coins nun immer noch nicht zurück, jetzt steht der Kanal auf „pending_force_closing_channels“. Hoffentlich nicht wieder mit zu geringer Gebühr.

$ umbrel/scripts/app compose lightning exec lnd lncli pendingchannels
{
    "total_limbo_balance":  "496860",
    "pending_open_channels":  [],
    "pending_closing_channels":  [],
    "pending_force_closing_channels":  [
        {
            "channel":  {
                "remote_node_pub":  "0242a4ae0c5bef18048fbecf995094b74bfb0f7391418d71ed394784373f41e4f3",
                "channel_point":  "e43f9ee90dcdf993a9899c7cf0b8a2acc8369837acb288efbe37b31f7c70c858:1",
                "capacity":  "500000",
                "local_balance":  "496530",
                "remote_balance":  "0",
                "local_chan_reserve_sat":  "0",
                "remote_chan_reserve_sat":  "0",
                "initiator":  "INITIATOR_LOCAL",
                "commitment_type":  "ANCHORS",
                "num_forwarding_packages":  "0",
                "chan_status_flags":  "",
                "private":  false,
                "memo":  ""
            },
            "closing_txid":  "643edc422caa007a9a59c3ee4c087390ccae7d74bd39e338747cd3eb47af952c",
            "limbo_balance":  "496860",
            "maturity_height":  829962,
            "blocks_til_maturity":  135,
            "recovered_balance":  "0",
            "pending_htlcs":  [],
            "anchor":  "LIMBO"
        }
    ],
    "waiting_close_channels":  []
}
5

Das war Zufall, denn die Gebühr von 16,3 sats/vB hat jetzt doch gereicht (Gebühren sind aktuell rückläufig).

Wieso dein Client (LND) jetzt was mit Forceclose anzeigt, verstehe ich auch nicht. Ich würde mal versuchen, LND neuzustarten. Wie soll man einen Channel forceclosen, der jetzt de facto (cooperative) geclosed ist?

Edit: Oder das Ganze war ein Forceclose und du musst jetzt noch bis Block 829962 abwarten bis das Guthaben zur Verfügung steht? Ich weiß leider nicht genau, wie man in den TX Daten (zB bei mempool) erkennt, ob es sich um einen Forceclose oder einen kooperativen Close handelt.

6

Vielleicht hat der Force Close was damit zu tun das der Kanal nie aktiv war. Als ich den damals zu Coingate eröffnet habe hat das auch ewig gedauert wegen zu geringer Gebühr. Als das dann endlich durchging wurde der Kanal zwar als offen, aber inaktiv angezeigt. Deswegen hab ich ihn jetzt auch wieder geschlossen, denn was nützt mir ein inaktiver Kanal. Hat bestimmt was mit der Gegenseite zu tun.

7

Soweit ich weiß, wird ein Kanal inaktiv gesetzt, wenn der Kanal aus welchem Grund auch immer nicht mehr fürs Routen benutzt werden soll. Da dein Kanal nicht „private“ war (was du dir für die Zukunft überlegen solltest, denn ich schätze du betreibst keine Routing-Node), könnte die Gegenstelle das aus verschiedenen Gründen getan haben - zB bist du vielleicht ausschließlich im Tor-Netzwerk und die Verbindung war zu unzuverlässig.

Weiß hier jemand, ob man selbst den Kanal dann trotzdem noch zum Zahlen und Zahlung empfangen benutzen kann? Die Gegenstelle wird über den entsprechenden Kanal natürlich nichts mehr routen, aber explizit über den Kanal als first oder last hop versuchte Zahlungen sollten weiterhin gehen, oder nicht?

Wie auch immer, Coingate ist eh kein guter Channel-Partner. LNBIG und nicehash funktionieren deutlich besser.

8

Hatte exakt das gleiche Problem. Leider hab ich bis heute auch nicht verstanden was da genau schief gelaufen ist. :confused:

9

Wo genau hat es denn bei dir geklemmt?
Ich kann mir das bei mir schon vorstellen, kann aber nur spekulieren. Das eröffnen des Kanals zu Coingate dauerte damals sehr lang wegen zu niedriger Gebühr. Als die Open-Transaktion dann durchging war der Kanal inaktiv. Möglicherweise hat Coingate den aufgrund der langen vergangenen Zeit nicht bestätigt, deshalb inaktiv (Spekulation). Jetzt beim Close vermutlich wieder das gleiche, Coingate hat den Close nicht bestätigt, deshalb nun der Forced Close. Wenn ich das richtig verstanden habe müsste der Forced Close dann morgen abgeschlossen sein und ich meine Coins wieder in der Wallet haben.

10

So ist es. Nach 2 Wochen (Standard mempoolexpiry) verwirft die Gegenseite die Channel Opening Tx aus ihrem Mempool. Wenn der Channel dann nach 2 Wochen (für dich) confirmed wird und aktiv geht, ist er nur einseitig bestätigt und damit defekt. Channel muss dann force closed werden.

Wenn du einen force close einleitest, hast du eine Timelock (Zeitsperre). Das siehst du unter lncli pendingchannels. Die blocks_til_maturity zeigt dir an, wieviele Blocks noch zu warten sind, bevor die Funds frei werden und in die Wallet zurücktransferiert werden. Aus dem obigen Ausschnitt also:

"blocks_til_maturity":  135
3 „Gefällt mir“
11

Ist das wirklich so? Klingt für mich nach etwas, was man auf LN-Protokollebene fixen könnte. Was on-chain confirmed ist, ist unumstößlich. Der Client der Gegenstelle müsste das also dann auch akzeptieren, hängt nur ggf. auf dem alten Stand (unbestätigte opening TX, weil sie aus lokalem mempool entfernt wurde).

12

Afaik ist das Standardeinstellung in bitcoin.conf (siehe Bitcoin Core Config Generator unter Sektion „Bitcoin Core“):

# Do not keep transactions in the mempool longer than <n> hours.
mempoolexpiry=336

Und da die meisten Nodes mit Defaultwerten arbeiten, werden diese Txs in 336 / 24 = 14 Tagen verworfen, sofern die Lightning Implementation die Tx nicht rebroadcastet. Aber ja, dieses Verhalten könnte sicherlich geändert werden, sofern alle Implementationen mitmachen.

13

Dass Clients unbestätige Transaktionen nur eine bestimmte Zeit (was auch immer für ein default-Wert) im mempool behalten, meinte ich gar nicht. Das ist klar und ist nichts, was man „fixen“ kann.

Aber wenn eine TX lokal aus dem mempool geflogen ist, dann aber doch in die Chain kommt (weil irgendein Miner es eben nicht verworfen hat), dann kommt die Info über diese TX ja doch bei allen an. Und dann sollte der Kanal auch funktionieren.

14

So, hat nun alles funktioniert. Nach dieser Maturity Zeit waren die Coins sofort wieder in meiner Wallet und ich konnte sie zurück an meine Bitbox überweisen. Aktuell sind die Gebühren ja sehr niedrig.

1 „Gefällt mir“
15

Habe ein ähnliches Problem nur noch bissel komplizierter.

Es hat eine andere Node ein Kanal zu mir geöffnet
Alle Sats auf meine Seite gerebalanced den Kanal mit viel zu wenig sats/vbyte geschlossen
Es war ein mutual close der aber mit 6sat/vbyte nie durchgehen wird. Die andere Node ist jetzt Offline.