Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-11 Thread Antoine Riard via bitcoin-dev
Hi ZmnSCPxj Well your deeclipser is already WIP ;) See my AltNet+Watchdog proposals in Core: https://github.com/bitcoin/bitcoin/pull/18987/https://github.com/bitcoin/bitcoin/pull/18988 It's almost covering what you mention, a driver framework to plug alternative transports protocols : radio,

Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-10 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine and Gleb, One thing I have been idly thinking about would be to have a *separate* software daemon that performs de-eclipsing for your Bitcoin fullnode. For example, you could run this deeclipser on the same hardware as your Bitcoin fullnode, and have the deeclipser bind to

Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-08 Thread Aymeric Vitte via bitcoin-dev
Le 08/06/2020 à 06:56, ZmnSCPxj via bitcoin-dev a écrit : > Running both Bitcoin and Lightning nodes on clearnet automatically links > them, making them easier to attack, whereas running Lightning on Tor does not. > Of course, they could still be linked by onchain transaction monitoring, but >

Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-07 Thread ZmnSCPxj via bitcoin-dev
Good morning Antoine, > > Since the issue here is that eclipsing of Bitcoin nodes is risky, it > > strikes me that a mitigation would be to run your Bitcoin fullnode on > > clearnet while running your Lightning node over Tor > > We clearly mention that risk of running a Bitcoin node over Tor,

Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-07 Thread Antoine Riard via bitcoin-dev
Hi ZmnSCPxj, > (Of note as well, is that the onchain contract provided by such services is the same in spirit as those instantiated in channels of the Lightning Network, thus the same attack schema works on the onchain side.) If you onchain contract uses a timelock and has concurrent

Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-05 Thread Aymeric Vitte via bitcoin-dev
Hi, As far as I understand your answer is "let's try to use what exists", this is not what I am proposing and not the Tor network, no "standard" exit nodes, different hidden services, decentralized anonymizer network unlike the Tor network, nodes are anonymizing themselves Comments below, please

Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-05 Thread ZmnSCPxj via bitcoin-dev
Good morning Aymeric, > The issue each time there are discussions/research linking to Tor is that it > is biased since the beginning because based on a wrong postulate: using the > Tor network > Well, in the interest of using the wrong tool for a highly important job, let me present this

Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-05 Thread Aymeric Vitte via bitcoin-dev
Le 04/06/2020 à 04:58, ZmnSCPxj via bitcoin-dev a écrit : >> [Tor is tricky](https://arxiv.org/abs/1410.6079) too > Since the issue here is that eclipsing of Bitcoin nodes is risky, it strikes > me that a mitigation would be to run your Bitcoin fullnode on clearnet while > running your

Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-03 Thread ZmnSCPxj via bitcoin-dev
Good morning Gleb and Antoine, This is good research, thank you for your work. > **Targeting Per-Hop Packet Delay** is based on routing via the victim, and > the victim should have at least two channels with the attacker. The existence of offchain-to-onchain swap services means that the

[bitcoin-dev] Time-dilation Attacks on the Lightning Network

2020-06-03 Thread Gleb Naumenko via bitcoin-dev
Hi! I and Antoine Riard explored time-dilation attacks on Lightning. We have a blogpost, which is probably too long to include in the email in full. You can read it here: https://discrete-blog.github.io/time-dilation/ There’s also a paper we wrote: https://arxiv.org/abs/2006.01418 We believe