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: 1. type: 268 (`local_channel_id_signatures`) 2. 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. 1. type: 269 (`local_channel_announcement`) 2. 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 Lightningfirstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev