Decoy node_ids and short_channel_ids



Summary:

In an email exchange, Rusty Russell and Bastien Teinturier discuss the potential risks of using self-assigned SCID schemes in Lightning Network payments. They also discuss a proposed solution to improve payee privacy by using decoy hops to a rendezvous node in public channels. The scheme involves Alice selecting multiple hops with some blinding applied to those hops' node_id and scid. These decoy hops are then included in the invoice routing hints, thereby making it possible for Alice to achieve a cheap form of rendezvous that only costs a few hundred bytes in the invoice. The proposed scheme is available in a gist on GitHub. Additionally, they discuss how to handle unknown SCIDs in update_add_htlc while maintaining payee privacy. With Bob-assigned SCIDs, Alice can have Bob unallocate them before forgetting the invoice, so she will simply never see old invoices. Rusty suggests adding an argument to invoice which is an array of one or more scids, and assigning a random temporary nodeid to that invoice. He also notes that custodial lightning services may face KYC pressure in the future, which means they cannot pay arbitrary invoices. However, Bastien believes that there will be enough non-custodial wallets to let motivated users pay whatever they want, and users can even run their own node to pay such invoices if needed. Rusty agrees that paying to a temporary id and paying to a private channel should look identical to avoid draconian regulations.


Updated on: 2023-06-02T22:44:50.640595+00:00