Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-11 📝 Original message: Hi, This is probably just ...
📅 Original date posted:2015-08-11
📝 Original message:
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150812/d8e1d102/attachment.html>;
📝 Original message:
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150812/d8e1d102/attachment.html>;