public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Paul Sztorc <truthcoin@gmail•com>
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	"lightning-dev\\@lists.linuxfoundation.org"
	<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers
Date: Thu, 24 Feb 2022 16:39:40 -0500	[thread overview]
Message-ID: <a047803b-0402-895d-f482-750a0dd24716@gmail.com> (raw)
In-Reply-To: <qfzN-NoT0oDddySCNEPQLaJaEqS56rBGxhD9HKvK6Z6qmdfRBUeeE3GGGpzlZSvwmEZbsL-FEitNm6J_LXKaKfIqlqPPCJ9I_CU2SsY1J8c=@protonmail.com>

[-- 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 --]

  reply	other threads:[~2022-02-24 21:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-24 12:49 ZmnSCPxj
2022-02-24 21:39 ` Paul Sztorc [this message]
2022-02-26  7:39   ` ZmnSCPxj
2022-02-26 14:58     ` Billy Tetrud
2022-02-27  0:42     ` Paul Sztorc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a047803b-0402-895d-f482-750a0dd24716@gmail.com \
    --to=truthcoin@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=lightning-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox