ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-12-10 📝 Original message: Good morning all, > Nice ...
📅 Original date posted:2019-12-10
📝 Original message:
Good morning all,
> Nice writeup!
I agree.
> I'd encourage Lightning node authors and operators to ensure they have
> multiple, redundant, trusted methods of receiving Bitcoin block data in
> a timely fashion.
I believe there was some discussion before, possibly in Adelaide 2018, where we consider to also deliver header data over the LN wire protocol.
This is useful if and only if the Bitcoin fullnode we use is differently eclisable from the Lightning node we use, e.g. the Bitcoin fullnode is openly on an IPv4 address while the Lightning node is on a Tor hidden service.
> > Some LN errors messages may be triggered at abnormal rate like
> > `expiry_too_soon` due to victim using a HTLC base in the past and may
> > be used to guess oddities.
A node might engage in background probing of payments that definitely will fail, and thereby get such information that way.
Let us consider the case where Alice is a victim of such an eclipse attack, and is only connected to nodes (Bitcoin and Lightning) controlled by Mallory.
Alice makes a outgoing probe, and as all its peers are controlled by Mallory, its first hop goes through Mallory and then goes to Bob and Charlie (who will fail the payment).
Bob may notice that the CLTV is too near the future and thus fail with `expiry_too_soon`.
However, against this, Mallory can simply directly fail payments.
It would have to fail all payments that were not forwarded via Alice (i.e. if there is no Mallory1->Alice forward with similar value and timing as the Alice->Mallory2 forward, Mallory2 will fail the payment) immediately.
This allows Mallory to sidestep such protections.
Regards,
ZmnSCPxj
📝 Original message:
Good morning all,
> Nice writeup!
I agree.
> I'd encourage Lightning node authors and operators to ensure they have
> multiple, redundant, trusted methods of receiving Bitcoin block data in
> a timely fashion.
I believe there was some discussion before, possibly in Adelaide 2018, where we consider to also deliver header data over the LN wire protocol.
This is useful if and only if the Bitcoin fullnode we use is differently eclisable from the Lightning node we use, e.g. the Bitcoin fullnode is openly on an IPv4 address while the Lightning node is on a Tor hidden service.
> > Some LN errors messages may be triggered at abnormal rate like
> > `expiry_too_soon` due to victim using a HTLC base in the past and may
> > be used to guess oddities.
A node might engage in background probing of payments that definitely will fail, and thereby get such information that way.
Let us consider the case where Alice is a victim of such an eclipse attack, and is only connected to nodes (Bitcoin and Lightning) controlled by Mallory.
Alice makes a outgoing probe, and as all its peers are controlled by Mallory, its first hop goes through Mallory and then goes to Bob and Charlie (who will fail the payment).
Bob may notice that the CLTV is too near the future and thus fail with `expiry_too_soon`.
However, against this, Mallory can simply directly fail payments.
It would have to fail all payments that were not forwarded via Alice (i.e. if there is no Mallory1->Alice forward with similar value and timing as the Alice->Mallory2 forward, Mallory2 will fail the payment) immediately.
This allows Mallory to sidestep such protections.
Regards,
ZmnSCPxj