Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D955BC001A; Sun, 27 Feb 2022 00:42:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id D208440986; Sun, 27 Feb 2022 00:42:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 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_FMBLA_NEWDOM=1.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qb3K-WwOIOVN; Sun, 27 Feb 2022 00:42:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) by smtp4.osuosl.org (Postfix) with ESMTPS id 120DE40946; Sun, 27 Feb 2022 00:42:25 +0000 (UTC) Received: by mail-qt1-x82a.google.com with SMTP id f18so5976259qtb.3; Sat, 26 Feb 2022 16:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:cc :references:from:subject:in-reply-to:content-transfer-encoding; bh=OmSu3q45H2lDVe++qPkCDrZVG7fmffWTLxi61W3gELY=; b=dHs2RGznK8FoMMouw5/YVacDEfxdBMR9Qe77j/vDPQE17GOEsVAy8PP0UeomqX5OCh J2sbgk/HGs7lFE/fEfGDa4XoQQot+Y9dhnEpwLUGYH7ii8bB/0fVwpjzTCk9TdVpmAjA gRullYHQYQJ1m0e0INL1w16KvsvXaa02vihfgNgG2nRyMSVXirDQlvKTw25tj8+kMmmF s+YZjPFhlYkbt8oWw21Uoql2Y9J8/wxKFbZvBlzgZ8OA8PuW1bd2HDfa7tkGCmqLIDnY WKP4x9tWr/V3jmGXcZcg4VEw0fTFsg9Pag+cPmcy85kz+zkm4fseV/4Km0oU3PDBc0ZC UFFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=OmSu3q45H2lDVe++qPkCDrZVG7fmffWTLxi61W3gELY=; b=U6vZC91caYC1mY5gy0pOKqlcO6GSOm85D3lMr6nSgU2uiXiYBHl5m3HZS4xFUtR0je CXFkJ/56b2aWFPfRjugMfT6A1ustZD9FOIPjaWlqa/IcPRZZLdXM/1LMZfkkojQpSLH0 E0sebWGnKIc9VkbkmzFs2WKAmy6UfkuHVbGNxG7Xk6iZPLxz9wXMgGwqD4JVEb0reBnd uptDu4y+XpCrEJdR7Pmy3hv8PPJpwRaDP2gor6/iPyXYOZ0CMv2LoHipSgGg7GYmfDdV Q7o9URiYTxorAr0sGJUpz+MvP/F5tbwmohLA2z8EA2OK79Y3TcUG4lCgg47jpEocAwVo 2fZQ== X-Gm-Message-State: AOAM533aOuR/ovFfWI3uSSIvY0MBrmnZcZa+mE1TqOA3gQc688nK4r/l GYwVPUSABzM8G1fT8WlOfAd0+ELFp1U= X-Google-Smtp-Source: ABdhPJypa4vFnnbaI90HfxS/66GS+wv5liVimrqL3qeOxg+l6TV7mDTzTIHQcOfrM98Pof2Hin2Fsg== X-Received: by 2002:a05:622a:1356:b0:2df:bdb1:fbf3 with SMTP id w22-20020a05622a135600b002dfbdb1fbf3mr6750348qtk.407.1645922544490; Sat, 26 Feb 2022 16:42:24 -0800 (PST) Received: from [192.168.0.165] (ool-45714b6d.dyn.optonline.net. [69.113.75.109]) by smtp.googlemail.com with ESMTPSA id x12-20020ac85f0c000000b002de8931d4d6sm4227701qta.77.2022.02.26.16.42.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Feb 2022 16:42:24 -0800 (PST) Message-ID: <39992d10-fa91-daca-19a6-9f9840cacc76@gmail.com> Date: Sat, 26 Feb 2022 19:42:22 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.0 Content-Language: en-US To: Bitcoin Protocol Discussion References: From: Paul Sztorc In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Sun, 27 Feb 2022 00:42:26 -0000 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