path: root/bf/9bbc03353815bd87a3da0473e18b1201c098e7

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A8695C001A;
 Sat, 26 Feb 2022 14:58:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 90D0583E60;
 Sat, 26 Feb 2022 14:58:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 27WzfpUffRCj; Sat, 26 Feb 2022 14:58:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [IPv6:2a00:1450:4864:20::529])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 3FFFE83E5E;
 Sat, 26 Feb 2022 14:58:26 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id m3so11229465eda.10;
 Sat, 26 Feb 2022 06:58:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=KiNtiXWbyJ3B61WsQykOEIxGr82aCC6ckr+/P4s+qss=;
 b=UlGjCsekHKLx+mPfASUhMPldqWfzsvZUoMeFBUcrWMZQOFpDYZjTpSuasbHCpoF8am
 I3BbQ5TGoETsJZBQPXI9kTAejVU9THPiJtzWqJoEs0vOpCPCthJ2gAozK/NiLqiRnvST
 ahP/r++KcKGWcH/tZsHXmXj4WOoPE9S/gv/JkyCQVgDoJ3HF/gKh7IgholyTIXBqstlM
 aHDjQ0I9YUJpo2kzH9bt5yXTwmDIUZcwzRCR47I/FjQ5nTCjUdGOhfUbWRgf8O35mVAr
 Cp2HTO0AARZjoLM/SBz6unaYCFeyhLFmymPRTXNXLb2f6qrYKRdVO3L6y8ABc0BiELkz
 nNdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=KiNtiXWbyJ3B61WsQykOEIxGr82aCC6ckr+/P4s+qss=;
 b=Mz2Is81ht71AB9Q8wvi9OtPnyQbPRZV+7vGskNIcq/3UyeRZI+tNQstuEgHMfkRiRx
 Cbe6KmqudpAAXbIl97QLf208Nx3ou3W2OrpoCQ8BYNn6wgs9dEdjavst05iHCvcydtrT
 GfinhBPMr/LZJCHk3ux9TQrItH62arPNfLkAtOXqSOiJNgoUotMD2ovrPdY7wm0sXMin
 Ju+5ynGOrvdi+LpMJvlC1I35YbNn8UsePqq0Rzg1d6Cxl4ruVy6DLu1RwFlThU1bUlWg
 pnTYGQXCV0nd4U9ICpsVPMCu6bzSYg7wYCn+aAoFOxIWcY5T0NSHutsJCgiAnFH9MoFW
 PZfw==
X-Gm-Message-State: AOAM531oHrw3kuWKaz7is/HA3gFjkgI5yBdNQKrJeo1+dAlggteq1Z71
 W0C2KXG5NyJTKUe2b+x2EKx3UthOcqL3pijr18GFwoWi
X-Google-Smtp-Source: ABdhPJyw6TJGtnOXPorBp7ntF4z424GnXUWsdlZ92Wg30sWEelIpTdORadkTeIMCcuaq/RDDyDibENy/fXfqiNOAHMo=
X-Received: by 2002:a50:fb91:0:b0:408:5100:b4a7 with SMTP id
 e17-20020a50fb91000000b004085100b4a7mr11514383edq.311.1645887504122; Sat, 26
 Feb 2022 06:58:24 -0800 (PST)
MIME-Version: 1.0
References: <qfzN-NoT0oDddySCNEPQLaJaEqS56rBGxhD9HKvK6Z6qmdfRBUeeE3GGGpzlZSvwmEZbsL-FEitNm6J_LXKaKfIqlqPPCJ9I_CU2SsY1J8c=@protonmail.com>
 <a047803b-0402-895d-f482-750a0dd24716@gmail.com>
 <M6pN0qkZsl6BUonPHbqh9XQNpOnGoywK_muHcMu7Uwtzb1cYyxXaS6T7U1TJ69yf_s95Os3wGq58Ibct5KdGc35gXXB80kDXNJNW7Yb2nc8=@protonmail.com>
In-Reply-To: <M6pN0qkZsl6BUonPHbqh9XQNpOnGoywK_muHcMu7Uwtzb1cYyxXaS6T7U1TJ69yf_s95Os3wGq58Ibct5KdGc35gXXB80kDXNJNW7Yb2nc8=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sat, 26 Feb 2022 08:58:12 -0600
Message-ID: <CAGpPWDY06oAoVeVR8b=T_a6Yzpxstj3Sx-m_TP__cKg+q-ygoA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000006071905d8ed0ca0"
X-Mailman-Approved-At: Sat, 26 Feb 2022 15:35:23 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Feb 2022 14:58:27 -0000

--00000000000006071905d8ed0ca0
Content-Type: text/plain; charset="UTF-8"

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

--00000000000006071905d8ed0ca0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">&gt;=C2=A0<span style=3D"font-size:12.8px">m is how much =
people want to kill a sidechain, 0 =3D everybody would be sad if it died an=
d would rather burn all their BTC forever than continue living</span><div d=
ir=3D"auto"><span style=3D"font-size:12.8px"><br></span></div><div dir=3D"a=
uto"><span style=3D"font-size:12.8px">Math is brutal</span></div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Fe=
b 26, 2022, 01:39 ZmnSCPxj via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><br>
Good morning Paul,<br>
<br>
<br>
&gt; I don&#39;t think I can stop people from being ignorant about Drivecha=
in. But I can at least allow the Drivechain-knowledgable to identify each o=
ther.<br>
&gt;<br>
&gt; So here below, I present a little &quot;quiz&quot;. If you can answer =
all of these questions, then you basically understand Drivechain:<br>
&gt;<br>
&gt; 0. We could change DC to make miner-theft impossible, by making it a l=
ayer1 consensus rule that miners never steal. Why is this cure worse than t=
he disease?<br>
<br>
Now miners are forced to look at all sideblocks, not optionally do so if it=
 is profitable for them.<br>
<br>
&gt; 1. If 100% hashrate wanted to steal coins from a DC sidechain *as quic=
kly as possible*, how long would this take (in blocks)?<br>
<br>
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.)<br>
<br>
&gt; 2. Per sidechain per year (ie, per 52560 blocks), how many DC withdraw=
als can take place (maximum)? How many can be attempted?<br>
&gt;=C2=A0 =C2=A0 =C2=A0 (Ie, how does the &#39;train track metaphor&#39; w=
ork, from ~1h5m in the &quot;Overview and Misconceptions&quot; video)?<br>
<br>
I hate watching videos, I can read faster than anyone can talk (except mayb=
e Laolu, he speaks faster than I can process, never mind read).<br>
<br>
~4 times (assuming 52560 block per year, which may vary due to new miners, =
hashrate drops, etc)<br>
<br>
&gt; 3. Only two types of people should ever be using the DC withdrawal sys=
tem at all.<br>
&gt;=C2=A0 =C2=A03a. Which two?<br>
<br>
a.=C2=A0 Miners destroying the sidechain because the sidechain is no longer=
 viable.<br>
b.=C2=A0 Aggregators of sidechain-to-minechain transfers and large whales.<=
br>
<br>
&gt;=C2=A0 =C2=A03b. How is everyone else, expected to move their coins fro=
m chain to chain?<br>
<br>
Cross-system atomic swaps.<br>
(I use &quot;System&quot; here since the same mechanism works for Lightning=
 channels, and channels are not blockchains.)<br>
<br>
&gt;=C2=A0 =C2=A03c. (Obviously, this improves UX.) But why does it also im=
prove security?<br>
<br>
Drivechain-based pegged transfers are aggregates of many smaller transfers =
and thus every transfer out from the sidechain contributes its &quot;fee&qu=
ot; to the security of the peg.<br>
<br>
&gt; --<br>
&gt; 4. What do the parameters b and m stand for (in the DC security model)=
?<br>
<br>
m is how much people want to kill a sidechain, 0 =3D everybody would be sad=
 if it died and would rather burn all their BTC forever than continue livin=
g, 1 =3D do not care, &gt; 1 people want to actively kill the sidechain.<br=
>
<br>
b is how much profit a mainchain miner expects from supporting a sidechain =
(do not remember the unit though).<br>
Something like u =3D a + b where a is the mainchain, b is the sidechain, u =
is the total profit.<br>
Or fees?=C2=A0 Something like that.<br>
<br>
&gt; 5. How can m possibly be above 1? Give an example of a sidechain-attri=
bute which may cause this situation to arise.<br>
<br>
The sidechain is a total scam.<br>
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 potentia=
lly make users want to destroy it completely rather than let it continue.<b=
r>
People end up hating sidechains completely.<br>
<br>
&gt; 6. For which range of m, is DC designed to deter sc-theft?<br>
<br>
m &lt;=3D 1<br>
<br>
&gt; 7. If DC could be changed to magically deter theft across all ranges o=
f m, why would that be bad for sidechain users in general?<br>
<br>
Because the sidechain would already be part of mainchain consensus.<br>
<br>
&gt; --<br>
&gt; 8. If imminent victims of a DC-based theft, used a mainchain UASF to p=
rohibit the future theft-withdrawal, then how would this affect non-DC user=
s?<br>
<br>
If the non-DC users do not care, then they are unaffected.<br>
If the non-DC users want to actively kill the sidechain, they will countera=
ttack with an opposite UASF and we have a chainsplit and sadness and mutual=
 destruction and death and a new subreddit.<br>
<br>
&gt; 9. In what ways might the BTC network one day become uncompetitive? An=
d how is this different from caring about a sidechain&#39;s m and b?<br>
<br>
If it does not enable scaling technology fast enough to actually be able to=
 enable hyperbitcoinization.<br>
<br>
Sidechains are not a scaling solution, so caring about m and b is different=
 because your focus is not on scaling.<br>
<br>
&gt; --<br>
&gt; 10. If DC were successful, Altcoin-investors would be harmed. Two Maxi=
malist-groups would also be slightly harmed -- who are these?<br>
<br>
Dunno!<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000006071905d8ed0ca0--