According to BOLT 07, the accounting message of the node looks like this:
- type: 257 (
Where the addresses are as follows:
address descriptorThe types are defined:
one: ipv4; data =
two: ipv6; data =
3: Onion service tor v2; data =
- version 2 onion service addresses; It encodes an 80-bit, truncated one.
hash of a 1024 bit
RSApublic key for the onion service (a.k.a. Tor
4: Onion service tor v3; data =
- version 3 (prop224)
Onion service addresses; Code
[32:32_byte_ed25519_pubkey] || [2:checksum] || [1:version], where
checksum = sha3 (".onion checksum" | pubkey || version)[:2].
With this in mind, I could announce my node to have the IP address of another existing lightning node or even some arbitrary IP address. While it is clear that nobody could connect with me, since I do not control the IP address, I wonder how implementations could cope with this type of behavior.
Even if the implementations do not fight with such forgery, an attacker could probably use this to fish and trick a user into paying an invoice, since it comes from a node_id that is connected to an IP address of a well-known service where the person attacked could even be a client
Is there anything else that could go wrong with this phishing behavior? Maybe there would even be benefits from it?