Hi guys, I was reading some stuff about the LN security flaw that everyone is talking about (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022032.html) but found it quite technical and difficult to understand.
While I take some time to read all relevant documentation (will list it below), is there anyone patient enough to explain in very simple terms what happened, and what the security issue is about? I couldn't find good articles around, if you have interesting material please post it below!
Explained simply:
Imagine papercliping garbage to a legal bill, but then the whole thing gets thrown out because of it. So a new bill is proposed but the attacker paperclipped more garbage to it and it doesn't pass again. Eventually it is no longer possible to submit the bill and attackers win.
In this case the bill is your in flight payment that you're trying to redeem on chain before the timeout.
reply
Thank you
reply
Nice explanation.
reply
deleted by author
reply
deleted by author
reply
Storm in tea cup?
reply
Hardly. I think the people who are trying to downplay this are engaging in a bit of copium, to be honest. There are many issues with the lightning network that people are keen to ignore and not discuss, I think it's actually quite a serious issue (the lack of discussion/willingness to engage in anything remotely bordering on self-criticism or critique in an honest way) in the bitcoin community that we need to talk about more often.
That said, aside from the aforementioned other issues (which there are plenty of; just outside of the scope of this particular post/thread), one of the more well-known bitcoin core/lightning network devs (who I understand is someone well-regarded and respected within that sphere of people) has decided to no longer be doing dev work for lightning because of this. I think that's worrying enough to merit concern.
reply
deleted by author
reply
Latest Rabbit Hole Recap episode addressed it.
There's a stupid mempool thing that if you have transactions X, Y and Z such that X conflicts with Y and Y conflicts with Z, then X could be ousted by Z even if they don't conflict. It goes like this: Y replaces X, then X is thrown out of mempool, then Z can replace Y.
In very specific circumstances this can be used maliciously to block somebody from posting a transaction. LN assumes that everybody is able to post a transaction within a certain time from the moment they desire to do so, but this assumption is invalidated by the attack.
In the specific case of LN, LN nodes can avoid the issue by scanning the mempool. But IMHO the mempool behaviour is the thing to fix.
reply
As my father used to say: 'Sometimes what seems like a tidal wave is just a fart in a bathtub'.
reply