Good morning Rusty, To clarify, it seems the below:
1. There is a "private" node, one whose channels are all non-published. 2. There is a public node who knows that everything that passes through the channel with the "private" node comes only from the "private" node. It thus has an information advantage it might not have any incentive to sacrifice. 3. This protocol is initiated by the public node, and if the public node does not initiate it, the "private" node can do nothing. Is my understanding correct? Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, November 1, 2018 10:38 AM, Rusty Russell <ru...@rustcorp.com.au> wrote: > I'm not sure if this is too large a hammer for a small problem, but I > thought it worth writing up. > > Currently, a node with only private channels loses deniability of > payments; if you have an unannounced channel with me, I can be fairly > sure any payment I see coming from that channel is from you (in theory > you could have used 'r' hints to convince someone to send a payment > though you, but that requires boutique arrangements). > > If we create "local" channel announcements, which only propagate one > hop, this deniability increases. The mechanism would look something > like this. > > 1. type: 267 (`local_channel_id`) > 2. data: > - [`32`:`channel_id`] > - [`8`:`fake_short_channel_id`] > > The public node would suggest a fake short channel id (which it would > choose to be unique to it). If it wants, to the private node would > reply with: > > 3. type: 268 (`local_channel_id_signatures`) > 4. data: > - [`32`:`channel_id`] > - [`8`:`fake_short_channel_id`] > - [`32`:`fake_node_id`] > - [`64`:`node_signature`] > > The `fake_node_id` is the node_id which the private node wants to use > for the channel_announcement (it might be its real id, might not). The > `node_signature` is its signaure on the `local_channel_announcement` > message using that key. > > 5. type: 269 (`local_channel_announcement`) > 6. data: > - [`64`:`node_signature_1`] > - [`64`:`node_signature_2`] > - [`2`:`len`] > - [`len`:`features`] > - [`32`:`chain_hash`] > - [`8`:`short_channel_id`] > - [`33`:`other_node_id`] > > This is like `channel_announcement` without claiming a specific > bitcoin > funding transaction, and with one 'node_id' implied by who you receive > it from. This would be generated by the public node, and sent to its > peers: they MAY treat it as a valid channel_announcement, but SHOULD > NOT > propagate it (in fact, it can't be propagated). > > Now, `channel_update` works as before, with a similar non-propagation > rule. > > Feedback welcome! > Rusty. > > > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
