From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 812D2C002D for ; Sun, 5 Jun 2022 16:37:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 6D2DC842F9 for ; Sun, 5 Jun 2022 16:37:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 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, 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 keGmd-jxS14O for ; Sun, 5 Jun 2022 16:37:28 +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 smtp1.osuosl.org (Postfix) with ESMTPS id 44DF7841B3 for ; Sun, 5 Jun 2022 16:37:28 +0000 (UTC) Date: Sun, 05 Jun 2022 16:37:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1654447046; x=1654706246; bh=6pwwN2NfQS9UMJRdcjM90hzk6Ng+B7D1BaLiZg+0Vl4=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=OX06MxX/r02OqMa4mvz2aq2h6Ec57u/AFbs8kOwOA6gV9Hcx9tkpwRXN9NfeLAk0n F/932Jo8YWvJ3p0Gx7FjWCUXIE9o3Jtp+2vR238N95Fg4krRo7jbwmJGefbEvg8nBH NXVkzKT5pwpDNrFEdAH2lJGA7zdj7bEQEmmPDToL7ZvHr39BgbuHVMkSyg0wYNXjM0 4VSibNzR7d50pm29+WBnGkYEdfoyEqo00nebS4jNIPbM3TrfCPTOu528m14l4UHUpH 8fOboqwoKLis8kK682eH9wYCM/cqr8jErWbnKpfaI2NU0MuFdnska/vroAQomkAjNe 24UBxSfGrdOJA== To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <_Wxebx3JnH8Rt96A6OJjHaGDvElF_k7ezcQBFbdJ--fITmbuiv7dhg84ie4lSfLaf9OchIexAjs1bnltz5jagajhlQoqX_-aAhN6abpvVJ8=@protonmail.com> In-Reply-To: <162963804-b06af81ec3655f4e1950de9136310c7a@pmq3v.m5r2.onet> References: <162963804-b06af81ec3655f4e1950de9136310c7a@pmq3v.m5r2.onet> Feedback-ID: 2872618:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [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: Sun, 05 Jun 2022 16:37:29 -0000 Good morning vjudeu, > Some people think that sidechains are good. But to put them into some wor= king solution, people think that some kind of soft-fork is needed. However,= it seems that it can be done in a no-fork way, here is how to make it perm= issionless, and introduce them without any forks. > > First, we should make a new chain that has zero coins. When the coin supp= ly is zero, it can be guaranteed that this chain is not generating any coin= s out of thin air. Then, all that is needed, is to introduce coins to this = chain, 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 the= ir transaction output of any type, without moving real coins on the origina= l chain. > > Then, all that is needed, is to make a way to withdraw the coins. It coul= d be done by publishing the transaction from the original chain. It can be = copy-pasted to our chain, and can be used to destroy coins that were produc= ed earlier. In this way, our Merge-Mined chain has zero supply, and can onl= y temporary store some coins from other chains. > > Creating and destroying coins from other chains is enough to make a test = network. To make it independent, one more thing is needed, to get a mainnet= solution: moving coins inside that chain. When it comes to that, the only = limitation 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.= In the Lightning Network, it is solved by forming 2-of-2 multisig, then co= ins 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 piec= e, sidechains can be enabled. > > > However, I mentioned before that this solution would require no forks. It= could, if we consider using Homomorphic Encryption. Then, it is possible t= o add new features, without touching consensus. For example, by using Homom= orphic Encryption, it is possible to execute 2-of-2 multisig on some P2PK o= utput. That means, more things are possible, because if we can encrypt thin= gs, then operate on encrypted data, and later decrypt it (and broadcast to = the network), then it can open a lot of new possible upgrades, that will be= totally permissionless and unstoppable. > > So, to sum up: by adding transaction joining in a homomorphic-encryption-= way, it may be possible to introduce sidechains in a no-fork way, no matter= if people wants that or not. Also, it is possible to add the hash of our c= hain to the signature inside a Bitcoin transaction, then all data from the = "zero supply chain" can be committed to the Bitcoin blockchain, that would = prevent overwriting history. Also, Merged Mining could be used to reward si= dechain miners, so they will be rewarded inside the sidechain. I proposed something similar years ago --- more specifically, some kind of = general ZKP system would allow us to pretty much write anything, and if it = terminates, we can provide a ZKP of the execution trace. At the time it was impractical due to the ZKP systems of the time being *st= ill* too large and too CPU-heavy *and* requiring a tr\*sted setup. Encrypting the amount in a homomorphic encryption such as Pedersen commitme= nts / ElGamal commitments is how MimbleWimble coins (such as Grin) work. They achieve transactional cut-through in a similar manner due to the homom= orphic encryption being what is validated by validators without revealing t= he exact balances, and with the only requirement being that a set of consum= ed outputs equals the set of created outputs (fees being an explicit output= that has no encryption, and thus can be claimable by anyone and have a kno= wn value, which basically means that it is the miner that mines the transac= tion that can claim it). Regards, ZmnSCPxj Regards, ZmnSCPxj