> 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.thyfroni...@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" <d...@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. >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev