📅 Original date posted:2020-07-15
📝 Original message:On Tue, 14 Jul 2020 at 16:42, ZmnSCPxj via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200715/ed01a6cf/attachment.html>;
Jochen Hoenicke [ARCHIVE] /
npub1tu…dca6f
2023-06-07 18:25:55
in reply to nevent1q…kew3
Author Public Key
npub1tue9u2scw5pe77vn4fz0464zz0387gm0zwy2zjhqg2yap36zhj2s4dca6fPublished at
2023-06-07 18:25:55Event JSON
{
"id": "0f5cf6c2d00e77a86f9b0e58e989a67c6d0ec09b3d729b1234f182a5b22e23eb",
"pubkey": "5f325e2a1875039f7993aa44faeaa213e27f236f1388a14ae04289d0c742bc95",
"created_at": 1686162355,
"kind": 1,
"tags": [
[
"e",
"26fe7618e4158956272911ab8e6bc5741e3b8801ac9a9bacc5cb085d2c1c0d4a",
"",
"root"
],
[
"e",
"e731e70863ca98e91b92d3ab339994144f8c28cf94f4f96a98e6d458b519dd2e",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-07-15\n📝 Original message:On Tue, 14 Jul 2020 at 16:42, ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Mr. Lee,\n\u003e\n\u003e \u003e Sorry. Re-sending with correction to CC bitcoin-dev\n\u003e \u003e\n\u003e \u003e I am sorry if this was already brought up in previous threads. If I know\n\u003e \u003e lightning network correctly then HTLC is used to enforce settlements on\n\u003e \u003e blockchain if there is a dispute. Could a person lose money if their HTLC\n\u003e \u003e does not get confirmed in the timeframe or if an older HTLC gets\n\u003e \u003e confirmed first? I see different ways this could happen.\n\u003e \u003e\n\u003e \u003e One, if the blockchain is very saturated with other transactions. The\n\u003e \u003e reason we need lightning network is why it might have troubles with\n\u003e \u003e settlements?\n\u003e\n\u003e This could happen, but the entire exercise is to move transactions off the\n\u003e blockchain, precisely to lower this risk.\n\u003e\n\u003e Otherwise, transfers onchain will take a long time.\n\u003e In practice, a long time to settle a payment will invalidate many\n\u003e real-world economic exchanges anyway (consider paying for food at a\n\u003e restaurant --- if your payments take days to settle, the food has gotten\n\u003e stale before the restaurant receives payment and releases your food).\n\u003e Thus, if an onchain transfer takes a long time to settle, there is already\n\u003e risk of economic loss present.\n\u003e\n\u003e By moving activity offchain, we reduce pressure onchain and improve\n\u003e settlement speeds on both offchain and onchain, reducing risk of economic\n\u003e loss due to delay.\n\u003e\n\u003e\n\u003e \u003e Two, competition from a different conflicting HTLC. A newer\n\u003e \u003e HTLC might not get confirmed before an older HTL.\n\u003e\n\u003e I cannot make sense of this.\n\u003e\n\u003e You cannot create conflicting HTLCs.\n\u003e\n\nCorrect. Removing or Creating an HTLC is something that both channel\npartners need to agree on. They may create multiple pending HTLCs as long\nas there are enough funds, but creating conflicting HTLCs is not possible.\n\n\n\u003e \u003e\n\u003e \u003e I found out about a recent attack technique that sounds like it might be\n\u003e \u003e similar called \"flood and loot\".\n\u003e\n\u003e Roughly, my understanding of Flood and Loot is to make a lot of\n\u003e uneconomically tiny HTLCs going through a target victim forwarding node.\n\u003e You make circular routes going from your own node back to yourself.\n\u003e Then you refuse to actually claim the HTLCs sent back to yourself.\n\u003e\n\nNo, the way I understand it is that an attacker, say Malleroy, routes a lot\nof medium sized HTLC payments from his node to his node via a victim node,\nsay Alice's, and possibly other nodes.\nThen Malleroy *accepts* the payments by publishing the hash on the\nreceiving end, so he gets all the sent funds on his receiving channel.\nMalleroy's receiving node behaves completely honestly, and nobody can prove\nthat it belongs to the attacker.\nFinally when Alice claims her HTLC by presenting the hash, Malleroy just\nignores the claim. Now Alice, the victim, is forced to close the channel\nto prevent the HTLC to timeout. If Malleroy does it with multiple victims\nat exactly the same time, they will all compete with each other. The\nvictims cannot increase the fee for the HTLC claiming transaction, because\nthey are the ones who force-closed the channel. CPFP doesn't work, because\ntheir ultimate output is CLTV'd. As soon as the HTLC timeouts Malleroy can\nclaim the still pending HTLCs using an RBF transaction.\n\nSo it is Alice who has to force close, which puts her at a big disadvantage.\n\nMalleroy will have to pay the lightning fees, but they are negligible. The\nfee for the on-chain force-close transaction (with the HTLC outputs) is\npaid by whoever opened the channel. AFAIK the fee for the HTLC resolving\ntransactions is paid by whoever claims the HTLC. In this scenario it is\npaid from Alice's money. If Malleroy opened the channel, he risks losing\nsome funds to on-chain fees. On the other hand the one who pays the fee\ncontrols the fee. He could negotiate a very low fee (say a cent per HTLC),\nwhen the network is idle and then wait for a natural congestion before\nstarting the attack, giving him a low risk with high success probability.\nEvery HTLC he can claim after timeout is profit.\n\nRegards,\n Jochen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200715/ed01a6cf/attachment.html\u003e",
"sig": "1b55cf9f4c28dfa67454e4e79e208a936e7ab3b43fb215b2a7a7ec60716fbfa7c971157d557580a4b9dad93367a182f03c6a2a0c49b8f838bced73edd80b687f"
}