Good morning again Cezary,
> > That was really interesting to read this. > > Why you want to send Node ID inside pheromone? Why not to send random > > number, that would be then passed though invoice? > > To increase privacy, node could generate new random number every week and > > distribute pheromone gain. > > Our spam-limiting mechanism in current Lightning is tied to node IDs, and > node IDs are effectively anchored onchain by the channels they have (and > onchain is public anyway...). > I was hoping to reuse the same mechanism to give an upper bound on how much > spam you can ride on the Lightning pheromone network (the same bound applies > to the current Lightning gossip, you can only spam Lightning by spamming > Bitcoin, and spamming Bitcoin is costly). > > However, if you have other ideas about how to limit pheromone spam, I would > gladly like to hear it. For example, instead of considering distance-from-node, we could realize that it is the *channel* itself that is what limits the pheromone spam. So maybe the pheromone should count distance-from-*channel*. If I want to be a receiver, I just need to ensure that at least one of my open channels has been published as a pheromone (and I do not need to publish *all* my channels, just enough of them to have a good chance of being reachable). The pheromone would contain signatures of me and my counterparty. (In a post-Taproot world, it would contain a single signature, plus a proof that the UTXO involved is reserved *only* for Lightning network (for example, channel UTXOs could have a taprooted `OP_RETURN "Lightning Is Awesome!!"` branch which can never be used, but which can be revealed to show that it is for Lightning), and is not a locked UTXO that is *also* being used for another purpose, as that obviates the spam-limiting since multiple applications could now be spammed with a single onchain UTXO.) Crucially, the pubkeys used need not be our node IDs, and every channel will have different pubkeys, even if two channels are to the same two nodes. Now suppose I want to issue an invoice. I just check what channels I have that have been pheromone-broadcast. The invoice then contains the selected short-channel-id(s) rather than the actual node (though since invoices are signed, what pubkey do we use to sign it?). Then suppose I receive an incoming HTLC that is supposed to reach a short-channel-id of a channel I have. Either it is to me, or to my peer on that channel. If it is to me, then I should be able to recognize the payment hash / payment point on the HTLC/PTLC, and can claim it now. If I do not recognize it, it is probably to my counterparty, who can then check if it recognizes the payment hash / point and send back a definite `incorrect_or_unknown_payment_details`, signed by itself (which the payer can recognize as one of the signatories of the pheromone). Crucially, this lets me receive money via other, unpublished channels as well; the payment might be going in the direction of my channel, but I could also be on the shortest path between the payer and that specific channel. Now let us turn our attention to onion-routing a trampoline route when our pheromones are channel-based instead of node-based. Remember, onion-routing requires that we know a static public key of a node, with which we can make an asymmetric encryption. However, pheromones also show the two public keys involved in the channel, and our trampoline routing can use one or the other key arbitrarily (though budgets may need to add +1 hop in case it lands in the "wrong" direction). Then if I receive a trampoline-routed onion to a channel that I have, I can try to decrypt with my key, and if that succeeds, then I have unwrapped the onion and know the next trampoline (or I know that I am the final destination). If decryption fails (there is an HMAC again of the "rest" of the onion after all) then the onion is for my peer on that channel and I hand over the HTLC to it. Similarly, since payment point decorrelation will now be handled at the trampoline level, presumably the onion can now contain the tweak to be applied to the payment point. This gives a mild improvement in privacy: everyone else who is not involved in the channel has a 50/50 chance of guessing who is the real destination of the payment. Further, every channel I have has its own pubkey I own, which is not the same as the pubkey I own on another channel. I could use one channel as the destination when I am selling Ahura Mazda Holy Writings and Sanctified Commentary, and another channel as the destination when I am selling The Horned Man Depraved Sex Paraphernalia, even from the same Lightning node. With proper handling of UTXOs after closing (i.e. doing onchain mixing before spending onchain, or creating a new channel) then the single node I operate can sell both without anyone realizing I sell both kinds of products; I could claim that I was just an innocent third-party node that happened to have channels to both the Ahura Maza Holy Writings and Sanctified Commentary node, and The Horned Man Depravedd Sex Paraphernalia node. Regards, ZmnSCPXj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
