mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-02-21 14:04:18 +01:00
Code Issues Projects Releases Wiki Activity

Remove HTLC amount restriction (#877)

Browse source 
We previously had a restriction on HTLC amounts to avoid big losses during
the early phases of the network, but it shouldn't be necessary anymore.

As long as we honor `max_htlc_value_in_flight_msat` and implementations
provide safe defaults for that parameter, we don't need that additional
restriction.
This commit is contained in:
Bastien Teinturier 2021-06-21 22:41:46 +02:00 • committed by GitHub
parent bda72c8305
commit 84213f45c0
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 0 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
02-peer-protocol.md
View file

@ -843,8 +843,6 @@ A sending node:
- MUST offer `amount_msat` greater than 0.
- 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.
- if result would be offering more than the remote's
`max_accepted_htlcs` HTLCs, in the remote commitment transaction:
- MUST NOT add an HTLC.
@ -868,8 +866,6 @@ 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:
- 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:
- MUST ignore a repeated `id` value after a reconnection.
@ -902,10 +898,6 @@ as calculated in [BOLT #5](05-onchain.md#penalty-transaction-weight-calculation)
`cltv_expiry` values equal to or greater than 500000000 would indicate a time in
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.
The node _responsible_ for paying the Bitcoin fee should maintain a "fee
spike buffer" on top of its reserve to accommodate a future fee increase.
Without this buffer, the node _responsible_ for paying the Bitcoin fee may