A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers

A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers
2022-02-24 21:39 ` Paul Sztorc
  
From: ZmnSCPxj @ 2022-02-24 12:49 UTC (permalink / raw)
  To: lightning-dev\@lists.linuxfoundation.org, bitcoin-dev

Good morning lightning-dev and bitcoin-dev,

Recently, some dumb idiot, desperate to prove that recursive covenants are somehow a Bad Thing (TM), [necromanced Drivechains][0], which actually caused Paul Sztorc to [revive][1] and make the following statement:

> As is well known, it is easy for 51% hashrate to double-spend in the LN, by censoring 'justice transactions'. Moreover, miners seem likely to evade retribution if they do this, as they can restrain the scale, timing, victims, circumstances etc of the attack.

Let me state that, as a supposed expert developer of the Lightning Network (despite the fact that I probably spend more time ranting on the lists than actually doing something useful like improve C-Lightning or CLBOSS), the above statement is unequivocally ***true***.

However, I believe that the following important points must be raised:

* A 51% miner can only attack LN channels it is a participant in.
* A 51% miner can simultaneously attack all Drivechain-based sidechains and steal all of their funds.

In order for "justice transactions" to come into play, an attacker has to have an old state of a channel.
And only the channel participants have access to old state (modulo bugs and operator error on not being careful of toxic waste, but those are arguably as out of scope as operator error not keeping your privkey safe, or bugs that reveal your privkey).

If the 51% miner is not a participant on a channel, then it simply has no access to old state of the channel and cannot even *start* the above theft attack.
If the first step fails, then the fact that the 51% miner can perform the second step is immaterial.

Now, this is not a perfect protection!
We should note that miners are anonymous and it is possible that there is already a 51% miner, and that that 51% miner secretly owns almost all nodes on the LN.
However, even this also means there is some probability that, if you picked a node at random to make a channel with, then there is some probability that it is *not* a 51% miner and you are *still* safe from the 51% miner.

Thus, LN usage is safer than Drivechain usage.
On LN, if you make a channel to some LN node, there is a probability that you make a channel with a non-51%-miner, and if you luck into that, your funds are still safe from the above theft attack, because the 51% miner cannot *start* the attack by getting old state and publishing it onchain.
On Drivechain, if you put your funds in *any* sidechain, a 51% miner has strong incentive to attack all sidechains and steal all the funds simultaneously.

--

Now, suppose we have:

* a 51% miner
* Alice
* Bob

And that 51% miner != Alice, Alice != Bob, and Bob != 51% miner.

We could ask: Suppose Alice wants to attack Bob, could Alice somehow convince 51% miner to help it steal from Bob?

First, we should observe that *all* economically-rational actors have a *time preference*.
That is, N sats now is better than N sats tomorrow.
In particular, both the 51% miner *and* Alice the attacker have this time preference, as does victim Bob.

We can observe that in order for Alice to benefit from the theft, it has to *wait out* the `OP_CSV` before it can finalize the theft.
Alice can offer fees to the miner only after the `OP_CSV` delay.

However, Bob can offer fees *right now* on the justice transaction.
And the 51% miner, being economically rational, would prefer the *right now* funds to the *maybe later* promise by Alice.

Indeed, if Bob offered a justice transaction paying the channel amount minus 1 satoshi (i.e. Bob keeps 1 satoshi), then Alice has to beat that by offering the entire channel amount to the 51% miner.
But the 51% miner would then have to wait out the `OP_CSV` delay before it gets the funds.
Its time preference may be large enough (if the `OP_CSV` delay is big enough) that it would rather side with Bob, who can pay channel amount - 1 right now, than Alice who promises to pay channel amount later.

"But Zeeman, Alice could offer to pay now from some onchain funds Alice has, and Alice can recoup the losses later!"
But remember, Alice *also* has a time preference!
Let us consider the case where Alice promises to bribe 51% miner *now*, on the promise that 51% miner will block the Bob justice transaction and *then* Alice gets to enjoy the entire channel amount later.
Bob can counter by offering channel amount - 1 right now on the justice transaction.
The only way for Alice to beat that is to offer channel amount right now, in which case 51% miner will now side with Alice.

But what happens to Alice in that case?
It loses out on channel amount right now, and then has to wait `OP_CSV` delay, to get the exact same amount later!
It gets no benefit, so this is not even an investment.
It is just enforced HODLing, but Alice can do that using `OP_CLTV` already.

Worse, Alice has to trust that 51% miner will indeed block the justice transaction.
But if 51% miner is unscrupulous, it could do:

* Get the bribe from Alice right now.
* After the bribe from Alice confirms, confirm the justice transaction (which has a bribe from Bob).
* Thus:
  * Alice loses the channel amount.
  * Bob keeps 1 satoshi.
  * 51% miner gets channel amount + channel amount - 1.

Now of course, we can eliminate the need for trust by using some kind of smart contract.
Unfortunately for Alice, there is no contract that Alice and 51% miner can engage in, to ensure that 51% miner will block the justice transaction, which itself does *not* require that 51% miner wait out the `OP_CSV` delay.
Either the payment from Alice to 51% miner is delayed (and the 51% miner suffers the time preference discount) or the 51% miner has to offer a bond that only gets released after the Alice theft succeeds (and again the 51% miner suffers the time preference discount on that bond).

Thus, due to the `OP_CSV` delay, the honest participant always has the upper hand, even in a 51% miner scenario.
If your channel is *not* with the 51% miner, your funds are still safe.

--

Now, we might consider, what if the 51% miner always blocks *all* Lightning-related transactions?
In that case, it loses out on any bribes that any LN participants would offer.

Further, with Taproot, a mutual LN channel close is indistinguishable from a singlesig spend.
Thus, not all LN-related transactions can be censored by the 51% miner.
Extensive use of Taproot Tapleaves can also make it difficult for a 51% miner to differentiate between LN and other protocols (though that *does* mean we should probably e.g. coordiante with other protocols like CoinSwap, CoinPool etc. so that the "shape" of Taproot Tapleaves is consistent across protocols).

--

A final note: in the presence of channel factories, the *entire* factory is at risk if at least one participant is the 51% miner or a sockpuppet thereof.
Thus, channel factories trade off even further scaling, at the cost of reduced protection against 51% miners.


Regards,
ZmnSCPxj

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019976.html
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019978.html




 permalink raw reply	[|nested]
2022-02-24 12:49 [bitcoin-dev] A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers ZmnSCPxj

  2022-02-26  7:39   ` ZmnSCPxj
  
