You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched for existing issues that already suggest this feature, without success.
Describe the Feature Request
Start9 should default to new channel opens being unannounced. Public channels should be opt in as they are primarily for routing node operators which the majority of lightning users are not.
When opening channels unannounced as default it would be handy to have a tool tip that pointed users who do want to be a routing node towards enabling a public channel open. Users who are looking to be routers would probably know the difference between public and unannounced though but this is a little extra life improvement. This is important because a channel needs to be closed and re-opened to change it's public status.
Describe the Use Case
What benefits does this have?
More reliable network wide payments as you wouldn't have inefficiently allocated capital acting as de-facto routing nodes (I'd assume many Start9 users are opening nodes to make payments and doing zero channel management). These channels also generally have low fees (the default) so get selected for routes more often than not which as the liquidity is not managed results in more payment failures for all users on lightning.
Users who open channels to just make payments (I'd assume most) wouldn't have to deal with all the UX implications of routing payments.
Some added privacy for users, they can still be revealed through probing but it makes it that little bit harder.
Some marginal reduction in gossip on the network limiting bandwidth requirements for node operators. This is likely going to become problematic with onion messages coming to lightning so limiting this as much as possible is a minor + to me.
EmbassyOS doesn't do channel opens of any kind on its own. This is up to the implementations of packages as well as the wallets that use them. Implementing this behavior in Zeus as you stated should give you the functionality you need without requiring any changes to EmbassyOS or the LND/CLN packages
RTL does not have a configurable default channel privacy setting. If they added one, then we could default everyone's channels to private. Neither does Thunderhub or Spark.
Definitely follow up on this with the maintainers of those repos, and report back if they update!
Prerequisites
Describe the Feature Request
Start9 should default to new channel opens being unannounced. Public channels should be opt in as they are primarily for routing node operators which the majority of lightning users are not.
When opening channels unannounced as default it would be handy to have a tool tip that pointed users who do want to be a routing node towards enabling a public channel open. Users who are looking to be routers would probably know the difference between public and unannounced though but this is a little extra life improvement. This is important because a channel needs to be closed and re-opened to change it's public status.
Describe the Use Case
What benefits does this have?
More reliable network wide payments as you wouldn't have inefficiently allocated capital acting as de-facto routing nodes (I'd assume many Start9 users are opening nodes to make payments and doing zero channel management). These channels also generally have low fees (the default) so get selected for routes more often than not which as the liquidity is not managed results in more payment failures for all users on lightning.
Users who open channels to just make payments (I'd assume most) wouldn't have to deal with all the UX implications of routing payments.
Some added privacy for users, they can still be revealed through probing but it makes it that little bit harder.
Some marginal reduction in gossip on the network limiting bandwidth requirements for node operators. This is likely going to become problematic with onion messages coming to lightning so limiting this as much as possible is a minor + to me.
We recently implemented this in Zeus: ZeusLN/zeus#1002
Describe Preferred Solution
No response
Describe Alternatives
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: