Lightning Network is currently starting to build up, it has recently passed 2 Million dollars in capacity, but its still far from being perfect, there’s currently very little ways of assessing how much fees a payer will pay, although its currently mostly a negligible value, it may not be in the future.

A use case of the Payee paying the fees of the transaction is used in almost every exchange platform, because on the main blockchain you can assess the current average fees and even figure out how much, on average, it will take your payment to be accepted by the network if you sent it with a definite amount, this currently does not exist in Lightning.

If the payee pays the fees the payer can route the payment towards complicit nodes that charge way higher fees than average.

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.

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