Feed for category: bolt
Unspecified Bolt Protocol Extensions

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.

A suggestion to hint for channel capacity in BOLT 11 invoices
In making payments through lightning channels, space is a factor that must be considered. However, one cannot tell how much capacity is available on which channel. Rusty Russell is proposing a change to the system that automatically attaches an ‘r’ field to any channel that has sufficient capacity to receive a certain amount. Some members of the community however think this may be risky because an unauthorized user can tell how much capacity one has and use it to attack.
Lightning Improvement Protocols
There has been a recent discussion on the Lightning mailing list about the idea of organizing Lightning specifications and naming them Lightning Improvement Protocols LIPs. The idea comes from Bitcoin’s own Bitcoin Improvement Protocol where all the past, present and future work on Bitcoin is thoroughly explained.
Bolt-12 Proposal: Payment Protocol for Lightning Payments

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