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

option_scid_assign: privacy protection for private channels. #681

Open
wants to merge 2 commits into
base: master
from

Conversation

@rustyrussell
Copy link
Collaborator

commented Oct 3, 2019

This turned out to be a bit more complex than I expected.

Private channels expose their funding transaction in routehints to
receive payments, but this is unnecesary. Their funding tx can also
be probed via payment attempts.

  1. A new feature, so you know when you can use these controls.
  2. A channel_flags bit so you can ensure that new channels are
    protected probes from the start.
  3. Messages to assign (and unassign) random short_channel_ids,
    with a side-effect of disabling the funding-tx-based one.

Fixes: #675

rustyrussell added 2 commits Oct 3, 2019
…in Contents.

It wes between "Packet Structure" and "Payload for the Last Node",
which is just weird.  Move it after "Payload for the Last Node".

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Private channels expose their funding transaction in routehints to
receive payments, but this is unnecesary.  Their funding tx can also
be probed via payment attempts.

1. A new feature, so you know when you can use these controls.
2. A channel_flags bit so you can ensure that new channels are
   protected probes from the start.
3. Messages to assign (and unassign) random short_channel_ids,
   with a side-effect of disabling the funding-tx-based one.

Fixes: #675
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@rustyrussell rustyrussell force-pushed the rustyrussell:guilt/option-scid-assign branch from d929b4a to acfd2b0 Oct 3, 2019
@t-bast t-bast self-requested a review Oct 4, 2019
Copy link
Collaborator

left a comment

Great proposal, thanks for putting this together.
I was thinking about that a couple of weeks ago and tinkering with the idea of going even further and allowing "private/unannounced" nodes to use multiple node IDs (node_id_alias maybe?).

My high-level idea is that Eve (not Alice, Alice is nice and has nothing to hide) opens an unannounced channel with some public node (why not ACINQ, I hear it's a great node?). She then registers several node ids with the public node to use as alias. When the public node receives a forwarding request, he uses the real node_id and short_channel_id. WDYT?

the funding flow wishes to advertise this channel publicly to the
network, as detailed within [BOLT #7](07-routing-gossip.md#bolt-7-p2p-node-and-channel-discovery).

`disable_incoming` indicates that no payments are to be accepted for this
channel: this is only effective if `announce_channel` is not set, and the

This comment has been minimized.

Copy link
@t-bast

t-bast Oct 4, 2019

Collaborator

This is a bit misleading. Payments will be accepted for this channel, but with a different short_channel_id than the funding-tx-based one, right? So maybe:

Suggested change
channel: this is only effective if `announce_channel` is not set, and the
channel using its funding-transaction-derived `short_channel_id`: this is only effective if `announce_channel` is not set, and the
If it were to conflict with a future `short_channel_id` for a real
channel, misrouting may occur. The simplest way to minimize this is
to use old block numbers, but that also reduces the search space.
Simpler is to select a random value which isn't already used, and
close (before funding_locked) any future channel unfortunate enough to
clash.
Comment for lines +1180  – +1185

This comment has been minimized.

Copy link
@t-bast

t-bast Oct 4, 2019

Collaborator

I'm more in favor of restricting to old blocks, this makes it a lot simpler to manage.
Restricting to old blocks means we have ~500.000*2^40 possibilities ~= 10^17
Assuming 100.000 attempts per second (most nodes probably won't be able to forward that many payment attempts per second, so it feels conservative) it will take more than 150.000 years to probe.
Should be a big enough search space, isn't it? ;)

This comment has been minimized.

Copy link
@rustyrussell

rustyrussell Oct 5, 2019

Author Collaborator

In practice, you can just pick a random 64 you will never clash. I don't want to overly restrict implementations: you can choose to use a subset of believable unspent outputs, etc.

This comment has been minimized.

Copy link
@t-bast

t-bast Oct 5, 2019

Collaborator

Agreed, I just think we can remove the statement that choosing old blocks reduces the search space because in practice it's irrelevant.

@rustyrussell

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 5, 2019

Great proposal, thanks for putting this together.
I was thinking about that a couple of weeks ago and tinkering with the idea of going even further and allowing "private/unannounced" nodes to use multiple node IDs (node_id_alias maybe?).

This is always possible, but makes routing loops worse, and can always be done on a separate layer.
I prefer rendezvous routing, which doesn't require registration.

@t-bast

This comment has been minimized.

Copy link
Collaborator

commented Oct 5, 2019

I prefer rendezvous routing, which doesn't require registration.

Isn't that true as well for the scid trick you're proposing in this PR? It's obsolete once we have rendezvous routing (which may also make the invoice route hints obsolete altogether).

However I believe that rendezvous routing is potentially more costly in terms of bytes used in the invoice, but maybe we should spend more time spec-ing a proposal to figure that out. I can work on that.

@t-bast

This comment has been minimized.

Copy link
Collaborator

commented Oct 7, 2019

Rendezvous routing will not play nicely with MPP...if a recipient wants to use rendezvous for multi-part payments, it will have to generate multiple onions (for each partial payment) which will be too big to put in the invoice.

This scid proposal is more lightweight so it will add value even if we have rendezvous support at some point.

This is always possible, but makes routing loops worse

I don't understand your point about routing loops...for "private" nodes these alias node ids will not be announced to the network and will only be included in invoices, with details of the (unannounced) channel leading to it. So it won't mess anything routing-related. And those alias node ids can be BIP32-derived from a main nodeId, so they won't even clash with any other nodeId in the network. Maybe I should draft something more detailed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.