pull down to refresh

Discussion: Time to be careful on the Lightning Network?
132 sats \ 9 comments \ @SimpleStacker 15 Nov 2022 bitcoin
I remember reading an old post about lighting network double spends during periods of high layer 1 congestion... which we happen to be in.
I don't think I can explain all the details very well, but it involves submitting channel closing transactions that correspond to earlier states of the lightning network. Normally an honest node like a watchtower would dispute the transaction but during high congestion it's possible that the disputing transaction doesn't get processed in time.
Thoughts? Is this something to be worried about? And could someone ELI5 how "closing channels corresponding to earlier sates" and also "disputing transactions" works?
write
preview
related posts
321 sats \ 0 replies \ @TonyGiorgio 15 Nov 2022
Its something that is still very well a concern, anchor outputs or not
In this scenario though, fees didn't really go up too much. There's a pretty low floor where low valued transactions can still get in. If we get into scenarios where everyone is paying a lot for fees then its more of a concern for a mass exit attack.
However, if an attacker wanted to, now would be a good time for them to continue to push up the mempool even more. An attacker can wait for high fees to occur naturally or do it themselves.
reply
224 sats \ 0 replies \ @LaserStack 15 Nov 2022
It's not really something to be worried about. Your node will automatically broadcast the dispute tx, and it has the force-close delay's time (usually 1 day) to get confirmed. And your node can fee-bump it with anchor outputs. Also, if you dispute a fraudulent force-close successfully, you'll get all the funds in the channel as compensation. This also discourages attempted fraud.
reply
31 sats \ 6 replies \ @nerd2ninja 15 Nov 2022
Set your force close wait time to compensate for this. 2 weeks, a month if need be.
reply
50 sats \ 5 replies \ @ares 3 May 2023
How to set using lnd? Give me and example of how to set this in lnd.conf ?
reply
0 sats \ 3 replies \ @nerd2ninja 3 May 2023
Imma be honest with you, I had to hit up my support group. We got a Bitcoin technical support group here: https://discord.gg/bitcoin-discord-782749290219962370
reply
0 sats \ 2 replies \ @ares 3 May 2023
deleted by author
reply
0 sats \ 1 reply \ @nerd2ninja 3 May 2023
Hmmm I accepted my own invite and it worked. Try this one: https://discord.com/invite/K5H25KZHke
reply
0 sats \ 0 replies \ @ares 3 May 2023
Just joined. Have to wait 10 minutes till I can post messages. What is you Discord name? nerd2ninja?
reply
10 sats \ 0 replies \ @nerd2ninja 3 May 2023
; 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
^lnd.conf
or --remote_csv_delay <value> as part of channel opening args
reply