>> I think we could stop this type of attack by including some kind of >> shared secret in the onion message to the final node: > I think we get this "for free" if we switch to path decorrelation and > points+privkeys instead of hashes+preimages. > > Path decorrelation means that each hop is given a random point, to be added > to the next SS "HTLC". > 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. > The final node also cannot differentiate between an incorrect total for this > scalar, or an incorrect "invoice hash"/invoice point. > > Hence, some intermediate node along the way cannot guess this, and the final > node will give the same error, i.e. "invoice point not found". > > That might indeed stop an attacker from testing 2nd-degree, 3rd-degree etc. neighbors, making the attack much less versatile. However, for his direct neighbor in the route, the attacker does learn the point to be used in that hop. Therefore I think the attacker can still test whether or not the next node is the final hop.
CJP _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
