Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Track armed static address HTLCs after aborted swaps

Aperta
  • Qualcosa non va?
#1,171 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 7 giorni

@hieblmi ci sta già lavorando.

Dal 9/7/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

Static address loop-ins can leave the client with a durable safety obligation once it signs and hands HTLC transaction signatures to the server. Even if the client later aborts the swap, the server may still be able to publish one of those HTLC transactions until the selected deposit set is otherwise spent.

We should add a dedicated HTLC transaction monitor for aborted/static loop-in swaps where the client handed out, or may have handed out, HTLC signatures.

Expected behavior:

  • Persist/register a swap as "armed" before or when HTLC signatures are handed to the server. This should cover ambiguous handoff failures where the server may have received signatures but the client did not receive a successful response.
  • On startup, restore all armed HTLC monitors.
  • For each armed swap, monitor the signed HTLC transaction/script for publication.
  • If the HTLC confirms, keep the swap/deposits on the timeout-sweep path until the timeout path is swept.
  • If any selected deposit is spent before the HTLC transaction is observed, stop the monitor for that armed HTLC because the all-input signed HTLC transaction can no longer be published.
  • Disarm the monitor once the swap reaches a final safe state, such as successful completion, confirmed timeout sweep, or provable invalidation by deposit spend.

This should remove the need for each abort path to reason separately about whether the server still holds usable HTLC signatures.

Lingua principale
Go
Stelle
593
Fork
138
Merge medio
4g 9h
PR unite (30g)
14

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di lightninglabs/loop

Tutte le issue di lightninglabs/loop

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.