Published on: 2020-02-13T10:45:46+00:00
In a series of email conversations, several individuals discuss the issue of privacy in Bitcoin Lightning Network transactions and propose various strategies to address it. The main concern is preventing correlation between different invoices by an adversary named Carol. One suggestion is to use a different node_id for each invoice, but it is noted that the lowest bits of the node ID are embedded in the SCID and should not be openly revealed to Carol.To hide from Bob, another participant named Bastien suggests using Tor and a different node_id for each channel opened with Bob. The importance of privacy in Bitcoin transactions is emphasized throughout the discussion, along with the need for effective strategies to maintain it.The conversation also touches on the topic of hiding the node ID of the last node. Bob can provide an encryption key to peers with unpublished channels, which they can XOR with their own true node ID and use the lowest bits in the SCID. The possibility of Alice using multiple Bobs to enhance her privacy is also explored.Another proposal is made by Mark Holden, suggesting a way for Alice and Bob to agree on a set of 256 scids without additional messages or changes to existing ones. This involves negotiating a random integer 'r' on open_channel and using the `temporary_channel_id`. Bob can compute 256 scids using a specific formula, resulting in a low chance of scid collisions between channels. A cuckoo filter is suggested as a more efficient alternative to keeping a map of 256 scids for each channel.Bastien Teinturier suggests a new scheme to prevent channel probing attacks in the Lightning Network, involving payment secrets and decoy keys to create decoy short channel IDs. The issue of assigning short channel IDs is also addressed, with the proposal of using blocknum=0 to identify special SCIDs and reserving the rest for the lowest 40 bits of the X-coord of the destination node ID. The use of short channel IDs as a reference to the next node in onion routing is mentioned, along with the potential for stealing additional bits from blocknum to increase identification capacity.The conversation continues with Bastien proposing an improved scheme for payment channel routing. The use of payment secrets and decoy node IDs is suggested to prevent leakage of real information. However, there is a need to address the issue of assigning SCIDs without revealing them trivially. The suggestion is made for Bob to keep a mapping and restrict each peer to 256 live SCIDs.In another email, the author explores enhancements for unannounced channels in the Lightning Network, which are useful for mobile nodes and help break linkability between on-chain and off-chain payments. The current implementation is considered broken as invoices leak both the node_id and short_channel_id. An alternative design is proposed, involving the use of decoy node IDs and short_channel_ids to prevent leakage. Improvements to the scheme include leveraging the payment_secret to reduce the size of the onion payload.Overall, the conversations highlight the ongoing efforts to address privacy concerns in Bitcoin Lightning Network transactions and propose various strategies and enhancements to achieve it effectively.
Updated on: 2023-07-31T22:32:27.737793+00:00