Skip to content

Topics: add new topic for unannounced channels#403

Merged
jnewbery merged 1 commit intobitcoinops:masterfrom
harding:2020-05-new-topics-1.5
May 19, 2020
Merged

Topics: add new topic for unannounced channels#403
jnewbery merged 1 commit intobitcoinops:masterfrom
harding:2020-05-new-topics-1.5

Conversation

@harding
Copy link
Copy Markdown
Collaborator

@harding harding commented May 15, 2020

Adds a new topic. An unresolved issue is what to call this topic: unannounced channels or private channels. The name we choose affects the URL and I really don't want to break a URL (or even setup a redirect) if we change names later, so let's try to choose a good term now.

Arguments for "unannounced"

  • It's an accurate description of the key attribute of such channels
  • It has no particular negative or positive connotations (AFAIK)
  • It has use going back to at least 2017 and a quick search of Lightning-Dev shows it being used by Rusty Russell, Christian Decker, and Bastien Teinturier. ZmnSCPxj seems to use the related term "unpublished channels". Those are all significant contributors to LN development and I like to honor contributor terminology choices when they don't get in the way of clear communication

Arguments for "private"

  • It's also an accurate description of the key attribute, although it may give the mistaken impression that private channels are resistant against surveillance (which they may not be, not any more than, say, private property is resistant against surveillance)
  • It's the term used in BOLTs 4 and 11
  • It seems to be the term used by everyone but the people noted above on the Lightning-Dev mailing per a quick search of the archives via my MUA

I originally went with "unannounced" because of Zmn's argument against such channels but @jnewbery questioned the logic there:

I don't fully understand z-man's argument. He says that if a channel is unannounced, then the connected party in that channel knows that all payments to/from that channel are ultimately to/from the other party. He then says that all channels should be announced. But in that case, doesn't the connected party still know that all payments to/from the other party are ultimately to/from the other party if there's only one announced channel to that pubkey? To avoid that, the other party needs to have at least two channels open and route payments (otherwise the spy could send probe payments via the victim and see that it never routes and only ever terminates payments).

Z-man's argument is against non-routing nodes rather than against unannounced channels.

I think I still prefer the "unannounced" name because of its lack of association with the word "privacy". I think it's better to use bland names than give users potentially unreasonable expectations. However, I don't have a strong opinion about which name we choose as long as it's something we can stick with long term.

@jnewbery
Copy link
Copy Markdown
Contributor

jnewbery commented May 15, 2020

I think 'unannounced' is better. Privacy is multidimensional and to some extent subjective, whereas unannounced is an objective description - it's a channel which is opened and not announced on the lightning gossip network.

I like the shorter unpublished channels delenda est summary. (I remembered the summary being longer than it actually is).

@ZmnSCPxj
Copy link
Copy Markdown
Contributor

To avoid that, the other party needs to have at least two channels open and route payments (otherwise the spy could send probe payments via the victim and see that it never routes and only ever terminates payments).

If the party with one published channel itself has unpublished / unannounced channels with other peers (who are foolish enough to use them) then it can route, and the surveilling node will mis-assign a set of payments as terminating to the one-published-channel node without realizing that in fact this is a routing node with its own unpublished peers.

Which suggests to me that basically the non-publishing nodes get their privacy leeched off by the published peer, thus unpublished channels delenda est.

Z-man's argument is against non-routing nodes rather than against unannounced channels.

This is correct. But a node with one published channel can still route if it has unpublished peers, whereas a completely unpublished node cannot route at all.

In any case "unannounced" / "unpublished" is a better term as it does not imply any privacy --- a node might be more concerned about making sure its onchain funds are not linked to its offchain Lightning activity (which is revealed on publication of a channel), and trust a particular Lightning Service Provider to keep mum about its offchain activity (which I would argue is not something you want to rely on --- people change, and since ultimately all Lightning Service Providers are made up of people, so too will they change, and the entity you find trustworthy today may not be trustworthy tomorrow, and yet the logs exists, thus, unpublished channels delenda est).

@jonatack
Copy link
Copy Markdown
Collaborator

I prefer "unannounced" as well, for the good reasons discussed above.

@harding harding force-pushed the 2020-05-new-topics-1.5 branch from a692ebc to 9c1d2bc Compare May 18, 2020 11:29
@harding
Copy link
Copy Markdown
Collaborator Author

harding commented May 18, 2020

Ok, unanimous agreement so far on naming. I've rephrased the final paragraph to give the reason for discouraging the name "private channels" as it confusing people into thinking they're more private. It still links to @ZmnSCPxj post, as I think that's still the best extended explanation of the privacy implications.

@jnewbery
Copy link
Copy Markdown
Contributor

@ZmnSCPxj - thanks for dropping in :)

I really don't understand the delenda est terminology, or for that matter any other argument along the lines of "to use Bitcoin/Lightning the way I want to, I need to prevent others from using Bitcoin/Lightning the way they choose to." We recently saw similar arguments about the mortal threat posed to all users of Bitcoin by people choosing to use BIP 157. I still believe in the approach of trying to build something better, rather than trying to prevent people from using something worse. That approach seems much more likely to succeed in the long run (and much more interesting!)

If the party with one published channel itself has unpublished / unannounced channels with other peers (who are foolish enough to use them) then it can route

ok, so lets imagine this world where you've successfully managed to delere all unannounced channels. In this world, nodes with announced channels no longer receive this privacy boost. In the world we live in, the fact that unannounced channels exist is enough to provide privacy cover for all announced channels.

the non-publishing nodes get their privacy leeched

Not true. The privacy/deniability benefits are shared by all announced channels, since any of them could be routing for unannounced channels. Yes, the unannounced channel counterparty does give up some of its privacy for the convenience of not having to be a routing node, which I think is a trade-off that some users want to make. Saying "that's not something I want to use or work on" makes sense to me. Saying "this poses a mortal thread to the entire system" is stretching.

Copy link
Copy Markdown
Contributor

@jnewbery jnewbery left a comment

Choose a reason for hiding this comment

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

ACK 9c1d2bc with a request for a small tweak to the summary text.

Comment thread _topics/en/unannounced-channels.md Outdated
don't intend to route payments, such as users of mobile clients that
aren't always online to route payments.

Unannounced channels channels are sometimes called **private
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

My preferred text:

Unannounced channels channels are sometimes called **private
channels** but this has been [discouraged][unpublished channels delenda est]
by some experts who dispute their privacy advantage over regular announced
channels.

(or similar)

@harding harding force-pushed the 2020-05-new-topics-1.5 branch from 9c1d2bc to 90418f6 Compare May 18, 2020 14:39
@harding
Copy link
Copy Markdown
Collaborator Author

harding commented May 18, 2020

Good discussion! I forced pushed another attempt at rewriting the final paragraph to try to fairly summarize the issue in as few words as possible (but with references).

@jnewbery
Copy link
Copy Markdown
Contributor

ACK 90418f6. Looks good to me. Neutral language is best for the topics summaries!

@ZmnSCPxj
Copy link
Copy Markdown
Contributor

ACK 90418f6

@jnewbery argument accepted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants