Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
BOLT2: Increase Bitcoin max chan size to 2^28-1 (~$10K) #579
Increase Bitcoin max Lightning Network channel size to 2^28-1 (approximately USD$10,551 right now) rather than the previous 2^24-1 (approximately USD$659 right now). This is long overdue (see next paragraph for why). The wording change is to replace "four most significant bytes" with "seven most significant nibbles" for amount_msat.
The reason is that many transactions such as paying a phone bill or purchasing an item (or even paying rent) will exceed the current maximum or come close to it, and in most cases exhaust the channels very quickly, often in approximately one or two Lightning transactions, thus causing about as many Bitcoin main chain transactions as there were LN transactions, erasing the purpose for LN in the first place, and preventing us from stress testing the high multiple uses of channels! It's time we increase the maximums. The only way we can stress test the network is if we put real amounts in place and use it as intended. It's best to do this while LN is still medium-sized rather than when it grows to be very big, since any bugs or system dynamics failures then would cause worse problems, especially since in the future we'll have the identical problem to now anyway (i.e., sooner is better, now).
I have run into my channels being exhausted after only a few uses for this precise reason of insufficient channel amount due to the maximum many times already.
In terms of timing:
For both LND and C-Lightning, regression tests would need to be updated. In addition, a more thorough understanding of defaults and graceful failures should be considered for both implementations. If I'm not mistaken, that can be done outside the scope of this maximum change in BOLT-0002, since those can be handled in software, and the standard merely suggests the failure modes which don't lose funds; someone correct me if I am wrong.
It is long past time that we fix this somehow, and I think it's a simple fix.
Then looking to the future, a further roadmap for increasing the limit further in the standard should be decided and expressed, such as how to recommend handling the maximum in the future for all eternity so we don't have to keep coming back and mucking with a training-wheels limit. User interface wording could be implemented by someone now, and compatible with the future. I recommend just removing the limit altogether after another year, wherein the user interface would take most effect. The wording could talk about how there is no protocol limit (besides the max main chain capability) but that implementations should expose reasonable default safety limits to their LN client users and node operators with some hints about what those defaults mean and how much money each setting represents so that users will continue to chose limits that represent their risk needs.