Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2019-12-16 📝 Original message: > The proposed ...
📅 Original date posted:2019-12-16
📝 Original message:
> The proposed countermeasure here of "raising alarms" in case the
> best-block nTime field is too far behind is compelling in a
> SPV-assumption world, though it is far from sufficient if the time delay
> is small
No that simple without interfering with IBD. While IBDing, alarms should be
off to avoid raising false positives so attacker
who succeeds to eclipse you before you synced to top won't raise it. And
your validation software needs to remember than
you're out of IBD to avoid being pinned back in the past, fallback to IBD
and disable alarms.
> 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.
I don't consider than your Lightning node is eclipsed. It needs further
research but IMO it's harder to eclipse without
detection on LN due to node pubkeys. And given than connectivity is cheaper
than base layer (no per-peer inventories to maintain)
if we have such header protocol, you should open connections to well-known
LN pubkeys. Even if you assume an infrastructure attacker,
given encrypted transport, it's hard to drop 80-bytes headers without
tampering others messages and so being easily detected.
Now how are you sure than LN pubkeys you get are the ones you intended to
connect to ? That's an authenticity problem and not
sure than copy-pasting from LN search engines is the best practice..
> I guess the sophisticated attacks try to trick the victim into believing
that no attack is underway, but I may be wrong.
Yes, a basic eclipse attack where you halt blocks update would be easily
detectable. Eclipsing by discarding
commitment/penalty txn still let CLTV/CSV time for the victim to react and
you can't be sure than victim
doesn't have a fallback way to broadcast tx. If well executed, attacks
described stay stealth
until it's too late to react. I think for analysis we should split
detection from reaction, even if in practice we
use same communication channel for both.
Le sam. 14 déc. 2019 à 19:07, Orfeas Stefanos Thyfronitis Litos <
o.thyfronitis at ed.ac.uk> a écrit :
> I guess the sophisticated attacks try to trick the victim into believing
> that no attack is underway, but I may be wrong.
>
> Orfeas
>
> On 14 December 2019 19:54:19 CET, "David A. Harding" <dave at dtrt.org>
> wrote:
>>
>> On Mon, Dec 09, 2019 at 01:04:07PM -0500, Antoine Riard wrote:
>>
>>> Time-Dilation Attacks on Offchain Protocols
>>> ------------------------------
>>>
>>
>> What is the advantage of these sophisticated attacks over the eclipse
>> attacker simply not relaying the honest user's commitment or penality
>> transactions to miners?
>>
>> -Dave
>>
>> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191216/fba721c5/attachment.html>;
📝 Original message:
> The proposed countermeasure here of "raising alarms" in case the
> best-block nTime field is too far behind is compelling in a
> SPV-assumption world, though it is far from sufficient if the time delay
> is small
No that simple without interfering with IBD. While IBDing, alarms should be
off to avoid raising false positives so attacker
who succeeds to eclipse you before you synced to top won't raise it. And
your validation software needs to remember than
you're out of IBD to avoid being pinned back in the past, fallback to IBD
and disable alarms.
> 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.
I don't consider than your Lightning node is eclipsed. It needs further
research but IMO it's harder to eclipse without
detection on LN due to node pubkeys. And given than connectivity is cheaper
than base layer (no per-peer inventories to maintain)
if we have such header protocol, you should open connections to well-known
LN pubkeys. Even if you assume an infrastructure attacker,
given encrypted transport, it's hard to drop 80-bytes headers without
tampering others messages and so being easily detected.
Now how are you sure than LN pubkeys you get are the ones you intended to
connect to ? That's an authenticity problem and not
sure than copy-pasting from LN search engines is the best practice..
> I guess the sophisticated attacks try to trick the victim into believing
that no attack is underway, but I may be wrong.
Yes, a basic eclipse attack where you halt blocks update would be easily
detectable. Eclipsing by discarding
commitment/penalty txn still let CLTV/CSV time for the victim to react and
you can't be sure than victim
doesn't have a fallback way to broadcast tx. If well executed, attacks
described stay stealth
until it's too late to react. I think for analysis we should split
detection from reaction, even if in practice we
use same communication channel for both.
Le sam. 14 déc. 2019 à 19:07, Orfeas Stefanos Thyfronitis Litos <
o.thyfronitis at ed.ac.uk> a écrit :
> I guess the sophisticated attacks try to trick the victim into believing
> that no attack is underway, but I may be wrong.
>
> Orfeas
>
> On 14 December 2019 19:54:19 CET, "David A. Harding" <dave at dtrt.org>
> wrote:
>>
>> On Mon, Dec 09, 2019 at 01:04:07PM -0500, Antoine Riard wrote:
>>
>>> Time-Dilation Attacks on Offchain Protocols
>>> ------------------------------
>>>
>>
>> What is the advantage of these sophisticated attacks over the eclipse
>> attacker simply not relaying the honest user's commitment or penality
>> transactions to miners?
>>
>> -Dave
>>
>> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191216/fba721c5/attachment.html>;