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

• * [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories
         [not found] <f0372f8eec5878fd919b654db76aeff7.squirrel@giyzk7o6dcunb2ry.onion>
  @ 2020-07-14  2:58 ` Mr. Lee Chiffre
    2020-07-14 14:42   ` ZmnSCPxj
    0 siblings, 1 reply; 3+ messages in thread
  From: Mr. Lee Chiffre @ 2020-07-14  2:58 UTC (permalink / raw)
    To: lightning-dev; +Cc: bitcoin-dev
  
  Sorry. Re-sending with correction to CC bitcoin-dev
  
  
  
  
  
   I am sorry if this was already brought up in previous threads. If I know
  lightning network correctly then HTLC is used to enforce settlements on
  blockchain if there is a dispute. Could a person lose money if their HTLC
  does not get confirmed in the timeframe or if an older HTLC gets
  confirmed first? I see different ways this could happen.
  
   One, if the blockchain is very saturated with other transactions. The
  reason we need lightning network is why it might have troubles with
  settlements? Two, competition from a different conflicting HTLC. A newer
  HTLC might not get confirmed before an older HTL. Three, denial of service
  the lightning router so they never have a chance to send a settlement
  HTLC.
  
  I found out about a recent attack technique that sounds like it might be
  similar called "flood and loot".
  
  Is this a concern on lightning network? I humbly say that I do not fully
  understand all of lightning network yet. I am working to grasp the idea.
  These are questions I look to find answer for. Another question I have. I
  did read the paper Scalable Funding of Bitcoin Micropayment Channel
  Networks. Would channel factories be better and eliminate my concern?
  
  
  I am sending this to lightning-dev mailing list. I do not see
  lightning-dev emails because google recaptcha blocks me from the
  subscribe. Please CC me if you reply so I can read it.
  
  -- 
  lee.chiffre@secmail•pro
  PGP 97F0C3AE985A191DA0556BCAA82529E2025BDE35
  
  
  
  
  
  
  ^ permalink raw reply	[flat|nested] 3+ messages in thread

• • * Re: [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories
      2020-07-14  2:58 ` [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories Mr. Lee Chiffre
    @ 2020-07-14 14:42   ` ZmnSCPxj
      2020-07-15 15:23     ` Jochen Hoenicke
      0 siblings, 1 reply; 3+ messages in thread
    From: ZmnSCPxj @ 2020-07-14 14:42 UTC (permalink / raw)
      To: Mr. Lee Chiffre, Bitcoin Protocol Discussion; +Cc: lightning-dev
    
    Good morning Mr. Lee,
    
    > Sorry. Re-sending with correction to CC bitcoin-dev
    >
    > I am sorry if this was already brought up in previous threads. If I know
    > lightning network correctly then HTLC is used to enforce settlements on
    > blockchain if there is a dispute. Could a person lose money if their HTLC
    > does not get confirmed in the timeframe or if an older HTLC gets
    > confirmed first? I see different ways this could happen.
    >
    > One, if the blockchain is very saturated with other transactions. The
    > reason we need lightning network is why it might have troubles with
    > settlements?
    
    This could happen, but the entire exercise is to move transactions off the blockchain, precisely to lower this risk.
    
    Otherwise, transfers onchain will take a long time.
    In practice, a long time to settle a payment will invalidate many real-world economic exchanges anyway (consider paying for food at a restaurant --- if your payments take days to settle, the food has gotten stale before the restaurant receives payment and releases your food).
    Thus, if an onchain transfer takes a long time to settle, there is already risk of economic loss present.
    
    By moving activity offchain, we reduce pressure onchain and improve settlement speeds on both offchain and onchain, reducing risk of economic loss due to delay.
    
    
    > Two, competition from a different conflicting HTLC. A newer
    > HTLC might not get confirmed before an older HTL.
    
    I cannot make sense of this.
    
    You cannot create conflicting HTLCs.
    Either you have some free money to create an HTLC, in which case there is no possible conflict with an existing HTLC (the fund is reserved for HTLCs, or it is yours without further encumbrance).
    
    Thus it is not possible to create a conflicting HTLC in any case: either you have funds (that are not already in an HTLC) to fund an HTLC and that HTLC cannot conflict with existing ones, or you have no funds and a new HTLC cannot be created until one of the HTLCs is resolved one way or another.
    
    > Three, denial of service
    > the lightning router so they never have a chance to send a settlement
    > HTLC.
    
    This is possible, but only that node risks loss.
    
    The reason why unilateral close is always possible is to handle the case where a routing node comes offline.
    
    If you have offered an HTLC to a routing node, you retain a timelock branch back to you (the "T" in HTLC).
    
    If the routing node goes offline past the timelock in the HTLC, then you unilaterally close the channel and drop the HTLC onchain.
    This is what lets you recover your funds.
    
    
    >
    > I found out about a recent attack technique that sounds like it might be
    > similar called "flood and loot".
    
    Roughly, my understanding of Flood and Loot is to make a lot of uneconomically tiny HTLCs going through a target victim forwarding node.
    You make circular routes going from your own node back to yourself.
    Then you refuse to actually claim the HTLCs sent back to yourself.
    
    Then you go offline.
    This means that the only way for the forwarding node to recover its funds is to drop the channel(s) involved onchain.
    But if the HTLCs are many and tiny, they are simply too uneconomic to claim onchain, so they just lose the channel funds as fees.
    
    
    
    >
    > Is this a concern on lightning network?
    
    Yes.
    Work is being done (anchor commitments) to mitigate the effects of onchain fees on Lightning.
    
    > I humbly say that I do not fully
    > understand all of lightning network yet. I am working to grasp the idea.
    > These are questions I look to find answer for. Another question I have. I
    > did read the paper Scalable Funding of Bitcoin Micropayment Channel
    > Networks. Would channel factories be better and eliminate my concern?
    
    They would not.
    Ultimately, your "final defense" is to drop the entire construction onchain until you reach the HTLCs and you can have the blockchain enforce the HTLC contract.
    
    It would *help* to reduce blockchain bloat by reducing the size of transactions to create multiple channels, and thus also secondarily helps reduce onchain fee pressure and also reduce Flood-and-Loot (which is basically a layer-crossing attack, taking advantage of lower-layer fees to create attacks on higher layers).
    
    But always the underlying problem remains: security costs something, and you have to pay for protection on the Internet when transacting with potentially untrusted (and untrustable) entities.
    It seems unlikely that "security costs something" can be eliminated.
    One can consider that modern-day state-imposed taxation is paying for security, for instance, of traditional face-to-face transactions.
    With Bitcoin, you can choose to either transact and pay for security, or not transact and forgo what you would have bought.
    With some tradeoffs, you can pay by other means that may be cheaper for you.
    
    
    Regards,
    ZmnSCPxj
    
    
    ^ permalink raw reply	[flat|nested] 3+ messages in thread

  • • * Re: [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories
        2020-07-14 14:42   ` ZmnSCPxj
      @ 2020-07-15 15:23     ` Jochen Hoenicke
        0 siblings, 0 replies; 3+ messages in thread
      From: Jochen Hoenicke @ 2020-07-15 15:23 UTC (permalink / raw)
        To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: lightning-dev
      
      [-- Attachment #1: Type: text/plain, Size: 4105 bytes --]
      
      On Tue, 14 Jul 2020 at 16:42, ZmnSCPxj via bitcoin-dev <
      bitcoin-dev@lists•linuxfoundation.org> wrote:
      
      > Good morning Mr. Lee,
      >
      > > Sorry. Re-sending with correction to CC bitcoin-dev
      > >
      > > I am sorry if this was already brought up in previous threads. If I know
      > > lightning network correctly then HTLC is used to enforce settlements on
      > > blockchain if there is a dispute. Could a person lose money if their HTLC
      > > does not get confirmed in the timeframe or if an older HTLC gets
      > > confirmed first? I see different ways this could happen.
      > >
      > > One, if the blockchain is very saturated with other transactions. The
      > > reason we need lightning network is why it might have troubles with
      > > settlements?
      >
      > This could happen, but the entire exercise is to move transactions off the
      > blockchain, precisely to lower this risk.
      >
      > Otherwise, transfers onchain will take a long time.
      > In practice, a long time to settle a payment will invalidate many
      > real-world economic exchanges anyway (consider paying for food at a
      > restaurant --- if your payments take days to settle, the food has gotten
      > stale before the restaurant receives payment and releases your food).
      > Thus, if an onchain transfer takes a long time to settle, there is already
      > risk of economic loss present.
      >
      > By moving activity offchain, we reduce pressure onchain and improve
      > settlement speeds on both offchain and onchain, reducing risk of economic
      > loss due to delay.
      >
      >
      > > Two, competition from a different conflicting HTLC. A newer
      > > HTLC might not get confirmed before an older HTL.
      >
      > I cannot make sense of this.
      >
      > You cannot create conflicting HTLCs.
      >
      
      Correct.  Removing or Creating an HTLC is something that both channel
      partners need to agree on.  They may create multiple pending HTLCs as long
      as there are enough funds, but creating conflicting HTLCs is not possible.
      
      
      > >
      > > I found out about a recent attack technique that sounds like it might be
      > > similar called "flood and loot".
      >
      > Roughly, my understanding of Flood and Loot is to make a lot of
      > uneconomically tiny HTLCs going through a target victim forwarding node.
      > You make circular routes going from your own node back to yourself.
      > Then you refuse to actually claim the HTLCs sent back to yourself.
      >
      
      No, the way I understand it is that an attacker, say Malleroy, routes a lot
      of medium sized HTLC payments from his node to his node via a victim node,
      say Alice's, and possibly other nodes.
      Then Malleroy *accepts* the payments by publishing the hash on the
      receiving end, so he gets all the sent funds on his receiving channel.
      Malleroy's receiving node behaves completely honestly, and nobody can prove
      that it belongs to the attacker.
      Finally when Alice claims her HTLC by presenting the hash, Malleroy just
      ignores the claim.  Now Alice, the victim, is forced to close the channel
      to prevent the HTLC to timeout. If Malleroy does it with multiple victims
      at exactly the same time, they will all compete with each other.  The
      victims cannot increase the fee for the HTLC claiming transaction, because
      they are the ones who force-closed the channel.  CPFP doesn't work, because
      their ultimate output is CLTV'd.  As soon as the HTLC timeouts Malleroy can
      claim the still pending HTLCs using an RBF transaction.
      
      So it is Alice who has to force close, which puts her at a big disadvantage.
      
      Malleroy will have to pay the lightning fees, but they are negligible.  The
      fee for the on-chain force-close transaction (with the HTLC outputs) is
      paid by whoever opened the channel. AFAIK the fee for the HTLC resolving
      transactions is paid by whoever claims the HTLC.  In this scenario it is
      paid from Alice's money.  If Malleroy opened the channel, he risks losing
      some funds to on-chain fees.  On the other hand the one who pays the fee
      controls the fee.  He could negotiate a very low fee (say a cent per HTLC),
      when the network is idle and then wait for a natural congestion before
      starting the attack, giving him a low risk with high success probability.
      Every HTLC he can claim after timeout is profit.
      
      Regards,
        Jochen
      
      [-- Attachment #2: Type: text/html, Size: 4930 bytes --]
      
      ^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-07-15 15:23 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <f0372f8eec5878fd919b654db76aeff7.squirrel@giyzk7o6dcunb2ry.onion>
2020-07-14  2:58 ` [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories Mr. Lee Chiffre
2020-07-14 14:42   ` ZmnSCPxj
2020-07-15 15:23     ` Jochen Hoenicke

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