Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0CC5FC0011; Thu, 24 Feb 2022 21:39:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id EDA93402E7; Thu, 24 Feb 2022 21:39:44 +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: 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 jf3E-Xewx_vE; Thu, 24 Feb 2022 21:39:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) by smtp4.osuosl.org (Postfix) with ESMTPS id 12BF740183; Thu, 24 Feb 2022 21:39:43 +0000 (UTC) Received: by mail-qt1-x82c.google.com with SMTP id f18so761855qtb.3; Thu, 24 Feb 2022 13:39:43 -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 :references:from:subject:in-reply-to; bh=wfumZgQIkWy8tBUdn1kxVbuBs7wIENmDNnnmcIP+4TI=; b=KyvjRrnBz+qMHD8HIILI9ZrBcvIPjPaVjKJ0MK5/+koF/paZnHtJKUihCiUfvh/5F8 o45OtVR2A4GmgRcDHsc/bn4XaftaH3fxxK3GdrgB2LhXyW9lFaJEEaGj6Filf8B/ZiA5 iKq5ZJnbddWqWF83xJqDGp+Q3kZo1qvl29h6dQtq/rxiyvtJw0/mRWTiuRC/UFHXYIqg 5mxgWxGK9feG6+oC23zb0yUeUu07O9ceVgZz5oqvdTGqZHeizwAC5tOb56pNtDjVBQJk MTDu8JS7ASuaEsT6iTUdI/3emPPRQGoJoimUbxWwE28OvLwNp78kz8ZbJFIrZNyZY/AN SVyg== 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:references:from:subject:in-reply-to; bh=wfumZgQIkWy8tBUdn1kxVbuBs7wIENmDNnnmcIP+4TI=; b=kz3dz6sB/bRGdKggcqeOm35sTj+wNC5uOUJNs25INR5vRhRgef/SP84T1EH7vr0uh4 STIR6oqcezZYtH30W4SmqjMm0K/zHw07ycSsNO+wcMsW8Z5W/mvjByxzgZhOZjqbWatz 4l3lE72CKaReG2fOSdoKB3IfWw2K27NnFSgCYB0a73gz3dH76DY9XOaWawLH0Nq4heyP EeoXgOt5C5HcH4SXg78IxgQP1pkzA3+S0a+ZBhBsfFuEfhFLDu1stL2Kkrj+MBeloHtc SD0DrlcElB4fjloOx6tnF497eLKlk4Hhd9/chHPObvtlLVL1rFrvyzbRHB4BK02lmp+Q RDag== X-Gm-Message-State: AOAM531oy3YsOEXfZ8aWyJUKmrDcWNWx61U+DFxhzNAaNe5I27zAHKGN 34G4vd0eX8XvqHtYgu8sSNtW10jzrbQ= X-Google-Smtp-Source: ABdhPJzRhlgT0xHm5wv0e4cMvOzP58zXcTjnVyGI6+UMfb+vlVr6Ah+viLzhLh4YfPeNVgHVoD3ncQ== X-Received: by 2002:a05:622a:646:b0:2de:8dcb:95a0 with SMTP id a6-20020a05622a064600b002de8dcb95a0mr4340166qtb.206.1645738782381; Thu, 24 Feb 2022 13:39:42 -0800 (PST) Received: from [192.168.0.165] (ool-45714b6d.dyn.optonline.net. [69.113.75.109]) by smtp.googlemail.com with ESMTPSA id m2-20020ae9e002000000b0050819df7151sm369342qkk.99.2022.02.24.13.39.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Feb 2022 13:39:42 -0800 (PST) Content-Type: multipart/alternative; boundary="------------yJMl0nvCg1Ivscy9UpymGhIp" Message-ID: Date: Thu, 24 Feb 2022 16:39:40 -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 , "lightning-dev\\@lists.linuxfoundation.org" References: From: Paul Sztorc In-Reply-To: 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: Thu, 24 Feb 2022 21:39:45 -0000 This is a multi-part message in MIME format. --------------yJMl0nvCg1Ivscy9UpymGhIp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------yJMl0nvCg1Ivscy9UpymGhIp Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
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
--------------yJMl0nvCg1Ivscy9UpymGhIp--