From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id D53F3C000E for ; Thu, 2 Sep 2021 21:03:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id C848C606E3 for ; Thu, 2 Sep 2021 21:03:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 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_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jxc1eFDlL6HV for ; Thu, 2 Sep 2021 21:03:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) by smtp3.osuosl.org (Postfix) with ESMTPS id 452306075D for ; Thu, 2 Sep 2021 21:03:04 +0000 (UTC) Date: Thu, 02 Sep 2021 21:02:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1630616580; bh=6qLOdWwPcwQer5PDtDkfvsABqRltZ5zZftQfZrja0QY=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=fre9Fpp7VKQ3zr0OwISlo3DjLWgxbLRWdfEDci6Lwgv0zcQQsOwtb2uPewca3eUq5 KlR9AvXMThPyukWAmkvb4OQyQtE3N9Kja0lGI6/yisnDa+gEoIrF3tgeRtnTT85hYn EOHBDM7NdtRNczzZkX6TahyNIuFHKoHS1X2g0gAQ= To: Prayank , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <3dyAATLXbsE7WBzpVIc0s4sRkSFhR_5NN04uUgx3o9LH48IKR6EHL3V45PfpRM96yxHXdsjd7WC7MGuPlBw7MRpCkpXRsB-WI7i3-Nr13Ew=@protonmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Drivechain: BIP 300 and 301 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, 02 Sep 2021 21:03:06 -0000 Good morning Prayank, Just to be clear, neither Liquid nor RSK, as of my current knowledge, are D= rivechain systems. Instead, they are both federated sidechains. The money owned by a federated sidechain is, as far s the Bitcoin blockchai= n is concerned, really owned by the federation that.runs the sidechain. Basically, a mainchain->sidechain transfer is done by paying to a federatio= n k-of-n address and a coordination signal of some kind (details depending = on federated sidechain) to create the equivalent coins on the sidechain. A sidechain->mainchain transfer is done by requesting some coins on the sid= echain to be destroyed, and then the federation will send some of its mainc= hain k-of-n coins into whatever address you indicate you want to use on the= mainchain. In theory, a sufficient quorum of the federation can decide to ignore the s= idechain data entirely and spend the mainchain money arbitrarily, and the m= ainchain layer will allow this (being completely ignorant of he sidechain). In such federated sidechains, the federation is often a fixed predetermined= signing set, and changes to that federation are expected to be rare. Federated sidechains are ultimately custodial; as noted above, the federati= on could in theory abscond with the funds completely, and the mainchain wou= ld not care if the sidechain federation executes its final exit strategy an= d you lose your funds. One can consider federated sidechains to be a custodian with multiple perso= nality disorder, that happens to use a blockchain to keep its individual su= b-personalities coordinated with each other, but ultimately control of the = money is contingent on the custodian following the dictates of the supposed= owners of the coin. >From a certain point of view, it is actually immaterial that there is a sep= arate blockchain called the "sidechain" --- it is simply that a blockchain = is used to coordinate the custodians of the coin, but in principle any othe= r coordination mechanism can be used between them, including a plain databa= se. With Drivechains, custody of the sidechain funds is held by mainchain miner= s. Again, this is still a custodial setup. A potential issue here is that the mainchain miners cannot be identified (t= he entire point is anonymity of miners is possible), which may be of concer= n. In particular, note that solely on mainchain, all that miners determine is = the *ordering* and *timing* of transactions. Let us suppose that there is a major 51% attack attempt on the Bitcoin bloc= kchain. We expect that such an attack will be temporary --- individuals currently n= ot mining may find that their HODLings are under threat of the 51% attack, = and may find it more economic to run miners at a loss, in order to protect = their stacks rather than lose it. Thus, we expect that a 51% attack will be temporary, as other miners will a= rise inevitably to take back control of transaction processing. https://github.com/libbitcoin/libbitcoin-system/wiki/Threat-Level-Paradox In particular, on the mainchain, 51% miners cannot reverse deep history. If you have coins you have not moved since 2017, for example, the 51% attac= k is expected to take about 4 years before it can begin to threaten your ow= nership of those coins (hopefully, in those 4 years, you will get a clue an= d start mining at a loss to protect your funds from outright loss, thus hel= ping evict the 51% attacker). 51% miners can, in practice, only prevent transfers (censorship), not force= transfer of funds (confiscation). Once the 51% attacker is evicted (and they will in general be evicted), the= n coins you owned that were deeply confirmed remain under your control. With Drivechains, however, sidechain funds can be confiscated by a 51% atta= cker, by forcing a bogus sidechain->mainchain withdrawal. The amount of time it takes is simply the security parameter of the Drivech= ain spec. It does not matter if you were holding those funds in the sidechain for sev= eral years without moving them --- a 51% attacker that is able to keep cont= rol of the mainchain blockchain, for the Drivechain security parameter, wil= l be capable of confiscating sidechain funds outright. Thus, even if the 51% attacker is evicted, then your coins in the sidechain= can be confiscated and no longer under your control. Increasing the Drivechain security parameter leads to slower sidechain->mai= nchin withdrawals, effectively a bottleneck on how much can be transferred = sidechain->mainchain. While exchanges may exist that allow sidechain->mainchain withdrawal faster= , those can only operate if the number of coins exiting the sidechain is ap= proximately equal to coins entering the sidechain (remember, it is an *exch= ange*, coins are not actually moved from one to the other). If there is a "thundering herd" problem, then exchanges will saturate and t= he sidechain->mainchain withdrawal mechanism has to come into play, and if = the Drivechain security parameter (which secures sidechains from 51% attack= confiscation) In a "thundering herd" situation, the peg can be lost, meaning that sidecha= in coins become devalued relative to mainchain coins they are purportedly e= quivalent to. A "thundering herd" exiting the sidechain can happen, for example, if the s= idechain is primarily used to prototype a new feature, and the feature is d= emonstrably so desirable that Bitcoin Core actually adds it. In that case, the better security of the mainchain becomes desirable, and t= he sidechain no longer has a unique feature to incentivize keeping your fun= ds there (since mainchain has/will have that feature). In that case, the sidechain coin value can transiently drop due to the side= chain->mainchain withdrawal bottleneck caused by the Drivechain security pa= rameter. And if the value can temporarily drop, well, it is not much of a peg, then. * If the Drivechain security parameter is too low, then a short 51% attack = is enough to confiscate all sidechain coins. * If the Drivechain seucrity parameter is too large, then a coincidental la= rge number of sidechain->mainchain exits risks triggering a thundering herd= that temporarily devalues the sidechain value relative to mainchain. Against 51% attack confiscation, Paul Sztorc I believe proposes a "nuclear = option" where mainchain fullnodes are upgraded to ignore historical blocks = created by the 51% attacker. The point is that a 51% attacker takes on the risk that confiscation will s= imply cause everyone to evict all miners and possibly destroy Bitcoin entir= ely, and rational 51% attackers will not do so, since then their mining har= dware becomes useless. I believe this leads to a situation where a controversial chainsplit of a s= idechain can effectively "infect" mainchain, with competing mainchain miner= s with different views of the sidechain censoring each other, thus removing= isolation of the sidechain from the mainchain. -- More to the point: what are sidechains **for**? * If sidechains are for prototyping new features, then you are probably bet= ter off getting a bunch of developer friends together and creating a federa= tion that runs the sidechain so you can tinker on new features with friends= . * This is how SegWit was prototyped in Elements Alpha, the predecessor of= Liquid. * If sidechains are for scaling, then: * We already ***know*** that blockchains cannot scale. * Your plan for scaling is to make ***more*** blockchains? Which we know cannot scale, right? * Good luck. Now, if we were to consider scaling... As I pointed out above, in principle a federated sidechain simply decided t= o use a blockchain to coordinate the federation members. Nothing really prevents the federation from using a different mechanims. In addition, federations (whether signer federations like in RSK or Liquid,= or miner federations like in Drivechains) have custodial risk if you put y= our funds in them. The only way to avoid the custodial risk is if ***you*** were one of the si= gnatories of the federation, and the federation was an n-of-n. Now, let us consider a 2-of-2 federation, the smallest possible federation. As long as *you* are one of the two signatories, you have no custodial risk= in putting funds in this federation --- nothing can happen to the mainchai= n funds without your say-so, so the federation cannot confiscate your funds= . And again, there is no real need to use a big, inefficient data structure l= ike a **blockchain**. In fact, in a 2-of-2 federation, there are only two members, so a lot of th= e blockchain overhead can be reduced to just a bunch of fairly simple proto= col messages you send to each other, no need for a heavy history-retaining = append-only data structure. Of course, only you and the other signatory in this 2-of-2 federation can s= afely keep funds in that federation. You cannot pay a third party with those funds, because that third party now= takes on custodial risk, you and your coutnerparty can collude to steal th= e funds of the third party. However, suppose your counterparty was a member of another 2-of-2 federatio= n, this time with the third party you want to pay. You can use an atomic swap mechanism of some kind so that you pay your cout= erparty if that couterparty pays the third party. And guess what? That is just Lightning Network. Regards, ZmnSCPxj