Allow disabling new channel proposals based on listpays?

[sj-fisher]

I've been re-reading the clboss documentation and am reminded that clboss will consider opening channels to nodes we pay to regularly.

This is logical but doesn't it have privacy implications? Once we open a direct channel to another node, there is an on-chain transaction tying us together. Of course, it is possible that we opened the channel for some other reason, but my vague suspicion is that this still isn't great. It at least offers a hint to anyone investigating us that we might have a relationship with the other node. As an example, suppose we make a regular donation to a controversial charity and don't want to go out of our way to advertise our connection to it.

Assuming this is worth caring about, I think an easy fix would be a configurable boolean to say whether clboss is allowed to use listpays to propose new channels. I know it's already possible to use "clboss-unmanage open" to prevent this, but that means we have to think in advance about who we pay that we might not want to open a channel to.

Hmm... reading more of the documentation, we should maybe always allow listpays to propose a swap service as a new channel candidate. I assume we know or can find out what the swap service node(s) are, since clboss initiated the payments to them itself.

[ksedgwic]

In case it helps: https://github.com/ZmnSCPxj/clboss/blob/master/docs/channel_creation.md

[ksedgwic]

I checked the code to see if ChannelFinderByListpays uses "patrons" or not. It appears to send ProposePatronlessChannelCandidate.

One idea is to see if we can propose the frequent payment targets as patrons (instead of direct candidates) and then find good nodes next to them instead of directly connecting to them. This would help some.

Another idea is to see if we can somehow mark or label certain payments and exclude them from the extract_payees_loop which would improve privacy for these payments w/o sacrificing efficiency for other less privacy-critical payments.

[sj-fisher]

The idea of using the frequent payment targets as patrons is clever and would definitely help, although depending on one's level of paranoia it may not be enough. Although it might make things harder to implement, it might be nice to be able to specify "don't automatically create channels to nodes within distance n of regular payees" - so as you've described it n=0, but more paranoid users could specify n=1 to create channels to peers of peers of regular payees but not to their direct peers, and so on. (n>2 or 3 is probably 'silly'.)

I don't think the idea of marking certain payments as excluded from extract_payees_loop is bad, but personally I would like to be able to run my node in a "default private" setting, rather than having to remember to mark some of my payments as sensitive. Doesn't the existence of "clboss-unmanage open" already effectively provide this up-front opt out, albeit with a clunkier user interface than some kind of "this is sensitive" flag directly specified as part of the payment request?

I can (ignoring the dev effort needed) see value in providing different levels of support for privacy-vs-performance here, something like:

• never take payments into account when deciding on new channel peers
• never take non-swap payments into account when deciding on new channel peers
• take payments into account when deciding on new channel peers, but only ever use them as patrons
• take payments into account when deciding on new channel peers and allow direct connections to them (current default)