📅 Original date posted:2015-08-11
📝 Original message:
Hi Anthony,
Yes, reorg attacks are definitely a known with Bitcoin. You can send
money to an exchange and then double-spend withdraw several
confirmations later if you have infinite hashrate.
With lightning, I think to fund the channel, the minimum confirmation
times should be fairly high (even above 6 confirms). If a 120-block
reorg occurs, bitcoin is pretty busted anyway, might be of out-of-scope
with Lightning. IMO, lightning reduces this attack.
The nice thing about payment channels is that after it's set up, you
don't worry about confirmation times if it's off-chain. For that reason,
confirmation times (and block mining rate, ~10 minutes) matters a lot
less.
On Wed, Aug 12, 2015 at 03:38:16AM +0800, Anthony Towns wrote:
> Hi,
>
> This is probably just stating the obvious. Sometimes that's useful though,
> and maybe this is one of those times!
>
> When setting up a new channel with an untrusted counterparty, you will wait
> for N confirmations of their anchor transactions. Further, N might be well
> known and common amongst a lot of lightning hubs (if it's not, then it will
> be hard to know how long setting up a channel will take). What if N is too
> small, and I can afford to do a double-spend despite M (M > N)
> confirmations as long as it gains me $X?
>
> Then I do the following:
>
> - I open one or more anonymous channels, capable of receiving at least $X
> - I start the doublespend fork
> - I then simultaneously construct multiple lightning channels, funding
> them at $d each.
> - I wait for N confirmations so my new channels are active.
> - I quickly route multiple payments from my new channels to my anonymous
> channels until I can't send anymore
> - I publish the doublespending fork, so that my $d*n never got spent
> - I close my original anonymous channels gaining $X <= $d*n
>
> The only people worse off are the ones who opened the $d channels after N
> confirmations -- any intermediary hubs are fine. Those hubs didn't have to
> commit any funds to the new channels for the attack to work; the money they
> lose was that in other channels they used to route my payments forwards.
>
> With onion routing, none of the ripped off hubs need know where the money
> ended up, so there's not a lot of potential to do iron pipe cryptography to
> get your money back.
>
> The only constraints here (I think) are:
>
> - how many channels you can open in M-N blocks
> - you have to have >$X funds available in the first place to commit to the
> double spend
> - how much capacity the lightning network actually has in routable bitcoin
>
> If it costs 1.4*25*M bitcoin to mount a doublespend attack over M blocks
> (ie bribing 67% of hashpower for the time it normally takes to do 2*M
> blocks), and you can open 2000 channels per block, then that gives
>
> X > 1.4*25*M
> n < 2000*(M-N)
>
> X < d*n = d*2000*(M-N)
>
> 1.4*25*M < X < d*2000*(M-N)
> 35/2000 * M < d * (M-N)
> 35/2000 * (1 + N/(M-N)) < d???
>
> Setting N = 12, M = 15 gives:
>
> d = 35/2000 * (1+4) = 7/80
> n = 6000
>
> so you're putting up 525 bitcoin by flooding the blockchain with anchor
> transactions, sending it to yourself over lightning, then doublespending
> the original 525 btc at a cost of spending ~505 btc on hashpower. Expensive
> ($157k capital to make $6k profit), but still worthwhile (3.8% ROI in ~6
> hours is 16% a day, or about 5e25 % annualised...)
>
> Maybe if you make N depend on d you could mitigate this though -- something
> like, if you to put "$d" on your side of the channel, you'll have to wait
> for 5+(d*2000/25)*2 confirmations. So a $50 channel is d=.2 BTC, which is
> ~37 confirmations, or about 6 hours. Increasing the blocksize (number of
> channels openable per block) or lowering the block reward (decreasing the
> cost of a doublespend fork) increases the confirmations required though...
>
> Cheers,
> aj
>
> --
> Anthony Towns <aj at erisian.com.au>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Joseph Poon
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-09 12:44:01
in reply to nevent1q…4vvl
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-09 12:44:01Event JSON
{
"id": "8e84167c2043eaa73593019b8c9021b059f37e5ffe31497a8075c6d64b5155d2",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314641,
"kind": 1,
"tags": [
[
"e",
"1999e6e5c3a08701e87d0441d41428c5f7ec78e406b229c140e87687eb2b705a",
"",
"root"
],
[
"e",
"9683d3524551c75d7e8eb9b7c23fee4c8c11333c1b948d5ea0e0318bd1b77d0a",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2015-08-11\n📝 Original message:\nHi Anthony,\n\nYes, reorg attacks are definitely a known with Bitcoin. You can send\nmoney to an exchange and then double-spend withdraw several\nconfirmations later if you have infinite hashrate.\n\nWith lightning, I think to fund the channel, the minimum confirmation\ntimes should be fairly high (even above 6 confirms). If a 120-block\nreorg occurs, bitcoin is pretty busted anyway, might be of out-of-scope\nwith Lightning. IMO, lightning reduces this attack.\n\nThe nice thing about payment channels is that after it's set up, you\ndon't worry about confirmation times if it's off-chain. For that reason,\nconfirmation times (and block mining rate, ~10 minutes) matters a lot\nless.\n\nOn Wed, Aug 12, 2015 at 03:38:16AM +0800, Anthony Towns wrote:\n\u003e Hi,\n\u003e \n\u003e This is probably just stating the obvious. Sometimes that's useful though,\n\u003e and maybe this is one of those times!\n\u003e \n\u003e When setting up a new channel with an untrusted counterparty, you will wait\n\u003e for N confirmations of their anchor transactions. Further, N might be well\n\u003e known and common amongst a lot of lightning hubs (if it's not, then it will\n\u003e be hard to know how long setting up a channel will take). What if N is too\n\u003e small, and I can afford to do a double-spend despite M (M \u003e N)\n\u003e confirmations as long as it gains me $X?\n\u003e \n\u003e Then I do the following:\n\u003e \n\u003e - I open one or more anonymous channels, capable of receiving at least $X\n\u003e - I start the doublespend fork\n\u003e - I then simultaneously construct multiple lightning channels, funding\n\u003e them at $d each.\n\u003e - I wait for N confirmations so my new channels are active.\n\u003e - I quickly route multiple payments from my new channels to my anonymous\n\u003e channels until I can't send anymore\n\u003e - I publish the doublespending fork, so that my $d*n never got spent\n\u003e - I close my original anonymous channels gaining $X \u003c= $d*n\n\u003e \n\u003e The only people worse off are the ones who opened the $d channels after N\n\u003e confirmations -- any intermediary hubs are fine. Those hubs didn't have to\n\u003e commit any funds to the new channels for the attack to work; the money they\n\u003e lose was that in other channels they used to route my payments forwards.\n\u003e \n\u003e With onion routing, none of the ripped off hubs need know where the money\n\u003e ended up, so there's not a lot of potential to do iron pipe cryptography to\n\u003e get your money back.\n\u003e \n\u003e The only constraints here (I think) are:\n\u003e \n\u003e - how many channels you can open in M-N blocks\n\u003e - you have to have \u003e$X funds available in the first place to commit to the\n\u003e double spend\n\u003e - how much capacity the lightning network actually has in routable bitcoin\n\u003e \n\u003e If it costs 1.4*25*M bitcoin to mount a doublespend attack over M blocks\n\u003e (ie bribing 67% of hashpower for the time it normally takes to do 2*M\n\u003e blocks), and you can open 2000 channels per block, then that gives\n\u003e \n\u003e X \u003e 1.4*25*M\n\u003e n \u003c 2000*(M-N)\n\u003e \n\u003e X \u003c d*n = d*2000*(M-N)\n\u003e \n\u003e 1.4*25*M \u003c X \u003c d*2000*(M-N)\n\u003e 35/2000 * M \u003c d * (M-N)\n\u003e 35/2000 * (1 + N/(M-N)) \u003c d???\n\u003e \n\u003e Setting N = 12, M = 15 gives:\n\u003e \n\u003e d = 35/2000 * (1+4) = 7/80\n\u003e n = 6000\n\u003e \n\u003e so you're putting up 525 bitcoin by flooding the blockchain with anchor\n\u003e transactions, sending it to yourself over lightning, then doublespending\n\u003e the original 525 btc at a cost of spending ~505 btc on hashpower. Expensive\n\u003e ($157k capital to make $6k profit), but still worthwhile (3.8% ROI in ~6\n\u003e hours is 16% a day, or about 5e25 % annualised...)\n\u003e \n\u003e Maybe if you make N depend on d you could mitigate this though -- something\n\u003e like, if you to put \"$d\" on your side of the channel, you'll have to wait\n\u003e for 5+(d*2000/25)*2 confirmations. So a $50 channel is d=.2 BTC, which is\n\u003e ~37 confirmations, or about 6 hours. Increasing the blocksize (number of\n\u003e channels openable per block) or lowering the block reward (decreasing the\n\u003e cost of a doublespend fork) increases the confirmations required though...\n\u003e \n\u003e Cheers,\n\u003e aj\n\u003e \n\u003e -- \n\u003e Anthony Towns \u003caj at erisian.com.au\u003e\n\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\n\n-- \nJoseph Poon",
"sig": "5f2df1dd8586636c865e42c1f18388b402d018edc100f66c477d1c2e2582ab002ba7409e3ecfdf0ff8dae49830121addf9b2f245ae046c6664f2f8a4fb54f5ec"
}