BOLT2: Increase Bitcoin max chan size to 2^28-1 (~$10K)

[Ulmo]

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:

1. This change to BOLT-0002 can happen immediately.

2. In LND the file "fundingmanager.go" can have line 64 (which assigns maxBtcFundingAmount) changed from (1<<24)-1 to (1<<28)-1 when those developers see fit. In addition, they should consider how the default maximums are applied, especially with autopilot, so that a graceful experience for recent LND installations with the newest version can be had; manually increasing the limit would be allowed. For instance, line 319 of the file config.go for autopilot (which assigns the default conf file parameter autopilot.maxchansize using variable MaxChannelSize) could be appended with /16 before the closing parenthesis for the current change, and of course people could increase that as they see fit in their lnd.conf.

3. Similarly, in C-Lightning in file bitcoin/chainparams.c for the network_name of "bitcoin", "regtest", and "testnet", the parameters max_funding and max_payment can be changed from (1<<24)-1 to (1<<28)-1 and (0xFFFFFFFFULL) to (0xFFFFFFFFFULL), respectively.

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.

[araspitzu]

Please note that the drop of the channel funding limit has already been proposed and it goes by the name of 'wumbo/wumbology', you can find more info in the 1.1 proposals

[t-bast]

Superceded by #596