summaryrefslogtreecommitdiff
path: root/bip-0119.mediawiki
diff options
context:
space:
mode:
authorRichard Kiss <him@richardkiss.com>2020-02-01 12:25:27 -0800
committerGitHub <noreply@github.com>2020-02-01 12:25:27 -0800
commit3e85c85044915402b302605596831073f8e07318 (patch)
treea885b24d38bbd6cd6211a29208bd4216d71f3f42 /bip-0119.mediawiki
parent0042dec548f8c819df7ea48fdeec78af21974384 (diff)
downloadbips-3e85c85044915402b302605596831073f8e07318.tar.xz
Update bip-0119.mediawiki
Fix typo.
Diffstat (limited to 'bip-0119.mediawiki')
-rw-r--r--bip-0119.mediawiki2
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki
index 11a90bb..fa1ba4d 100644
--- a/bip-0119.mediawiki
+++ b/bip-0119.mediawiki
@@ -100,7 +100,7 @@ In BOLT #2, this maximum number of HTLCs in a channel is hard limited to 483 as
size to prevent the transaction from being too large to be valid. In common software implementations
such as LND, this limit is set much lower to 12 HTLCS. This is because accepting a larger number of
HTLCS makes it more difficult for transactions to confirm during congested periods as they must pay
-hire fees.
+higher fees.
Therefore, similarly to how congestion control is handled for normal transaction, lightning channel
updates can be done across an CHECKTEMPLATEVERIFY tree, allowing nodes to safely use many more
HTLCS.