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.

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

[feature]: add more parameters to Channel Acceptor #8637

Open
AndySchroder opened this issue Apr 10, 2024 · 5 comments
Open

[feature]: add more parameters to Channel Acceptor #8637

AndySchroder opened this issue Apr 10, 2024 · 5 comments
Labels
enhancement Improvements to existing features / behaviour P3 might get fixed, nice to have zero conf

Comments

@AndySchroder
Copy link

Would like to see some more parameters added to Channel Acceptor

  • to_self_delay
  • base_fee
  • fee_rate
  • time_lock_delta

I realize that the base_fee, fee_rate, and time_lock_delta can be changed at any time by the other party, but if we already know their values will be undesirable to us from the start, we'd rather not take the risk opening a channel with them.

Also, the to_self_delay could be renegotiated later if lightning/bolts#1117 gets complete, but again we'd rather not open a channel with someone if we know we are going to want to renegotiate immediately. See #8635 for some more discussion on why controlling the to_self_delay is desirable.

@AndySchroder AndySchroder added the enhancement Improvements to existing features / behaviour label Apr 10, 2024
@ziggie1984
Copy link
Collaborator

So to_self_delay wouldn't be a problem to add because the counter party does send it via the channel negotiation, the other parameters are not negotiated but are part of the Channel_Update Gossip msg, which is only sent when the channel is already confirmed. So I don't think it is feasible, maybe query his other channels before opening a channel to get an idea of their fee strategy and timelock security evaluation ?

@saubyk
Copy link
Collaborator

saubyk commented Apr 16, 2024

maybe query his other channels before opening a channel to get an idea of their fee strategy and timelock security evaluation

You're suggesting this as a logic which user can apply, correct? Not something that we might build into channel acceptor

@saubyk saubyk added zero conf P3 might get fixed, nice to have labels Apr 16, 2024
@ziggie1984
Copy link
Collaborator

exactly fees and timelock are not exchanged during the opening process, so we cannot build this into the channel acceptor.

@AndySchroder
Copy link
Author

exactly fees and timelock are not exchanged during the opening process, so we cannot build this into the channel acceptor.

Okay, so actually one's script calling Channel Acceptor actually can already do the best we can because we can look at the node_pubkey and then use other RPC calls to query that nodes other channels and then decide what to do before accepting.

However, why does Channel Acceptor provide min_htlc and max_value_in_flight? Are those policies or channel parameters?

@ziggie1984
Copy link
Collaborator

However, why does Channel Acceptor provide min_htlc and max_value_in_flight? Are those policies or channel parameters?

The latter, they are channel constraints your peer has to follow when creating the commitment transaction. So his max_htlc amount in his channel policy can never be greater than the max_value_in_flight you negotiated during the channel opening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvements to existing features / behaviour P3 might get fixed, nice to have zero conf
Projects
None yet
Development

No branches or pull requests

3 participants