lightning-dissector: A Wireshark Plugin for Lightning Network Protocol

Nayuta, a team currently developing a new Lightning Network implementation called ptarmigan, announced the release of a wireshark plugin for the Lightning Network (BOLT) protocol. The plugin is hosted here.

It’s alpha version, but it can decode some BOLT message. Currently, this software works for Nayuta’s implementation(ptarmigan) and Éclair. When ptarmigan is compiled with some option, it write out key information file. This Wireshark plug-in decode packet using that file. When you use Éclair, this software parse log file.

Improving payment UX with low-latency route probing

Pending payments are a common UX problem for LN that users often complain about. While the cause of this problem is not easily unraveled, there have been several issues involving stuck intermediate nodes awaiting revocation and recipients who can’t give timely preimage replies.

Fabrice Drouin proposed a change to address the issue using a faster “proceed/try another route” answer using a probe with a short timeout requirement. The system sends the blank probe request prior to sending the actual payment, via the same route.

Why double spend attacks on Lightning are not possible

Margherita Favaretto, a student working on remediation protocol for Lightning Network double-spend attacks asked for feedback for a proposed solution to double spend attacks using a “trusted remediation” gossip protocol.

ZmnSCPxj pointed out that double spend attacks are not possible on the Lightning Network unless both parties involved in the channel agree to it, which is not likely, first because the man at the other end of the channel will lose money. Secondly even if the other end of the channel is irrational enough to help the other guy double spend, they will still ask for an invoice and give the money using “existing invoice-payment mechanisms.” ZmnSCPxj added:

If the problem you are trying to solve, is the inadvertent publication of revoked commitment transactions, then the correct solution is not to have revocable transactions in the first place, i.e. eltoo. While it can be argued that it would take time for needed features of eltoo to appear on the blockchain layer (SIGHASH_NOINPUT_UNSAFE), it would also take time to implement “trusted remediation”, by which time the problem could be solved by switching over to eltoo.