Skip to content
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

Add advisory section for wumbo channels confirmations #746

Closed
wants to merge 4 commits into from
Closed

Add advisory section for wumbo channels confirmations #746

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
1bcd157
Add advisory section for wumbo channels:
araspitzu Feb 5, 2020
c79b82a
Replace Implementors with Implementers to please the spellchecker
araspitzu Feb 18, 2020
2cfe2c6
Advise for the block reward to largely exceed the funding amount
araspitzu Mar 3, 2020
6cc31bb
Address PR feedback
araspitzu Mar 18, 2020
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
4 changes: 4 additions & 0 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -192,6 +192,10 @@ know this node will accept `funding_satoshis` greater than or equal to 2^24.
Since it's broadcast in the `node_announcement` message other nodes can use it to identify peers
willing to accept large channel even before exchanging the `init` message with them.

Implementers are advised to provide the means to scale the number of confirmations, tweaking
`accept_channel.minimum_depth`, with the size of the funding amount. A rule of thumb is to
Copy link
Collaborator

Choose a reason for hiding this comment

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

We should just drop the sentence starting with "A rule of thumb". I don't think its sufficiently conservative for many users, and its probably too conservative for others.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm curious on why it wouldn't be sufficiently conservative for many users (we're also adding largely exceeds), but if this is too generic and can't cover most cases then I agree we should remove it.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think it's mainly that it's too opinionated. Looking at the cumulative block reward to evaluate cost is one way among several ways of evaluating your scaling scenario. Having this in the spec may be influencing too much the implementers.

IIUC what was suggested during the meeting, this advisory should only say something like:

Implementers are advised to provide the means to scale the number of confirmations, tweaking 
`accept_channel.minimum_depth` and `accept_channel.to_self_delay`, with the size of the funding amount.

And let implementers completely free of choosing what scaling strategies they offer to their users.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good to me 👍

wait enough blocks until the cumulative block reward exceeds the size of the channel.
Copy link

Choose a reason for hiding this comment

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

Maybe we should also recommend to scale to_self_delay in consequence ? You may have watchtowers to alleviate the liveliness requirement but mempool congestion is still a concern.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Why does the issue apply to to_self_delay? I don't think it does, I think only funding is important as you don't want to start using the channel, relay payments and then see the channel's funding tx be double spent. But what could the attack be when closing?

Copy link

Choose a reason for hiding this comment

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

Eclipsing your node and slowing block your block reception. That way I pin you with a delayed view of blockchain view, can broadcast a revoked commitment transaction and you won't react until it's too late. An adversary would also beneficiate from a congestioned mempool for your justice txn getting confirmed. This attack may be hard to setup but for a high-value channel they shouldn't be excluded, increasing to_self_delay means increasing period during which eclipsing must be sustained.

t-bast marked this conversation as resolved.
Show resolved Hide resolved

#### Requirements

The sending node:
Expand Down