Joseph Poon [ARCHIVE] on Nostr: š Original date posted:2015-08-11 š Original message: Hi Anthony, Yes, reorg ...
š
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
š 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