Often times nodes need to communicate with each other what their implementation is, looking for specific features that are only in select implementations, the desired feature is a question of node implementation.

A concept of Unspecified protocol extensions has been proposed, they are unspecified as they are not part of the BOLT specifications, each extension must have a set of random 20-byte identifier with type bigger than a certain number. Using the concept of current extension, any extensions that are unidentified by a node will not be recognized, while if the node’s implementation identifies this unspecified extension, both nodes can continue communications knowing that they have the same set of extra features.

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.

Two weeks ago, Corné Plooy published a draft for a promising protocol improvement to Bolt-11 called Bolt-12: Payment Protocol For Lightning.

I was thinking of how to use Lightning for various types of payments, and I think it’s currently fine for customer/(web)shop type interactions, but it seems a bit inconvenient for other use cases, e.g. salary payments or direct pay-out of cryptocurrency bought on an exchange. I came up with an idea that addresses some of these issues and more (e.g. payee anonymity) by having a direct line of communication between payer and payee instead of BOLT11-style interaction