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

Feedback welcome!
Lightning-dev mailing list

Reply via email to