<oembed><type>rich</type><version>1.0</version><author_name>npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l</author_name><author_url>https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2018-12-04&#xA;📝 Original message:&#xA;Good morning CJP,&#xA;&#xA;&#xA;&gt; I think we could stop this type of attack by including some kind of&#xA;&gt; shared secret in the onion message to the final node:&#xA;&#xA;I think we get this &#34;for free&#34; if we switch to path decorrelation and points+privkeys instead of hashes+preimages.&#xA;&#xA;Path decorrelation means that each hop is given a random point, to be added to the next SS &#34;HTLC&#34;.&#xA;The final node needs to be given the total of the scalars of each hop random point along the route, most likely within the last hop of the onion.&#xA;The final node also cannot differentiate between an incorrect total for this scalar, or an incorrect &#34;invoice hash&#34;/invoice point.&#xA;&#xA;Hence, some intermediate node along the way cannot guess this, and the final node will give the same error, i.e. &#34;invoice point not found&#34;.&#xA;&#xA;Regards,&#xA;ZmnSCPxj</html></oembed>