random short channel id for private channels #675
Comments
|
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 |
|
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 |
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: lightning#675 Signed-off-by: Rusty Russell <[email protected]>
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: lightning#675 Signed-off-by: Rusty Russell <[email protected]>
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: lightning#675 Signed-off-by: Rusty Russell <[email protected]>
|
This has been exploited at https://github.com/BitcoinDevShop/hidden-lightning-network as announced on the mailinglist https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003603.html |
|
Fixed by #910 |
Mark H pointed in this stackexchange comment out that:
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.
The text was updated successfully, but these errors were encountered: