From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6B760C001A; Sat, 26 Feb 2022 07:39:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 58B9182FEA; Sat, 26 Feb 2022 07:39:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 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, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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=protonmail.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 WiXk5WiZlZX6; Sat, 26 Feb 2022 07:39:43 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.osuosl.org (Postfix) with ESMTPS id 585B882F31; Sat, 26 Feb 2022 07:39:43 +0000 (UTC) Date: Sat, 26 Feb 2022 07:39:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1645861180; bh=XCVZVqoMWvC8+TZKjGvlNb49l4NDA4u3KWP+fvnSBds=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=biFZTrlfhkD4CQ6hVdAYH4mm0DT6vzn5Ifep0ZKb0b/RM3vdpDp31PffdrJCDB3rL KBLX3w0EfMcajbQyMiAxvQMX5hQKtyiFdA+uj0HNRaa7qWrWdPEHTcyt4eDdP46ZLh qQfagfcAnUzXQaBQzXU1xozWTHavG+nYm8YbkKduAEmOW2ypnG+8U1oxmZoPIc/6cw jnz4gFIw2I2syhTGWw6GbEezTNdyTLiBjPPiDehOd+s1B0qvLRwZnMUxHFyUoawX+j 8qC63Jg0tF2Ge/8IpD513szNeeoTrP9D/19hHwAMM6/mlc08blkP+DUGZaSUat5UxT TRt/9/QDE4WLQ== To: Paul Sztorc , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 07:39:44 -0000 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 laye= r1 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 "Ov= erview and Misconceptions" video)? 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). ~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 viab= le. b. Aggregators of sidechain-to-minechain transfers and large whales. > 3b. How is everyone else, expected to move their coins from chain to ch= ain? 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 securit= y? 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 =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, > 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 =3D 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-attribut= e 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 potentia= lly 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 <=3D 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 proh= ibit 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 countera= ttack 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 h= ow 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 Maximal= ist-groups would also be slightly harmed -- who are these? Dunno! Regards, ZmnSCPxj