From 3b4b5f8f1d97a97b06bcd25e3e323d1de850e9af Mon Sep 17 00:00:00 2001 From: t-bast Date: Wed, 11 Aug 2021 09:34:47 +0200 Subject: [PATCH] Peers need to check each other's dust limit Since HTLCs below this amount will not appear in the commitment tx, they are effectively converted to miner fees. The peer could use this to grief you by broadcasting its commitment once it contains a lot of dust HTLCs. Fixes #696 --- 02-peer-protocol.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index b869f02a4..b781122d7 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -259,6 +259,7 @@ The receiving node MAY fail the channel if: - it considers `channel_reserve_satoshis` too large. - it considers `max_accepted_htlcs` too small. - it considers `dust_limit_satoshis` too small and plans to rely on the sending node publishing its commitment transaction in the event of a data loss (see [message-retransmission](02-peer-protocol.md#message-retransmission)). + - it considers `dust_limit_satoshis` too large. The receiving node MUST fail the channel if: - the `chain_hash` value is set to a hash of a chain that is unknown to the receiver. @@ -279,7 +280,7 @@ The receiving node MUST NOT: #### Rationale -The requirement for `funding_satoshis` to be less than 2^24 satoshi was a temporary self-imposed limit while implementations were not yet considered stable, it can be lifted by advertising `option_support_large_channel`. +The requirement for `funding_satoshis` to be less than 2^24 satoshi was a temporary self-imposed limit while implementations were not yet considered stable, it can be lifted by advertising `option_support_large_channel`. The *channel reserve* is specified by the peer's `channel_reserve_satoshis`: 1% of the channel total is suggested. Each side of a channel maintains this reserve so it always has something to lose if it were to try to broadcast an old, revoked commitment transaction. Initially, this reserve may not be met, as only one side has funds; but the protocol ensures that there is always progress toward meeting this reserve, and once met, it is maintained. @@ -295,6 +296,10 @@ would be eliminated as dust. The similar requirements in `accept_channel` ensure that both sides' `channel_reserve_satoshis` are above both `dust_limit_satoshis`. +The receiver should not accept large `dust_limit_satoshis`, as this could be +used in griefing attacks, where the peer publishes its commitment with a lot +of dust htlcs, which effectively become miner fees. + Details for how to handle a channel failure can be found in [BOLT 5:Failing a Channel](05-onchain.md#failing-a-channel). ### The `accept_channel` Message @@ -353,7 +358,6 @@ The receiver: - if `channel_type` is set, and `channel_type` was set in `open_channel`, and they are not equal types: - MUST reject the channel. - Other fields have the same requirements as their counterparts in `open_channel`. ### The `funding_created` Message