public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

• * [bitcoin-dev] Time-dilation Attacks on the Lightning Network
         [not found] <2e8fba65-f7fa-4c37-a318-222547e25a06@Spark>
  @ 2020-06-03 16:20 ` Gleb Naumenko
    2020-06-04  2:58   ` ZmnSCPxj
    0 siblings, 1 reply; 10+ messages in thread
  From: Gleb Naumenko @ 2020-06-03 16:20 UTC (permalink / raw)
    To: bitcoin-dev
  
  [-- Attachment #1: Type: text/plain, Size: 3060 bytes --]
  
  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 this work should be interesting for anyone curious/excited about LN or other second-layer protocols in Bitcoin. We are very interested in your opinions!
  
  Now, let me share the intro from the post with you (which is really a summary of the work), since it’s about the right size for a mailing list post. Hopefully, it would motivate you to read further.
  
  Protocols on top of the Bitcoin base layer are really cool. They offer tremendous opportunities in terms of scalability, confidentiality, and functionality, at a cost of new security assumptions.
  
  We all know payment channels have to be monitored, otherwise, the funds can be stolen. That sounds too abstract though. We decided to study what an attacker actually has to do to steal funds from LN users.
  
  More specifically, we explored how peer-to-peer layer attacks can help with breaking the assumption above. Per time-dilation attacks, an attacker controls the victim’s access to the Bitcoin network (hard, but not impossible) and delays block delivery to the victim. After that, the attacker exploits that the victim can’t access recent blocks in a timely manner. In some cases, it is enough to isolate the victim only for two hours.
  
  Then the attacker makes a couple (totally legit) actions on the Lightning Network towards the victim’s channels, and at the same time commits a different state instead. Since the victim is behind in terms of the latest blockchain tip, they cannot detect this and react as required by the protocol.
  
  We demonstrate three different ways the attacker can steal funds from the victim, and discuss the feasibility/cost of these attacks. We also explore the broad scope of countermeasures, which may significantly increase the attack cost.
  
  In short, the takeaways from our work are:
  
  1. Many Lightning users (those with Bitcoin light clients) are currently vulnerable to Eclipse attacks.
  2. Those Lightning users which run Bitcoin Core full nodes are more robust to Eclipse attacks, but the attacks are still possible as recent research suggests.
  3. Eclipse attacks enable stealing funds via time-dilation.
  4. Time-dilation attacks can’t be mitigated with just observing slow block arrival, so there is no simple solution to (3).
  5. Thus, time-dilation is a practical way to steal funds from eclipsed users. Neither it requires hashrate nor targets merchants only. Light client users are a good target because they are easy to attack. Full node users are a good target because they are often used by major hubs (or service providers), and stealing their aggregate liquidiy might justify the high attack cost.
  6. Strong anti-Eclipse measures is the key solution. WatchTowers are cool too.
  
  
  Best,
  
  Gleb Naumenko and Antoine Riard
  
  [-- Attachment #2: Type: text/html, Size: 3656 bytes --]
  
  ^ permalink raw reply	[flat|nested] 10+ messages in thread

• • * Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
      2020-06-03 16:20 ` [bitcoin-dev] Time-dilation Attacks on the Lightning Network Gleb Naumenko
    @ 2020-06-04  2:58   ` ZmnSCPxj
      2020-06-05 10:10     ` Aymeric Vitte
      2020-06-07 22:31     ` Antoine Riard
      0 siblings, 2 replies; 10+ messages in thread
    From: ZmnSCPxj @ 2020-06-04  2:58 UTC (permalink / raw)
      To: Gleb Naumenko, Bitcoin Protocol Discussion
    
    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 attacker needs only build one channel to the victim for this attack to work.
    Rather than route to themselves, the attacker routes to a convenient service providing such a swap service, and receives the stolen funds onchain, with no need even for an incoming channel from a different node.
    (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.)
    
    Indeed, the attack can be mounted on such a service directly.
    
    Even without such a service, the incoming channel need not be directly connected to the victim.
    
    
    > [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 Lightning node over Tor.
    Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) "only" loses you the ability to pay, receive, or route (and thereby earn forwarding fees), but as long as your blockchain view is clear, it should be fine.
    
    Of course, the Lightning node could still be correlated with the Bitcoin node when transactions are broadcast with the attached Bitcoin node (as noted in the paper).
    Instead the Lightning node should probably connect, over Tor, to some random Bitcoin fullnodes / Electrum servers and broadcast txes to them.
    
    And this seems to tie with what you propose: that the LN node should use a different view-fullnode from the broadcast-fullnode.
    
    
    > if a node doesn’t observe a block within the last 30 minutes, it attempts to make a new random connection to someone in the network.
    
    A mitigation to this would be to run a background process which sleeps for 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
    It might want to `disconnectnode` any previous node it attempted to connect to.
    
    However I note that the help for `addnode` contains the text "though such peers will not be synced from", which confuses me, since it also refers to the `-connect` command line option, and `-connect` means you only connect out to the specific nodes, so if those are not synced from.... huh?
    
    And of course the interesting part is "how do we get a `${BITCOINNODE}` that we think is not part of the eclipsing attacker?"
    
    
    > If a Lightning node is behind in its Bitcoin blockchain view, but Lightning payments between honest nodes are still flowing through it, this node will have a high routing failure rate. This would happen because honest nodes on the routing path would reject the forwarded HTLC for being too close to expired.
    
    I am uncertain this would happen very often.
    In the first place, the incoming HTLC would have "reasonable" timeouts, or else the incoming honest node would not have routed it at all, and the outgoing HTLC would be relative to this incoming one, so the outgoing honest node will still accept this.
    
    The victim *could* instead check that the absolute timelocks seem very far in the future relative to its own view of the current blockheight.
    (a forwarding node miht want to do that anyway to have an upper bound against griefing attacks)
    
    What would definitely increase in failure rate would be payments arising from the victim node; the victim node believes the blockheight to be much lower than it actually is, and either the payee node, or some intermediate node along the route, will claim to have too little time to safely forward the funds.
    This does not help for nodes which are primarily forwarding nodes.
    
    
    
    Regards,
    ZmnSCPxj
    
    
    ^ permalink raw reply	[flat|nested] 10+ messages in thread

  • • * Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
        2020-06-04  2:58   ` ZmnSCPxj
      @ 2020-06-05 10:10     ` Aymeric Vitte
        2020-06-05 11:44       ` ZmnSCPxj
        2020-06-07 22:31     ` Antoine Riard
        1 sibling, 1 reply; 10+ messages in thread
      From: Aymeric Vitte @ 2020-06-05 10:10 UTC (permalink / raw)
        To: ZmnSCPxj, Bitcoin Protocol Discussion, Gleb Naumenko
      
      [-- Attachment #1: Type: text/plain, Size: 2892 bytes --]
      
      
      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 Lightning node over Tor.
      > Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on) "only" loses you the ability to pay, receive, or route (and thereby earn forwarding fees), but as long as your blockchain view is clear, it should be fine.
      >
      > Of course, the Lightning node could still be correlated with the Bitcoin node when transactions are broadcast with the attached Bitcoin node (as noted in the paper).
      > Instead the Lightning node should probably connect, over Tor, to some random Bitcoin fullnodes / Electrum servers and broadcast txes to them.
      >
      > And this seems to tie with what you propose: that the LN node should use a different view-fullnode from the broadcast-fullnode.
      >
      
      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
      
      I will not elaborate on this again, it's an obvious very bad idea to use
      the Tor network for bitcoin
      
      It's not a bad idea to use the Tor protocol with no story of exit nodes
      and hidden services, linking again to:
      https://github.com/Ayms/node-Tor#phase-4-and-phase-5
      
      And new link: http://www.peersm.com/Convergence-2020.pdf "A universal
      and generic architecture to anonymize any application or protocol and
      turn it into an independent decentralized p2p network inside browsers
      and servers, with browsers acting as servers"
      
      LN and bitcoin nodes would be relays and/or RDV points and/or clients
      and serving parties, some Tor network nodes could be used in the middle
      also (relays only) but in any case sybils/eclipse attacks become much
      more difficult to perform (or unlikely depending on how the peer
      discovery system is designed)
      
      bitcoin | node-Tor |bitcoin and LN.pipe(node-Tor)
      
      Then question for possible future tests: is there a simple way to pipe
      the bitcoin protocol via stdin/stdout? (the socks interface could be
      used but we already saw that it did raise issues)
      
      -- 
      Move your coins by yourself (browser version): https://peersm.com/wallet
      Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
      Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
      Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
      Get the torrent dynamic blocklist: http://peersm.com/getblocklist
      Check the 10 M passwords list: http://peersm.com/findmyass
      Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
      Peersm : http://www.peersm.com
      torrent-live: https://github.com/Ayms/torrent-live
      node-Tor : https://www.github.com/Ayms/node-Tor
      GitHub : https://www.github.com/Ayms
      
      
      [-- Attachment #2: Type: text/html, Size: 4829 bytes --]
      
      ^ permalink raw reply	[flat|nested] 10+ messages in thread

    • • * Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
          2020-06-05 10:10     ` Aymeric Vitte
        @ 2020-06-05 11:44       ` ZmnSCPxj
          2020-06-05 15:41         ` Aymeric Vitte
          0 siblings, 1 reply; 10+ messages in thread
        From: ZmnSCPxj @ 2020-06-05 11:44 UTC (permalink / raw)
          To: Aymeric Vitte; +Cc: Gleb Naumenko, Bitcoin Protocol Discussion
        
        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 thought:
        
        * The Tor network is weakened due to its dependence on a limited set of exit nodes.
        * "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services.
        * Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet connections, the issue is with Tor-to-clearnet connections.
        * Of course, no miner is going to run over Tor because latency, so all the miners will be on clearnet.
        * So make your own bridge between Tor and clearnet.
        * Run two fullnodes on your computer (with sufficient ingenuity, you can probably share their block storages, or make one pruning).
        * One fullnode is on the public network but runs in `blocksonly` so it does not propagate any transactions (which might be attached to your public IP).
        * The other fullnode is on the Tor network and has an `-addnode` to the public-network node via `localhost`, which I assume is very hard for an eclipse attacker to get at.
        * Use the Tor-fullnode to propagate your transactions.
        
        Of course, the eclipse attacker can still attack all Tor exit nodes and block outgoing transaction traffic to perform eclipse attacks.
        And if you decide to propagate transactions to the public-network node then you pretty much lose your privacy there.
        
        Regards,
        ZmnSCPxj
        
        
        ^ permalink raw reply	[flat|nested] 10+ messages in thread

      • • * Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
            2020-06-05 11:44       ` ZmnSCPxj
          @ 2020-06-05 15:41         ` Aymeric Vitte
            0 siblings, 0 replies; 10+ messages in thread
          From: Aymeric Vitte @ 2020-06-05 15:41 UTC (permalink / raw)
            To: ZmnSCPxj; +Cc: Gleb Naumenko, Bitcoin Protocol Discussion
          
          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 let me know what is unclear in the description of
          the project so I can modify it because all the time I get the impression
          that it is mixed with the Tor network while it just has a very little to
          do with it, and I don't get that the simple principle of communicating
          between nodes using the Tor protocol without RDV points is never considered
          
          Regards,
          
          Le 05/06/2020 à 13:44, ZmnSCPxj a écrit :
          > 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 thought:
          Then for an important job people should use the right tool...
          >
          > * The Tor network is weakened due to its dependence on a limited set of exit nodes.
          And centralized structure, limited set of nodes to make it short, for
          some (or a lot) misbehaving, not designed for bitcoin, nothing prevents
          bitcoin from operating its own anonymizer system, which I am proposing
          > * "Direct", within-Tor rendezvous points are good, i.e. Tor hidden services.
          Good to a certain extent... if you want to hide that you are operating a
          bitcoin node you can use RDV points (ie hidden services) but if you
          don't care you just connect anonymized circuits between bitcoin nodes,
          this is more "direct" and does not exist in the Tor network, this
          includes light clients that can act as relays also
          > * Thus, there is no issue with Tor-to-Tor or clearnet-to-clearnet connections, the issue is with Tor-to-clearnet connections.
          There are plenty of Tor-to-Tor issues, not theoretical but in the real
          world, "Tor-to-clearnet" can be done outside of the Tor network, ie the
          bitcoin network
          > * Of course, no miner is going to run over Tor because latency, so all the miners will be on clearnet.
          Probably, again I am not proposing a remake of the Tor network, I don't
          see the use for a miner to hide (neither for a bitcoin node to use RDV
          points), but they can be part of the global anonymized system, please
          see below
          > * So make your own bridge between Tor and clearnet.
          > * Run two fullnodes on your computer (with sufficient ingenuity, you can probably share their block storages, or make one pruning).
          > * One fullnode is on the public network but runs in `blocksonly` so it does not propagate any transactions (which might be attached to your public IP).
          > * The other fullnode is on the Tor network and has an `-addnode` to the public-network node via `localhost`, which I assume is very hard for an eclipse attacker to get at.
          > * Use the Tor-fullnode to propagate your transactions.
          Yes but one full node should be able to do this alone, ie implement both
          interfaces, like miners and everybody in fact (or Peersm bridges with
          bittorrent if you look at the history of the project)
          >
          > Of course, the eclipse attacker can still attack all Tor exit nodes and block outgoing transaction traffic to perform eclipse attacks.
          > And if you decide to propagate transactions to the public-network node then you pretty much lose your privacy there.
          
          Please see the convergence link, it's not based on the assumption that
          "the more you are the better you can hide and the lesser you can get
          attacked", this does not work at all, it's based on the assumption that
          even with a reduced set of peers it becomes very difficult to know who
          is doing what and whom is talking to whom, the concept of
          exiting/bridging to clearnet(s) is not clearly detailed in this version
          but appears on the drawings
          
          
          
          
          ^ permalink raw reply	[flat|nested] 10+ messages in thread

    • * Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
        2020-06-04  2:58   ` ZmnSCPxj
        2020-06-05 10:10     ` Aymeric Vitte
      @ 2020-06-07 22:31     ` Antoine Riard
        2020-06-08  4:56       ` ZmnSCPxj
        2020-06-10 23:34       ` ZmnSCPxj
        1 sibling, 2 replies; 10+ messages in thread
      From: Antoine Riard @ 2020-06-07 22:31 UTC (permalink / raw)
        To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: Gleb Naumenko
      
      [-- Attachment #1: Type: text/plain, Size: 6460 bytes --]
      
      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 transactions
      arbiter by this one , it's subject to time-dilation attack. So yes
      submarine swaps, or any kind of atomic swap is concerned. We note this in
      discussion.
      But you're right for the attack cost, you don't need a channel to these
      services, which is also concerning for their attack surface.
      
      > 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, where do
      we recommend running a LN node over Tor ?
      
      >   And this seems to tie with what you propose: that the LN node should
      use a different view-fullnode from the broadcast-fullnode.
      
      Yes in Countermeasures - Link layer diversity, specially if it's easy for
      an attacker to provoke a transaction broadcast by buying a channel to the
      LN node.
      
      > A mitigation to this would be to run a background process which sleeps
      for 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
      
      Yeah instead of having every node operator running their own hacky scripts,
      without them being bulletproofs on detection, I'm working on getting such
      mitigations directly in Core, easily deployable for everyone.
      
      > The victim *could* instead check that the absolute timelocks seem very
      far in the future relative to its own view of the current blockheight.
      
      I think you're right it's really dependent on CLTV_delta deployed on the
      path and time-dilation offset. The alternative you're proposing is a good
      one, but you shouldn't know where you're in the path and max CLTV is 2048
      blocks IIRC.
      
      Thanks for your reading and review,
      
      Cheers,
      Antoine
      
      Le mer. 3 juin 2020 à 22:58, ZmnSCPxj via bitcoin-dev <
      bitcoin-dev@lists•linuxfoundation.org> a écrit :
      
      > 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 attacker
      > needs only build one channel to the victim for this attack to work.
      > Rather than route to themselves, the attacker routes to a convenient
      > service providing such a swap service, and receives the stolen funds
      > onchain, with no need even for an incoming channel from a different node.
      > (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.)
      >
      > Indeed, the attack can be mounted on such a service directly.
      >
      > Even without such a service, the incoming channel need not be directly
      > connected to the victim.
      >
      >
      > > [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 Lightning node over Tor.
      > Eclipsing the Lightning node (but not the Bitcoin fullnode it depends on)
      > "only" loses you the ability to pay, receive, or route (and thereby earn
      > forwarding fees), but as long as your blockchain view is clear, it should
      > be fine.
      >
      > Of course, the Lightning node could still be correlated with the Bitcoin
      > node when transactions are broadcast with the attached Bitcoin node (as
      > noted in the paper).
      > Instead the Lightning node should probably connect, over Tor, to some
      > random Bitcoin fullnodes / Electrum servers and broadcast txes to them.
      >
      > And this seems to tie with what you propose: that the LN node should use a
      > different view-fullnode from the broadcast-fullnode.
      >
      >
      > > if a node doesn’t observe a block within the last 30 minutes, it
      > attempts to make a new random connection to someone in the network.
      >
      > A mitigation to this would be to run a background process which sleeps for
      > 20 minutes, then does `bitcoin-cli addnode ${BITCOINNODE} onetry`.
      > It might want to `disconnectnode` any previous node it attempted to
      > connect to.
      >
      > However I note that the help for `addnode` contains the text "though such
      > peers will not be synced from", which confuses me, since it also refers to
      > the `-connect` command line option, and `-connect` means you only connect
      > out to the specific nodes, so if those are not synced from.... huh?
      >
      > And of course the interesting part is "how do we get a `${BITCOINNODE}`
      > that we think is not part of the eclipsing attacker?"
      >
      >
      > > If a Lightning node is behind in its Bitcoin blockchain view, but
      > Lightning payments between honest nodes are still flowing through it, this
      > node will have a high routing failure rate. This would happen because
      > honest nodes on the routing path would reject the forwarded HTLC for being
      > too close to expired.
      >
      > I am uncertain this would happen very often.
      > In the first place, the incoming HTLC would have "reasonable" timeouts, or
      > else the incoming honest node would not have routed it at all, and the
      > outgoing HTLC would be relative to this incoming one, so the outgoing
      > honest node will still accept this.
      >
      > The victim *could* instead check that the absolute timelocks seem very far
      > in the future relative to its own view of the current blockheight.
      > (a forwarding node miht want to do that anyway to have an upper bound
      > against griefing attacks)
      >
      > What would definitely increase in failure rate would be payments arising
      > from the victim node; the victim node believes the blockheight to be much
      > lower than it actually is, and either the payee node, or some intermediate
      > node along the route, will claim to have too little time to safely forward
      > the funds.
      > This does not help for nodes which are primarily forwarding nodes.
      >
      >
      >
      > Regards,
      > ZmnSCPxj
      > _______________________________________________
      > bitcoin-dev mailing list
      > bitcoin-dev@lists•linuxfoundation.org
      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >
      
      [-- Attachment #2: Type: text/html, Size: 7307 bytes --]
      
      ^ permalink raw reply	[flat|nested] 10+ messages in thread

    • • * Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
          2020-06-07 22:31     ` Antoine Riard
        @ 2020-06-08  4:56       ` ZmnSCPxj
          2020-06-08 16:43         ` Aymeric Vitte
          2020-06-10 23:34       ` ZmnSCPxj
          1 sibling, 1 reply; 10+ messages in thread
        From: ZmnSCPxj @ 2020-06-08  4:56 UTC (permalink / raw)
          To: Antoine Riard; +Cc: Gleb Naumenko, Bitcoin Protocol Discussion
        
        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, where do we recommend running a LN node over Tor ?
        
        Nowhere, *I* am the one recommending this.
        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 at least this increases the effort to attack, hopefully it becomes marginally less desirable to attack you.
        
        On the other hand, you *could* run them on different public IP addresses, if you happen to have more than one; for those who do not even have a single public IP address there is no real choice if you want to let others to connect to you, Tor hidden service is the only Lightning-supported way to be accessible without a public IP.
        
        (There are sections of the world where commodity "home" internet connections do not automatically get a public IP, and the privilege of getting one may be an additional cost; though of course if you have no real intent to help support either the Bitcoin or Lightning networks, you do not need a public IP anyway, and with IPv6 it becomes less and less likely that a randomly-chosen entity would be unlucky enough to not get a public IP.)
        
        > > The victim *could* instead check that the absolute timelocks seem very far in the future relative to its own view of the current blockheight.
        > I think you're right it's really dependent on CLTV_delta deployed on the path and time-dilation offset. The alternative you're proposing is a good one, but you shouldn't know where you're in the path and max CLTV is 2048 blocks IIRC.
        
        Seeing an incoming payment that violates the max CLTV is a good indication you have been eclipsed.
        
        On the other hand, if your Bitcoin node is eclipsed, then it seems likely your Lightning node is also eclipsed (if running over the same hardware) and you might not receive any indication over Lightning that you have been eclipsed anyway.
        
        I suppose we need to identify just exactly *what* ways a node of either type can be eclipsed; it seems that mitigations that protect against one kind of eclipse will not work in general with other kinds of eclipse.
        
        Regards,
        ZmnSCPxj
        
        
        ^ permalink raw reply	[flat|nested] 10+ messages in thread

      • • * Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
            2020-06-08  4:56       ` ZmnSCPxj
          @ 2020-06-08 16:43         ` Aymeric Vitte
            0 siblings, 0 replies; 10+ messages in thread
          From: Aymeric Vitte @ 2020-06-08 16:43 UTC (permalink / raw)
            To: ZmnSCPxj, Bitcoin Protocol Discussion, Antoine Riard; +Cc: Gleb Naumenko
          
          
          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 at least this increases the effort to attack, hopefully it becomes marginally less desirable to attack you.
          Or makes it easier in fact, correcting what I said in my previous
          answer, stating a "yes" for a mixed bitcoin and/or LN node in clearnet
          and Tor, with or without different IPs, it's probably not difficult for
          the Tor attacker to identify you (for example pinging the nodes with a
          new received tx to see who has it in mempool)
          
          Similar to "Deanonymizing the VPN peers"
          https://github.com/Ayms/torrent-live, this is not public but the method
          uses the clearnet/VPN "mixity" and unexpectedly the more you try to hide
          the better you can get deanonymized
          
          The conclusion is always the same: do not use the Tor network for
          services it is not designed for
          
          
          ^ permalink raw reply	[flat|nested] 10+ messages in thread

      • * Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
          2020-06-07 22:31     ` Antoine Riard
          2020-06-08  4:56       ` ZmnSCPxj
        @ 2020-06-10 23:34       ` ZmnSCPxj
          2020-06-11  9:21         ` Antoine Riard
          1 sibling, 1 reply; 10+ messages in thread
        From: ZmnSCPxj @ 2020-06-10 23:34 UTC (permalink / raw)
          To: Antoine Riard; +Cc: Gleb Naumenko, Bitcoin Protocol Discussion
        
        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 port 8334.
        Then you set your Bitcoin fullnode with `addnode=localhost:8334` in your `bitcoind.conf`.
        
        Your Bitcoin fullnode would then connect to the deeclipser using normal P2P protocol.
        
        The deeclipser would periodically, every five minutes or so, check the latest headers known by your fullnode, via the P2P protocol connection your fullnode makes.
        Then it would attempt to discover any blocks with greater blockheight.
        
        The reason why we have a separate deeclipser process is so that the deeclipser can use a plugin system, and isolate the plugins from the main fullnode software.
        For example, the deeclipser could query a number of plugins:
        
        * One plugin could just try connecting to some random node, in the hopes of getting a new connection that is not eclipsed.
        * Another plugin could try polling known blockchain explorers and using their APIs over HTTPS, possibly over Tor as well.
        * Another plugin could try connecting to known Electrum servers.
        * New plugins can be developed for new mitigations, such as sending headers over DNS or blocks over mesh or etc.
        
        Then if any plugin discovers a block later than that known by your fullnode, the deeclipser can send an unsolicited `block` or `header` message to your fullnode to update it.
        
        The advantage of using a plugin system is that it becomes easier to prototype, deploy, and maybe even test new de-eclipsing mitigations.
        
        At the same time, by running a separate daemon from the fullnode, we provide some amount of process isolation in case some problem with the plugin system exists.
        The deeclipser could be run by a completely different user, for example, and you might even run multiple deeclipser daemons in the same hardware, with different non-overlapping plugins, so that an exploit of one plugin will only bring down one deeclipser, with other deeclipser daemons remaining functional and still protecting your fullnode.
        
        Finally, by using the P2P protocol, the fullnode you run could be a non-Bitcoin-Core fullnode, such as btcd or rust-bitcoin or whatever other fullnode implementations exist, assuming you actually want to use them for some reason.
        
        What do you think?
        
        Regards,
        ZmnSCPxj
        
        
        
        ^ permalink raw reply	[flat|nested] 10+ messages in thread

      • • * Re: [bitcoin-dev] Time-dilation Attacks on the Lightning Network
            2020-06-10 23:34       ` ZmnSCPxj
          @ 2020-06-11  9:21         ` Antoine Riard
            0 siblings, 0 replies; 10+ messages in thread
          From: Antoine Riard @ 2020-06-11  9:21 UTC (permalink / raw)
            To: ZmnSCPxj; +Cc: Gleb Naumenko, Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 4374 bytes --]
          
          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, DNS, even LN Noise, Tor's
          Snowflake... Proposal is a PoC with a multi-threaded process but yes I want
          production-design to be a multi-process for the reasons you mentioned.
          Drivers should be developed out-of-tree but with an interface to plug them
          smoothly (tm).
          
          Proposal is more generic than pure LN, like some privacy-concerned users
          may want to broadcast by default their transactions over radio. But for LN
          support it should a) detect network/block issuance anomalies b) dynamically
          react by closing channels or c) fetch headers/blocks through redundant
          communication channels and d) provide emergency transactions broadcast if
          your time-sensitive transactions are censored.
          
          It's long-term work so be patient but getting opt-in support in Core would
          make it far easier for any LN routing/vaulting node to deploy it. In the
          meanwhile you can have multiple nodes on different infrastructures to serve
          as a backend for your LN node.
          
          Bonus: if LN nodes are incentivized to deploy such strong anti-eclipsing
          measures to mitigate time-dilation it would benefit base layer p2p security
          network-wise. In case of network partition, your node with link layer
          redundancy will keep it in-sync its connected peers on the same side of the
          partition, even if they don't deploy anything.
          
          I'm sure you have improvements to suggest !
          
          Best,
          Antoine
          
          
          Le mer. 10 juin 2020 à 19:35, ZmnSCPxj <ZmnSCPxj@protonmail•com> a écrit :
          
          > 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 port 8334.
          > Then you set your Bitcoin fullnode with `addnode=localhost:8334` in your
          > `bitcoind.conf`.
          >
          > Your Bitcoin fullnode would then connect to the deeclipser using normal
          > P2P protocol.
          >
          > The deeclipser would periodically, every five minutes or so, check the
          > latest headers known by your fullnode, via the P2P protocol connection your
          > fullnode makes.
          > Then it would attempt to discover any blocks with greater blockheight.
          >
          > The reason why we have a separate deeclipser process is so that the
          > deeclipser can use a plugin system, and isolate the plugins from the main
          > fullnode software.
          > For example, the deeclipser could query a number of plugins:
          >
          > * One plugin could just try connecting to some random node, in the hopes
          > of getting a new connection that is not eclipsed.
          > * Another plugin could try polling known blockchain explorers and using
          > their APIs over HTTPS, possibly over Tor as well.
          > * Another plugin could try connecting to known Electrum servers.
          > * New plugins can be developed for new mitigations, such as sending
          > headers over DNS or blocks over mesh or etc.
          >
          > Then if any plugin discovers a block later than that known by your
          > fullnode, the deeclipser can send an unsolicited `block` or `header`
          > message to your fullnode to update it.
          >
          > The advantage of using a plugin system is that it becomes easier to
          > prototype, deploy, and maybe even test new de-eclipsing mitigations.
          >
          > At the same time, by running a separate daemon from the fullnode, we
          > provide some amount of process isolation in case some problem with the
          > plugin system exists.
          > The deeclipser could be run by a completely different user, for example,
          > and you might even run multiple deeclipser daemons in the same hardware,
          > with different non-overlapping plugins, so that an exploit of one plugin
          > will only bring down one deeclipser, with other deeclipser daemons
          > remaining functional and still protecting your fullnode.
          >
          > Finally, by using the P2P protocol, the fullnode you run could be a
          > non-Bitcoin-Core fullnode, such as btcd or rust-bitcoin or whatever other
          > fullnode implementations exist, assuming you actually want to use them for
          > some reason.
          >
          > What do you think?
          >
          > Regards,
          > ZmnSCPxj
          >
          >
          
          [-- Attachment #2: Type: text/html, Size: 5000 bytes --]
          
          ^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-06-11  9:22 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <2e8fba65-f7fa-4c37-a318-222547e25a06@Spark>
2020-06-03 16:20 ` [bitcoin-dev] Time-dilation Attacks on the Lightning Network Gleb Naumenko
2020-06-04  2:58   ` ZmnSCPxj
2020-06-05 10:10     ` Aymeric Vitte
2020-06-05 11:44       ` ZmnSCPxj
2020-06-05 15:41         ` Aymeric Vitte
2020-06-07 22:31     ` Antoine Riard
2020-06-08  4:56       ` ZmnSCPxj
2020-06-08 16:43         ` Aymeric Vitte
2020-06-10 23:34       ` ZmnSCPxj
2020-06-11  9:21         ` Antoine Riard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox