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 E2083C002D for ; Sat, 4 Jun 2022 15:44:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id C307D60774 for ; Sat, 4 Jun 2022 15:44:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=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=gazeta.pl 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 lEieuVr7LFDa for ; Sat, 4 Jun 2022 15:44:06 +0000 (UTC) X-Greylist: delayed 00:10:11 by SQLgrey-1.8.0 Received: from smtpo43.poczta.onet.pl (smtpo43.poczta.onet.pl [213.180.142.174]) by smtp3.osuosl.org (Postfix) with ESMTPS id 891B160773 for ; Sat, 4 Jun 2022 15:44:06 +0000 (UTC) Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4LFkLK0bbVzlkG; Sat, 4 Jun 2022 17:33:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1654356825; bh=AncNibWsGZkl0Er4pL/GTX1P7wM9lkxI0acbz5mPxYk=; h=From:To:Date:Subject:From; b=eRhWYzouFRBgBQZetU7SyYzXUsFYSKfnZglBY7FQuAovnALnYAdoLT7m8GOscsQyl ray/77Wlahd9tFx7xhuySDS9P8veTPSacoGJKYTXyacw45HWd6LCNs3MpRyIdDl7NT 3n+pS1UkDIFDKUZRv0MRV/wvj00EjSVSSPzTxbbU= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.233.24] by pmq3v.m5r2.onet via HTTP id ; Sat, 04 Jun 2022 17:33:45 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: "bitcoin-dev@lists.linuxfoundation.org" , "truthcoin@gmail.com" Date: Sat, 04 Jun 2022 17:33:43 +0200 Message-Id: <162963804-b06af81ec3655f4e1950de9136310c7a@pmq3v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.233.24;PL;2 X-Mailman-Approved-At: Sat, 04 Jun 2022 16:07:05 +0000 Subject: [bitcoin-dev] Using Merged Mining on a separate zero supply chain, instead of sidechains 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, 04 Jun 2022 15:44:08 -0000 Some people think that sidechains are good. But to put them into some worki= ng solution, people think that some kind of soft-fork is needed. However, i= t seems that it can be done in a no-fork way, here is how to make it permis= sionless, and introduce them without any forks. First, we should make a new chain that has zero coins. When the coin supply= is zero, it can be guaranteed that this chain is not generating any coins = out of thin air. Then, all that is needed, is to introduce coins to this ch= ain, just by signing a transaction from other chains, for example Bitcoin. = In this way, people can make signatures in a signet way, just to sign their= transaction output of any type, without moving real coins on the original = chain. Then, all that is needed, is to make a way to withdraw the coins. It could = be done by publishing the transaction from the original chain. It can be co= py-pasted to our chain, and can be used to destroy coins that were produced= earlier. In this way, our Merge-Mined chain has zero supply, and can only = temporary store some coins from other chains. Creating and destroying coins from other chains is enough to make a test ne= twork. To make it independent, one more thing is needed, to get a mainnet s= olution: moving coins inside that chain. When it comes to that, the only li= mitation is the locking script. Normally, it is locked to some public key, = then by forming a signature, it is possible to move coins somewhere else. I= n the Lightning Network, it is solved by forming 2-of-2 multisig, then coin= s can be moved by changing closing transactions. But there is another option: transaction joining. So, if we have a chain of= transactions: A->B->C->...->Z, then if transaction joining is possible, it= can be transformed into A->Z transaction. After adding that missing piece,= sidechains can be enabled. However, I mentioned before that this solution would require no forks. It c= ould, if we consider using Homomorphic Encryption. Then, it is possible to = add new features, without touching consensus. For example, by using Homomor= phic Encryption, it is possible to execute 2-of-2 multisig on some P2PK out= put. That means, more things are possible, because if we can encrypt things= , then operate on encrypted data, and later decrypt it (and broadcast to th= e network), then it can open a lot of new possible upgrades, that will be t= otally permissionless and unstoppable. So, to sum up: by adding transaction joining in a homomorphic-encryption-wa= y, it may be possible to introduce sidechains in a no-fork way, no matter i= f people wants that or not. Also, it is possible to add the hash of our cha= in to the signature inside a Bitcoin transaction, then all data from the "z= ero supply chain" can be committed to the Bitcoin blockchain, that would pr= event overwriting history. Also, Merged Mining could be used to reward side= chain miners, so they will be rewarded inside the sidechain.