📅 Original date posted:2020-02-03
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:58:31
in reply to nevent1q…vxy7
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:58:31Event JSON
{
"id": "c614bffbb8a6667b46246b684911c8e1fd168b457e0f215cf4dfee63e7ea0e41",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315511,
"kind": 1,
"tags": [
[
"e",
"3ed35742512a6038c8a47910d5915af4fefd8766015db6ab01e4ef19d4ac6fff",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2020-02-03\n📝 Original message:\nBastien TEINTURIER \u003cbastien at acinq.fr\u003e writes:\n\u003e We can easily get rid of (1.) by leveraging the `payment_secret`. The\n\u003e improved scheme is:\n\u003e\n\u003e * Alice draws a random `decoy_key`\n\u003e * Alice computes the corresponding `decoy_node_id = decoy_key * G`\n\u003e * Alice draws a random `payment_secret`\n\u003e * Alice computes `decoy_short_channel_id = H(payment_secret * decoy_key *\n\u003e bob_node_id) xor short_channel_id`\n\u003e * Alice uses the `decoy_key` to sign the invoice\n\u003e * Carol recovers `decoy_node_id` from the invoice signature\n\u003e * Carol includes `P_I = payment_secret * decoy_node_id` in the onion\n\u003e payload for Bob\n\u003e * Bob can compute `short_channel_id = H(bob_private_key * P_I) xor\n\u003e decoy_short_channel_id`\n\u003e\n\u003e But I don't see how to get rid of (2.). If anyone has a clever idea on how\n\u003e to do that, I'd love to hear it!\n\nI really don't want a special marker on Carol; she needs to just pay\nlike normal. Not just because it's simple, but because it means that\nCarol can use a custodial wallet without having to flag the payment as\nsomehow special.\n\nAFAICT, having Bob assign scids is the only viable way to do this. The\ncurrent proposal limits to one scid at a time, but it could be extended\nto allow multiple scids.\n\n(I'm seeking a clever way that Bob can assign them and trivially tell\nwhich ID is assigned to which peer, but I can't figure it out, so I\nguess Bob keeps a mapping and restricts each peer to 256 live scids?).\n\nI've updated and somewhat simplified the PR now.\n\nCheers,\nRusty.",
"sig": "f0595b597e855a827bcc705d0a7867d8c0561101743773a8ef1afc54b5248e36d363f0daf08bc684d3cd5dd53f95bee6516f45448e245a42c27fbac39d3d890f"
}