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

random short channel id for private channels #675

Open
renepickhardt opened this issue Sep 28, 2019 · 2 comments · May be fixed by #681

Comments

@renepickhardt
Copy link
Contributor

commented Sep 28, 2019

Mark H pointed in this stackexchange comment out that:

It is best to assume that the short_channel_id specified in an invoice is just some arbitrary identifier which tells the last hop how to forward the payment.

I think for private channels we should stardatize the process of creating a short channel id that does not give the possability later to reveal the funding tx in the routing hints.

One idea - not sure if it is viable - that comes to my mind take the ECDH shared secrete and use it to encrypt the funding txid. use the necessary bytes from the encrypted result. This is deterministic for channel partners and just random junk for outsiders.

@btcontract

This comment has been minimized.

Copy link

commented Sep 28, 2019

This is a great idea, I like that peers are allowed to invent literally anything as long as it only concerns their private channels (turbo channels, channels without any on-chain funding at all and so on), there is no need to constrain a short_channel_id to some on-chain tx in this case.

@btcontract

This comment has been minimized.

Copy link

commented Sep 29, 2019

Another consideration: perhaps it makes sense to constrain random short ids by some max value so that node software can never conflate them with on-chain based short ids. For example, upper block height limit could be set to 500000 (a block height before LN went mainnet) so random short id would never be more than 500000x_x_.

rustyrussell added a commit to rustyrussell/lightning-rfc that referenced this issue Oct 3, 2019
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: lightningnetwork#675
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit to rustyrussell/lightning-rfc that referenced this issue Oct 3, 2019
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: lightningnetwork#675
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit to rustyrussell/lightning-rfc that referenced this issue Oct 3, 2019
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: lightningnetwork#675
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.