Hey Everyone, I have been fortunate to be invited to the BOLT1.1 spec meeting in November in Australia. There is an ongoing open agenda out with the topics that one would expect to be be discussed there like:
- Dual funded channels
- Splicing
- autopilot
- AMP
- watchtowers
and a few more technical points. If anyone here has some features missing in the lightning network it is now the time to state them and I can try to put them on the list for BOLT1.1. I will probably focus most on splicing and autopilot features but I am looking for your input.
This is great @renepickhardt ! It looks like you've listed the main ones there already.
You can add my vote to getting AMP live. I really enjoy playing with the emulator on https://www.robtex.com/lnemulator.html. It really shows what may be possible.
My biggest request:
- Multi-channel on-chain transactions (batching). I would like to be able to open more than one channel with an on-chain transaction. Each channel now is funded with a transaction with N inputs, a change output, and a channel output script. With the work going on in things such as bip 174 I think we can do much better. I would like to be able to open a large batch of channels and have the counterparties exchange partially signed transactions and when fully signed, transmit the channel opens to the blockchain. The risk is when a connecting node is non-responsive, then we need to re-start the signing process, but I think this can be solved through a protocol. It's pretty cool to open channels at 1 sat per byte, but it would be even cooler to open 10 channels at 1 sat per byte.
I can also think of a few things which could be nice to have.
- Add a protocol for channel state query. This should be optional to enable (by channel?) but would allow query of a node for channel information beyond the total capacity, such as the current balance on each node. I think this is important for future channel state balance dynamics and would prevent inadvertent channel balancing causing other nodes to become unbalanced.
- Add a channel reserve. There could be a setting to allow excess capacity on some node channels to be used to rebalance nodes on the network. However, a channel may want to keep some capacity for own use only. For example, if I have a channel with 1 BTC capacity, I can release 0.5 BTC for forwarding, but reserve 0.5 BTC for the case when my node is either the origin or destination.
Those are off the top of my head. If I come up with more ideas, I'll add another post.