Skip to content

Peers need to check each other's dust limit #894

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
t-bast merged 4 commits into from
Oct 6, 2021
+133 −12
Merged

Peers need to check each other's dust limit #894

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
a19d5fb
Peers need to check each other's dust limit
t-bast Aug 11, 2021
7e3dce4
Add network dust thresholds
t-bast Aug 18, 2021
9ff1387
Drop non-segwit support in shutdown
t-bast Sep 14, 2021
dff76b2
fixup! Add network dust thresholds
t-bast Sep 22, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 19 additions & 10 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -258,7 +258,6 @@ The receiving node MAY fail the channel if:
- it considers `max_htlc_value_in_flight_msat` too small.
- 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:
Expand All @@ -270,6 +269,7 @@ The receiving node MUST fail the channel if:
- `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint`, or `delayed_payment_basepoint`
are not valid secp256k1 pubkeys in compressed format.
- `dust_limit_satoshis` is greater than `channel_reserve_satoshis`.
- `dust_limit_satoshis` is smaller than `354 satoshis` (see [BOLT 3](03-transactions.md#dust-limits)).
Copy link
Contributor

@Crypt-iQ Crypt-iQ Sep 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should only apply for option_shutdown_anysegwit and otherwise allow a lower bound of 330 satoshis.

Copy link
Contributor

@Crypt-iQ Crypt-iQ Sep 21, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correction: I see eclair's reasoning for not allowing lower than 546 unless segwit-only shutdown. Maybe this should only apply if the node has option_shutdown_anysegwit & segwit-only shutdown. I know the latter isn't a feature-bit, but it could be.

Copy link
Collaborator Author

@t-bast t-bast Sep 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should only apply for option_shutdown_anysegwit and otherwise allow a lower bound of 330 satoshis.

I disagree, because option_shutdown_anysegwit can be activated after the channel is opened.
For example, Alice and Bob open a channel without option_shutdown_anysegwit and set dust_limit to 330 sats.
Then later they both activate option_shutdown_anysegwit (because why not?).
If they didn't use an upfront_shutdown_script, they're allowed to use a segwit v1+ script when closing the channel, which can be an issue for dust limits below 354 sats.
So let's be safe and use 354 sats which is future-proof.

Copy link
Contributor

@Crypt-iQ Crypt-iQ Sep 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, that makes sense.

- the funder's amount for the initial commitment transaction is not sufficient for full [fee payment](03-transactions.md#fee-payment).
- both `to_local` and `to_remote` amounts for the initial commitment transaction are less than or equal to `channel_reserve_satoshis` (see [BOLT 3](03-transactions.md#commitment-transaction-outputs)).
- `funding_satoshis` is greater than or equal to 2^24 and the receiver does not support `option_support_large_channel`.
Expand Down Expand Up @@ -547,12 +547,9 @@ A sending node:
- MUST send the same value in `scriptpubkey`.
- MUST set `scriptpubkey` in one of the following forms:

1. `OP_DUP` `OP_HASH160` `20` 20-bytes `OP_EQUALVERIFY` `OP_CHECKSIG`
(pay to pubkey hash), OR
2. `OP_HASH160` `20` 20-bytes `OP_EQUAL` (pay to script hash), OR
3. `OP_0` `20` 20-bytes (version 0 pay to witness pubkey hash), OR
4. `OP_0` `32` 32-bytes (version 0 pay to witness script hash), OR
5. if (and only if) `option_shutdown_anysegwit` is negotiated:
1. `OP_0` `20` 20-bytes (version 0 pay to witness pubkey hash), OR
2. `OP_0` `32` 32-bytes (version 0 pay to witness script hash), OR
3. if (and only if) `option_shutdown_anysegwit` is negotiated:
* `OP_1` through `OP_16` inclusive, followed by a single push of 2 to 40 bytes
(witness program versions 1 through 16)

Expand Down Expand Up @@ -580,9 +577,11 @@ may immediately begin closing negotiation, so we ban further updates
to the commitment transaction (in particular, `update_fee` would be
possible otherwise).

The `scriptpubkey` forms include only standard forms accepted by the
Bitcoin network, which ensures the resulting transaction will
propagate to miners.
The `scriptpubkey` forms include only standard segwit forms accepted by
the Bitcoin network, which ensures the resulting transaction will
propagate to miners. However old nodes may send non-segwit scripts, which
may be accepted for backwards-compatibility (with a caveat to force-close
if this output doesn't meet dust relay requirements).

The `option_upfront_shutdown_script` feature means that the node
wanted to pre-commit to `shutdown_scriptpubkey` in case it was
Expand Down Expand Up @@ -678,6 +677,10 @@ The receiving node:
- MUST propose a value "strictly between" the received `fee_satoshis`
and its previously-sent `fee_satoshis`.

The receiving node:
- if one of the outputs in the closing transaction is below the dust limit for its `scriptpubkey` (see [BOLT 3](03-transactions.md#dust-limits)):
- MUST fail the channel

#### Rationale

When `fee_range` is not provided, the "strictly between" requirement ensures
Expand All @@ -694,6 +697,12 @@ to have a maximum feerate. It may want a minimum feerate, however, to ensure
that the transaction propagates. It can always use CPFP later to speed up
confirmation if necessary, so that minimum should be low.

It may happen that the closing transaction doesn't meet bitcoin's default relay
policies (e.g. when using a non-segwit shutdown script for an output below 546
satoshis, which is possible if `dust_limit_satoshis` is below 546 satoshis).
No funds are at risk when that happens, but the channel must be force-closed as
the closing transaction will likely never reach miners.

## Normal Operation

Once both nodes have exchanged `funding_locked` (and optionally [`announcement_signatures`](07-routing-gossip.md#the-announcement_signatures-message)), the channel can be used to make payments via Hashed Time Locked Contracts.
Expand Down