From: Paul Sztorc @ 2022-02-24 21:39 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion, lightning-dev\@lists.linuxfoundation.org

[-- Attachment #1: Type: text/plain, Size: 3271 bytes --]

On 2/24/2022 7:49 AM, ZmnSCPxj via bitcoin-dev wrote:
...

>> ... it is easy for 51% hashrate to double-spend in the LN ...
> ... the above statement is unequivocally ***true***.

Both LN and Drivechain are vulnerable to miner-theft; and both use their design to deter theft.

> However, I believe that the following important points must be raised:
>
> * A 51% miner can only attack LN channels it is a participant in.
> * A 51% miner can simultaneously attack all Drivechain-based sidechains and steal all of their funds.

In LN, the main obstacle is that your miner-coalition must first join the channel.

In DC, the main obstacle is that your miner-coalition must construct a txn obeying the Bip300 rules. Knowing that SPV proofs allow miner-theft, the Bip300 rules are designed specifically to try to thwart miner-theft.

***

I don't think I can stop people from being ignorant about Drivechain. But I can at least allow the Drivechain-knowledgable to identify each other.

So here below, I present a little "quiz". If you can answer all of these questions, then you basically understand Drivechain:

0. We could change DC to make miner-theft impossible, by making it a layer1 consensus rule that miners never steal. Why is this cure worse than the disease?
1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly as possible*, how long would this take (in blocks)?
2. Per sidechain per year (ie, per 52560 blocks), how many DC withdrawals can take place (maximum)? How many can be attempted?
      (Ie, how does the 'train track metaphor' work, from ~1h5m in the "Overview and Misconceptions" video)?
3. Only two types of people should ever be using the DC withdrawal system at all.
   3a. Which two?
   3b. How is everyone else, expected to move their coins from chain to chain?
   3c. (Obviously, this improves UX.) But why does it also improve security?
--
4. What do the parameters b and m stand for (in the DC security model)?
5. How can m possibly be above 1? Give an example of a sidechain-attribute which may cause this situation to arise.
6. For which range of m, is DC designed to deter sc-theft?
7. If DC could be changed to magically deter theft across all ranges of m, why would that be bad for sidechain users in general?
--
8. If imminent victims of a DC-based theft, used a mainchain UASF to prohibit the future theft-withdrawal, then how would this affect non-DC users?
9. In what ways might the BTC network one day become uncompetitive? And how is this different from caring about a sidechain's m and b?
--
10. If DC were successful, Altcoin-investors would be harmed. Two Maximalist-groups would also be slightly harmed -- who are these?

***

> Thus, LN usage is safer than Drivechain usage.

Neither LN nor DC, are intended for use by everyone in every circumstance.

DC can simulate a zcash sidechain, but it can not allow for instant off-chain payments. So DC-vs-LN would never be an apples-to-apples comparison, on any criterion.

The end user should be free to decide, what risks they take with their money. Today, users can sell their BTC for Solana (or BSV or whatever). So, to me it seems clear that they should be "allowed" to spend their BTC to a Bip300 script, just as they are allowed to open a LN channel.

-Paul

[-- Attachment #2: Type: text/html, Size: 3917 bytes --]

 permalink raw reply	[|nested]
2022-02-24 21:39 ` Paul Sztorc

  2022-02-26 14:58     ` Billy Tetrud
  2022-02-27  0:42     ` Paul Sztorc
  
From: ZmnSCPxj @ 2022-02-26  7:39 UTC (permalink / raw)
  To: Paul Sztorc, Bitcoin Protocol Discussion
  Cc: lightning-dev\\@lists.linuxfoundation.org


Good morning Paul,


> I don't think I can stop people from being ignorant about Drivechain. But I can at least allow the Drivechain-knowledgable to identify each other.
>
> So here below, I present a little "quiz". If you can answer all of these questions, then you basically understand Drivechain:
>
> 0. We could change DC to make miner-theft impossible, by making it a layer1 consensus rule that miners never steal. Why is this cure worse than the disease?

Now miners are forced to look at all sideblocks, not optionally do so if it is profitable for them.

> 1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly as possible*, how long would this take (in blocks)?

13,150 (I think this is how you changed it after feedback from this list, I think I remember it was ~3000 before or thereabouts.)

> 2. Per sidechain per year (ie, per 52560 blocks), how many DC withdrawals can take place (maximum)? How many can be attempted?
>      (Ie, how does the 'train track metaphor' work, from ~1h5m in the "Overview and Misconceptions" video)?

I hate watching videos, I can read faster than anyone can talk (except maybe Laolu, he speaks faster than I can process, never mind read).

~4 times (assuming 52560 block per year, which may vary due to new miners, hashrate drops, etc)

> 3. Only two types of people should ever be using the DC withdrawal system at all.
>   3a. Which two?

a.  Miners destroying the sidechain because the sidechain is no longer viable.
b.  Aggregators of sidechain-to-minechain transfers and large whales.

>   3b. How is everyone else, expected to move their coins from chain to chain?

Cross-system atomic swaps.
(I use "System" here since the same mechanism works for Lightning channels, and channels are not blockchains.)

>   3c. (Obviously, this improves UX.) But why does it also improve security?

Drivechain-based pegged transfers are aggregates of many smaller transfers and thus every transfer out from the sidechain contributes its "fee" to the security of the peg.

> --
> 4. What do the parameters b and m stand for (in the DC security model)?

m is how much people want to kill a sidechain, 0 = everybody would be sad if it died and would rather burn all their BTC forever than continue living, 1 = do not care, > 1 people want to actively kill the sidechain.

b is how much profit a mainchain miner expects from supporting a sidechain (do not remember the unit though).
Something like u = a + b where a is the mainchain, b is the sidechain, u is the total profit.
Or fees?  Something like that.

> 5. How can m possibly be above 1? Give an example of a sidechain-attribute which may cause this situation to arise.

The sidechain is a total scam.
A bug may be found in the sidechain that completely negates any security it might have, thus removing any desire to protect the sidechain and potentially make users want to destroy it completely rather than let it continue.
People end up hating sidechains completely.

> 6. For which range of m, is DC designed to deter sc-theft?

m <= 1

> 7. If DC could be changed to magically deter theft across all ranges of m, why would that be bad for sidechain users in general?

Because the sidechain would already be part of mainchain consensus.

> --
> 8. If imminent victims of a DC-based theft, used a mainchain UASF to prohibit the future theft-withdrawal, then how would this affect non-DC users?

If the non-DC users do not care, then they are unaffected.
If the non-DC users want to actively kill the sidechain, they will counterattack with an opposite UASF and we have a chainsplit and sadness and mutual destruction and death and a new subreddit.

> 9. In what ways might the BTC network one day become uncompetitive? And how is this different from caring about a sidechain's m and b?

If it does not enable scaling technology fast enough to actually be able to enable hyperbitcoinization.

Sidechains are not a scaling solution, so caring about m and b is different because your focus is not on scaling.

> --
> 10. If DC were successful, Altcoin-investors would be harmed. Two Maximalist-groups would also be slightly harmed -- who are these?

Dunno!


Regards,
ZmnSCPxj


 permalink raw reply	[|nested]
2022-02-26  7:39   ` ZmnSCPxj

  2022-02-27  0:42     ` Paul Sztorc
  
From: Billy Tetrud @ 2022-02-26 14:58 UTC (permalink / raw)
  To: ZmnSCPxj, Bitcoin Protocol Discussion
  Cc: lightning-dev\\@lists.linuxfoundation.org

[-- Attachment #1: Type: text/plain, Size: 4839 bytes --]

> m is how much people want to kill a sidechain, 0 = everybody would be sad
if it died and would rather burn all their BTC forever than continue living

Math is brutal

On Sat, Feb 26, 2022, 01:39 ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

>
> Good morning Paul,
>
>
> > I don't think I can stop people from being ignorant about Drivechain.
> But I can at least allow the Drivechain-knowledgable to identify each other.
> >
> > So here below, I present a little "quiz". If you can answer all of these
> questions, then you basically understand Drivechain:
> >
> > 0. We could change DC to make miner-theft impossible, by making it a
> layer1 consensus rule that miners never steal. Why is this cure worse than
> the disease?
>
> Now miners are forced to look at all sideblocks, not optionally do so if
> it is profitable for them.
>
> > 1. If 100% hashrate wanted to steal coins from a DC sidechain *as
> quickly as possible*, how long would this take (in blocks)?
>
> 13,150 (I think this is how you changed it after feedback from this list,
> I think I remember it was ~3000 before or thereabouts.)
>
> > 2. Per sidechain per year (ie, per 52560 blocks), how many DC
> withdrawals can take place (maximum)? How many can be attempted?
> >      (Ie, how does the 'train track metaphor' work, from ~1h5m in the
> "Overview and Misconceptions" video)?
>
> I hate watching videos, I can read faster than anyone can talk (except
> maybe Laolu, he speaks faster than I can process, never mind read).
>
> ~4 times (assuming 52560 block per year, which may vary due to new miners,
> hashrate drops, etc)
>
> > 3. Only two types of people should ever be using the DC withdrawal
> system at all.
> >   3a. Which two?
>
> a.  Miners destroying the sidechain because the sidechain is no longer
> viable.
> b.  Aggregators of sidechain-to-minechain transfers and large whales.
>
> >   3b. How is everyone else, expected to move their coins from chain to
> chain?
>
> Cross-system atomic swaps.
> (I use "System" here since the same mechanism works for Lightning
> channels, and channels are not blockchains.)
>
> >   3c. (Obviously, this improves UX.) But why does it also improve
> security?
>
> Drivechain-based pegged transfers are aggregates of many smaller transfers
> and thus every transfer out from the sidechain contributes its "fee" to the
> security of the peg.
>
> > --
> > 4. What do the parameters b and m stand for (in the DC security model)?
>
> m is how much people want to kill a sidechain, 0 = everybody would be sad
> if it died and would rather burn all their BTC forever than continue
> living, 1 = do not care, > 1 people want to actively kill the sidechain.
>
> b is how much profit a mainchain miner expects from supporting a sidechain
> (do not remember the unit though).
> Something like u = a + b where a is the mainchain, b is the sidechain, u
> is the total profit.
> Or fees?  Something like that.
>
> > 5. How can m possibly be above 1? Give an example of a
> sidechain-attribute which may cause this situation to arise.
>
> The sidechain is a total scam.
> A bug may be found in the sidechain that completely negates any security
> it might have, thus removing any desire to protect the sidechain and
> potentially make users want to destroy it completely rather than let it
> continue.
> People end up hating sidechains completely.
>
> > 6. For which range of m, is DC designed to deter sc-theft?
>
> m <= 1
>
> > 7. If DC could be changed to magically deter theft across all ranges of
> m, why would that be bad for sidechain users in general?
>
> Because the sidechain would already be part of mainchain consensus.
>
> > --
> > 8. If imminent victims of a DC-based theft, used a mainchain UASF to
> prohibit the future theft-withdrawal, then how would this affect non-DC
> users?
>
> If the non-DC users do not care, then they are unaffected.
> If the non-DC users want to actively kill the sidechain, they will
> counterattack with an opposite UASF and we have a chainsplit and sadness
> and mutual destruction and death and a new subreddit.
>
> > 9. In what ways might the BTC network one day become uncompetitive? And
> how is this different from caring about a sidechain's m and b?
>
> If it does not enable scaling technology fast enough to actually be able
> to enable hyperbitcoinization.
>
> Sidechains are not a scaling solution, so caring about m and b is
> different because your focus is not on scaling.
>
> > --
> > 10. If DC were successful, Altcoin-investors would be harmed. Two
> Maximalist-groups would also be slightly harmed -- who are these?
>
> Dunno!
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5850 bytes --]

 permalink raw reply	[|nested]
2022-02-26  7:39   ` ZmnSCPxj
  2022-02-26 14:58     ` Billy Tetrud

  
From: Paul Sztorc @ 2022-02-27  0:42 UTC ( / )
  To: Bitcoin Protocol Discussion;  lightning-dev\\@lists.linuxfoundation.org

Not bad, but not particularly good either.

Definitely correct:
   1  (plus extra credit, it was originally 1008+2016),
   3a "whales"
   3b (atomic swaps is the "official" answer, but otc trading is also 
acceptable, or just "trade" in general)
   6
   9  part one

Close, but not quite right:
   2  (part one "~4" is correct, but you didn't answer part two)
   3a "attacker- miners" is not the way I see it at all
   3c true, but I was talking about withdrawal security, not hashrate, 
[this is related to the 3a "attacker miners" mis-answer]
   4  ? you seem to have not very seriously answered this. The 
parameters are spelled out in the original Nov 2015 post

Some kind of miscommunication may have happened:
   8 -- I was more thinking, what happens if the UASF fails (in 
thwarting miners) vs succeeds. (I take it for granted that non-DC users 
will prefer to do nothing, and prefer to be unaffected.)

Seems wrong to me:
   0  seems like a pretty big misunderstanding happened here, or else 
you mistakenly typo'd the wrong word
   5  (you started with m=1 examples, which is not what was requested; 
and finished with something not a sidechain attribute)
   7  [related to the miss on #5] ; it is not a re-ask of question #0
   9  part two is wrong
  10  you did not answer

Paul


On 2/26/2022 2:39 AM, ZmnSCPxj wrote:
> Good morning Paul,
>
>
>> I don't think I can stop people from being ignorant about Drivechain. But I can at least allow the Drivechain-knowledgable to identify each other.
>>
>> So here below, I present a little "quiz". If you can answer all of these questions, then you basically understand Drivechain:
>>
>> 0. We could change DC to make miner-theft impossible, by making it a layer1 consensus rule that miners never steal. Why is this cure worse than the disease?
> Now miners are forced to look at all sideblocks, not optionally do so if it is profitable for them.
>
>> 1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly as possible*, how long would this take (in blocks)?
> 13,150 (I think this is how you changed it after feedback from this list, I think I remember it was ~3000 before or thereabouts.)
>
>> 2. Per sidechain per year (ie, per 52560 blocks), how many DC withdrawals can take place (maximum)? How many can be attempted?
>>       (Ie, how does the 'train track metaphor' work, from ~1h5m in the "Overview and Misconceptions" video)?
> I hate watching videos, I can read faster than anyone can talk (except maybe Laolu, he speaks faster than I can process, never mind read).
>
> ~4 times (assuming 52560 block per year, which may vary due to new miners, hashrate drops, etc)
>
>> 3. Only two types of people should ever be using the DC withdrawal system at all.
>>    3a. Which two?
> a.  Miners destroying the sidechain because the sidechain is no longer viable.
> b.  Aggregators of sidechain-to-minechain transfers and large whales.
>
>>    3b. How is everyone else, expected to move their coins from chain to chain?
> Cross-system atomic swaps.
> (I use "System" here since the same mechanism works for Lightning channels, and channels are not blockchains.)
>
>>    3c. (Obviously, this improves UX.) But why does it also improve security?
> Drivechain-based pegged transfers are aggregates of many smaller transfers and thus every transfer out from the sidechain contributes its "fee" to the security of the peg.
>
>> --
>> 4. What do the parameters b and m stand for (in the DC security model)?
> m is how much people want to kill a sidechain, 0 = everybody would be sad if it died and would rather burn all their BTC forever than continue living, 1 = do not care, > 1 people want to actively kill the sidechain.
>
> b is how much profit a mainchain miner expects from supporting a sidechain (do not remember the unit though).
> Something like u = a + b where a is the mainchain, b is the sidechain, u is the total profit.
> Or fees?  Something like that.
>
>> 5. How can m possibly be above 1? Give an example of a sidechain-attribute which may cause this situation to arise.
> The sidechain is a total scam.
> A bug may be found in the sidechain that completely negates any security it might have, thus removing any desire to protect the sidechain and potentially make users want to destroy it completely rather than let it continue.
> People end up hating sidechains completely.
>
>> 6. For which range of m, is DC designed to deter sc-theft?
> m <= 1
>
>> 7. If DC could be changed to magically deter theft across all ranges of m, why would that be bad for sidechain users in general?
> Because the sidechain would already be part of mainchain consensus.
>
>> --
>> 8. If imminent victims of a DC-based theft, used a mainchain UASF to prohibit the future theft-withdrawal, then how would this affect non-DC users?
> If the non-DC users do not care, then they are unaffected.
> If the non-DC users want to actively kill the sidechain, they will counterattack with an opposite UASF and we have a chainsplit and sadness and mutual destruction and death and a new subreddit.
>
>> 9. In what ways might the BTC network one day become uncompetitive? And how is this different from caring about a sidechain's m and b?
> If it does not enable scaling technology fast enough to actually be able to enable hyperbitcoinization.
>
> Sidechains are not a scaling solution, so caring about m and b is different because your focus is not on scaling.
>
>> --
>> 10. If DC were successful, Altcoin-investors would be harmed. Two Maximalist-groups would also be slightly harmed -- who are these?
> Dunno!
>
>
> Regards,
> ZmnSCPxj