Re: [Lightning-dev] Proposal for "local" channel announcements.
Good morning Rusty and all, On reflection, it seems to me that non-public channels have the incentives very wrong. 1. Non-public channels are intended as a way to keep public maps small. So a node maintaining a non-public channel provides a service to the rest of the network by increasing number of participants without increasing map sizes of other nodes. 2. Users of non-public channels are not paid for the above service. 3. Users of non-public channels *pay* for their non-public channels by revealing to the other user of the channel that they are the only possible source/destination of payments. Let me instead propose, a different mechanism (which is what actually initially occurred to me when I first saw "local" channel announcements on the list of topics for the upcoming summit). 1. On channel open, the initiator of the channel indicates a "local" or "global" channel. Current channels are "global". In the far future, non-public channels have been subjected to an Exterminatus order. 2. "Local" channels are only gossiped up to some small number of nodes away, say 3. This still reduces the sizes of maps, while still providing an increased anonymity set in the number of possible users of the local channel. In my mind, something is wrong about non-public channels and their incentives. I suspect, some kind of "last mile" problem exists somehow. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, November 4, 2018 12:21 PM, Rusty Russell wrote: > ZmnSCPxj zmnsc...@protonmail.com writes: > > > 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. > > This is true. > > > 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? > > More routes means more fees, though. Your peer can always offer > substandard service, so I don't think this is worse. > > Cheers, > Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for "local" channel announcements.
ZmnSCPxj writes: > 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. This is true. > 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? More routes means more fees, though. Your peer can always offer substandard service, so I don't think this is *worse*. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for "local" channel announcements.
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 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
