From rusty at rustcorp.com.au Mon Feb 3 04:37:56 2020 From: rusty at rustcorp.com.au (Rusty Russell) Date: Mon, 03 Feb 2020 15:07:56 +1030 Subject: [Lightning-dev] Decoy node_ids and short_channel_ids In-Reply-To: References: Message-ID: <87h808cml7.fsf@rustcorp.com.au> Bastien TEINTURIER writes: > We can easily get rid of (1.) by leveraging the `payment_secret`. The > improved scheme is: > > * Alice draws a random `decoy_key` > * Alice computes the corresponding `decoy_node_id = decoy_key * G` > * Alice draws a random `payment_secret` > * Alice computes `decoy_short_channel_id = H(payment_secret * decoy_key * > bob_node_id) xor short_channel_id` > * Alice uses the `decoy_key` to sign the invoice > * Carol recovers `decoy_node_id` from the invoice signature > * Carol includes `P_I = payment_secret * decoy_node_id` in the onion > payload for Bob > * Bob can compute `short_channel_id = H(bob_private_key * P_I) xor > decoy_short_channel_id` > > But I don't see how to get rid of (2.). If anyone has a clever idea on how > to do that, I'd love to hear it! I really don't want a special marker on Carol; she needs to just pay like normal. Not just because it's simple, but because it means that Carol can use a custodial wallet without having to flag the payment as somehow special. AFAICT, having Bob assign scids is the only viable way to do this. The current proposal limits to one scid at a time, but it could be extended to allow multiple scids. (I'm seeking a clever way that Bob can assign them and trivially tell which ID is assigned to which peer, but I can't figure it out, so I guess Bob keeps a mapping and restricts each peer to 256 live scids?). I've updated and somewhat simplified the PR now. Cheers, Rusty.