From 63a937f687aae97daa242cd74205aa86ad2a5f9e Mon Sep 17 00:00:00 2001 From: Ulmo <224672+Ulmo@users.noreply.github.com> Date: Sat, 23 Feb 2019 19:34:39 -0800 Subject: [PATCH] Increase Bitcoin max chan size to 2^28-1 (~$10K) Increase Bitcoin max 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 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. --- 02-peer-protocol.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index e377f3f61..958f21105 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -783,7 +783,7 @@ Fees") while maintaining its channel reserve. - MUST NOT offer `amount_msat` below the receiving node's `htlc_minimum_msat` - MUST set `cltv_expiry` less than 500000000. - for channels with `chain_hash` identifying the Bitcoin blockchain: - - MUST set the four most significant bytes of `amount_msat` to 0. + - MUST set the seven most significant nibbles of `amount_msat` to 0. - if result would be offering more than the remote's `max_accepted_htlcs` HTLCs, in the remote commitment transaction: - MUST NOT add an HTLC. @@ -807,7 +807,7 @@ A receiving node: - SHOULD fail the channel. - if sending node sets `cltv_expiry` to greater or equal to 500000000: - SHOULD fail the channel. - - for channels with `chain_hash` identifying the Bitcoin blockchain, if the four most significant bytes of `amount_msat` are not 0: + - for channels with `chain_hash` identifying the Bitcoin blockchain, if the seven most significant nibbles of `amount_msat` are not 0: - MUST fail the channel. - MUST allow multiple HTLCs with the same `payment_hash`. - if the sender did not previously acknowledge the commitment of that HTLC: @@ -843,7 +843,9 @@ seconds, and the protocol only supports an expiry in blocks. `amount_msat` is deliberately limited for this version of the specification; larger amounts are not necessary, nor wise, during the -bootstrap phase of the network. +bootstrap phase of the network. The amount was initially limited to the +four most significant bytes being 0, but was changed to limiting +the seven most significant nibbles being 0 on February 23, 2019. ### Removing an HTLC: `update_fulfill_htlc`, `update_fail_htlc`, and `update_fail_malformed_htlc`