📅 Original date posted:2019-12-10
📝 Original message:
Good morning all,
> Nice writeup!
I agree.
> I'd encourage Lightning node authors and operators to ensure they have
> multiple, redundant, trusted methods of receiving Bitcoin block data in
> a timely fashion.
I believe there was some discussion before, possibly in Adelaide 2018, where we consider to also deliver header data over the LN wire protocol.
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.
> > Some LN errors messages may be triggered at abnormal rate like
> > `expiry_too_soon` due to victim using a HTLC base in the past and may
> > be used to guess oddities.
A node might engage in background probing of payments that definitely will fail, and thereby get such information that way.
Let us consider the case where Alice is a victim of such an eclipse attack, and is only connected to nodes (Bitcoin and Lightning) controlled by Mallory.
Alice makes a outgoing probe, and as all its peers are controlled by Mallory, its first hop goes through Mallory and then goes to Bob and Charlie (who will fail the payment).
Bob may notice that the CLTV is too near the future and thus fail with `expiry_too_soon`.
However, against this, Mallory can simply directly fail payments.
It would have to fail all payments that were not forwarded via Alice (i.e. if there is no Mallory1->Alice forward with similar value and timing as the Alice->Mallory2 forward, Mallory2 will fail the payment) immediately.
This allows Mallory to sidestep such protections.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:57:38
in reply to nevent1q…0r5z
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:57:38Event JSON
{
"id": "88b1804961b4f918dc904ee21fcc8676648c456ad856b422ddd5b9b33844dac7",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315458,
"kind": 1,
"tags": [
[
"e",
"5cab8387d6d05284fa12d1ea1f3527f2aa882e48c959e79d19f450e2d3597f25",
"",
"root"
],
[
"e",
"9ddcfaba696a937a2454b1a6f5cce30988a0fe07659173758f2805b693292cc7",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2019-12-10\n📝 Original message:\nGood morning all,\n\n\u003e Nice writeup!\n\nI agree.\n\n\n\u003e I'd encourage Lightning node authors and operators to ensure they have\n\u003e multiple, redundant, trusted methods of receiving Bitcoin block data in\n\u003e a timely fashion.\n\nI believe there was some discussion before, possibly in Adelaide 2018, where we consider to also deliver header data over the LN wire protocol.\nThis 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.\n\n\u003e \u003e Some LN errors messages may be triggered at abnormal rate like\n\u003e \u003e `expiry_too_soon` due to victim using a HTLC base in the past and may\n\u003e \u003e be used to guess oddities.\n\nA node might engage in background probing of payments that definitely will fail, and thereby get such information that way.\n\nLet us consider the case where Alice is a victim of such an eclipse attack, and is only connected to nodes (Bitcoin and Lightning) controlled by Mallory.\nAlice makes a outgoing probe, and as all its peers are controlled by Mallory, its first hop goes through Mallory and then goes to Bob and Charlie (who will fail the payment).\nBob may notice that the CLTV is too near the future and thus fail with `expiry_too_soon`.\n\nHowever, against this, Mallory can simply directly fail payments.\nIt would have to fail all payments that were not forwarded via Alice (i.e. if there is no Mallory1-\u003eAlice forward with similar value and timing as the Alice-\u003eMallory2 forward, Mallory2 will fail the payment) immediately.\nThis allows Mallory to sidestep such protections.\n\nRegards,\nZmnSCPxj",
"sig": "9b11466397da26909d59f6b2e41a7fcc686d75c251c0ef8623d6473781aecba2702181aedc688de61b3acf36c122835c7fcdfafa17ecd2792613863e776f6c32"
}