Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-28 📝 Original message: Hi Dave, I think the ...
📅 Original date posted:2022-11-28
📝 Original message:
Hi Dave,
I think the issue you're describing about credential tampering by
intermediary nodes is correct. If Alice controls Y along the path
W->X->Y->Zed, she can waste the credentials value provided. Indeed, this
issue generalizes for any classic payment path, where a routing node can
waste the senders credentials allocated on the downstream hops.
As discussed on the corresponding BOLT proposal, "staking/reputational"
credentials are probably be dependent on fat errors to assign payment path
failure correctly:
https://github.com/lightning/bolts/pull/1043#discussion_r1029938977
(even further in the case of blinded path, the senders might need another
round with the recipient to share a subset of the fat error).
Note the usage of blinded path in the aforementioned comment is about
sending back fresh credentials if the HTLC succeeds. One alternative is to
use the per-hop shared secret and wrap them in the return HTLC onion.
Another alternative, a blinded onion route could be registered at HTLC
forward phase, and this blinded path is leveraged for the fresh credentials
refill (I think the quantity of credentials could be a privacy-leak itself,
that you would like to mask).
Best,
Antoine
Le sam. 26 nov. 2022 à 15:48, David A. Harding <dave at dtrt.org> a écrit :
> On 2022-11-21 14:26, Antoine Riard wrote:
> >> Clara Shikhelman wrote:
> >> 4. How would these tokens work with blinded paths and other
> >> privacy-preserving suggestions?
> >
> > Primarily, the tokens could use the new onion messages and blinded
> > paths for the dissemination and renewal rounds. Current design assumes
> > they're attached to the HTLC during forward along the payment path,
> > though I think one design alternative could be completely detached,
> > and the HTLC onion just contains a ref to the tokens.
>
> I'm not sure I understand this answer, so I'll explain in my own words
> and kindly ask that you tell me if I'm wrong or missing something
> important.
>
> If Alice wants to pay Zed using a blinded path where Zed chooses
> terminal channels W->X->Y->Zed, then Zed will need to provide to Alice
> the encrypted credential tokens for X, and Y. In theory, if Alice
> controls node Y, she can prevent the HTLC from settling and so waste the
> value of Zed's provided tokens for node X. However, Alice shouldn't
> know where Zed's node is in the LN topography and can't be assured that
> he'll forward through her secondary node, so the attack is uncertain to
> work. The attack may also have a cost---Alice may need to buy
> credential tokens for node W and the hops leading to it from her primary
> node---with that cost mitigating the chance of the attack and the
> likelihood that it would be profitable.
>
> Thank you both for the interesting proposal and the insightful
> questions!,
>
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221128/58fc4c69/attachment.html>;
📝 Original message:
Hi Dave,
I think the issue you're describing about credential tampering by
intermediary nodes is correct. If Alice controls Y along the path
W->X->Y->Zed, she can waste the credentials value provided. Indeed, this
issue generalizes for any classic payment path, where a routing node can
waste the senders credentials allocated on the downstream hops.
As discussed on the corresponding BOLT proposal, "staking/reputational"
credentials are probably be dependent on fat errors to assign payment path
failure correctly:
https://github.com/lightning/bolts/pull/1043#discussion_r1029938977
(even further in the case of blinded path, the senders might need another
round with the recipient to share a subset of the fat error).
Note the usage of blinded path in the aforementioned comment is about
sending back fresh credentials if the HTLC succeeds. One alternative is to
use the per-hop shared secret and wrap them in the return HTLC onion.
Another alternative, a blinded onion route could be registered at HTLC
forward phase, and this blinded path is leveraged for the fresh credentials
refill (I think the quantity of credentials could be a privacy-leak itself,
that you would like to mask).
Best,
Antoine
Le sam. 26 nov. 2022 à 15:48, David A. Harding <dave at dtrt.org> a écrit :
> On 2022-11-21 14:26, Antoine Riard wrote:
> >> Clara Shikhelman wrote:
> >> 4. How would these tokens work with blinded paths and other
> >> privacy-preserving suggestions?
> >
> > Primarily, the tokens could use the new onion messages and blinded
> > paths for the dissemination and renewal rounds. Current design assumes
> > they're attached to the HTLC during forward along the payment path,
> > though I think one design alternative could be completely detached,
> > and the HTLC onion just contains a ref to the tokens.
>
> I'm not sure I understand this answer, so I'll explain in my own words
> and kindly ask that you tell me if I'm wrong or missing something
> important.
>
> If Alice wants to pay Zed using a blinded path where Zed chooses
> terminal channels W->X->Y->Zed, then Zed will need to provide to Alice
> the encrypted credential tokens for X, and Y. In theory, if Alice
> controls node Y, she can prevent the HTLC from settling and so waste the
> value of Zed's provided tokens for node X. However, Alice shouldn't
> know where Zed's node is in the LN topography and can't be assured that
> he'll forward through her secondary node, so the attack is uncertain to
> work. The attack may also have a cost---Alice may need to buy
> credential tokens for node W and the hops leading to it from her primary
> node---with that cost mitigating the chance of the attack and the
> likelihood that it would be profitable.
>
> Thank you both for the interesting proposal and the insightful
> questions!,
>
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20221128/58fc4c69/attachment.html>;