public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: "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: Sat, 26 Feb 2022 08:58:12 -0600	[thread overview]
Message-ID: <CAGpPWDY06oAoVeVR8b=T_a6Yzpxstj3Sx-m_TP__cKg+q-ygoA@mail.gmail.com> (raw)
In-Reply-To: <M6pN0qkZsl6BUonPHbqh9XQNpOnGoywK_muHcMu7Uwtzb1cYyxXaS6T7U1TJ69yf_s95Os3wGq58Ibct5KdGc35gXXB80kDXNJNW7Yb2nc8=@protonmail.com>

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

  reply	other threads:[~2022-02-26 14:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-24 12:49 [bitcoin-dev] A Comparison Of LN and Drivechain Security In The Presence Of 51% Attackers ZmnSCPxj
2022-02-24 21:39 ` Paul Sztorc
2022-02-26  7:39   ` ZmnSCPxj
2022-02-26 14:58     ` Billy Tetrud [this message]
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='CAGpPWDY06oAoVeVR8b=T_a6Yzpxstj3Sx-m_TP__cKg+q-ygoA@mail.gmail.com' \
    --to=billy.tetrud@gmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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