From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5D1DEC016F for ; Fri, 26 Jun 2020 00:57:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 40C1187E97 for ; Fri, 26 Jun 2020 00:57:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2Vnv8b3ec7a for ; Fri, 26 Jun 2020 00:57:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by whitealder.osuosl.org (Postfix) with ESMTPS id D8FAA87E96 for ; Fri, 26 Jun 2020 00:57:24 +0000 (UTC) Date: Fri, 26 Jun 2020 00:57:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1593133042; bh=NeHyCQMiAHXL3LNFIPSlTqcqav7ckj0xb6b47tiXGPc=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=v4aKXSt0Mo/7MBUVxeBRIVXz7OtJ9hN4H3H+RzD178dhG1L/XARmZh2FGveNkAnRP fH3PULdJkC9IGO8RK3iLoiasbOCtNFtUOL/aQrHNMN0um8a/M3F+rKF4p+p+yVqlyL rZxBrJjX1SQZAUygpgfprBQ5O/nrFIpeZMmPNHtY= To: Cloud Strife , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Bitcoin 2-way-pegged childchains via Proof of Burn 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: Fri, 26 Jun 2020 00:57:27 -0000 Good morning CS, The difficulty is not so much the proof-of-whatever, but rather, the peg it= self. My understanding of your pegout from sidechain to mainchain is that this pe= gout is very low-bandwidth, i.e. only a tiny amount can be pegged out at ea= ch mainchain block. This suggests to me that the sidecoin can still drop lower than maincoin du= ring times when overall side-to-main flows are higher than main-to-side flo= ws. (atomic swaps cannot *maintain* a peg, they can only follow a peg if it exi= sts; if the peg is weak, atomic swaps cannot strengthen it. this is because atomic swaps allow a non-1:1 exchange rate, as in cross-cur= rency atomic swaps.) In any case, from my reading of your text, I seem, the goal is scaling ("ac= ceptable option for lower value tx"). I studied sidechains some years ago, and, came to the conclusion that sidec= hains are not good for scaling. We already know that blockchains do not scale well (excessive bandwidth use= , permanent records needed to support newcomers); thus, the scaling solutio= n for cryptocurrency cannot be via **more** blockchains. Hence, Lightning Network. In Lightning Network, every channel is a consensus system between two parti= cipants, hence every channel is a 2-of-2 (i.e. requires consensus of both p= articipants to advance). We use atomic swaps to transfer between channels and the blockchain. The channel construction requires reference to an ultimate arbiter of any d= ispute/non-consensus between the channel participants; this is provided by = the blockchain layer off which the channel is based. Thus blockchain for arbitration, channels for scaling. Regards, ZmnSCPxj > Hi everyone, > > I am hoping to get a critique on a proposal of how to construct=C2=A0chil= dchains=C2=A0"on-top" of Bitcoin without requiring any changes to Bitcoin i= tself nor requiring any user or miner to be aware of them. > > The childchain is Bitcoin-aware and simulates the properties of Proof of = Work by requiring continuous burning of Bitcoin in return for the fees on t= he childchain. > > The childchain=C2=A0tip is selected by highest total accumulated Bitcoin = burnt (with goal to simulate total accumulated work) for that full chained = set of childchain block commits. > > The only asset on the childchain=C2=A0is a 2-way-peg coin that's secured = in value without oracles or collateral by requiring that each valid child c= hain block must not only burn Bitcoin, but must always use a small % of the= burnt amount to deterministically reimburse=C2=A0withdrawals from the chil= dchain. > > Childchain -> mainchain :: user burns the child-BTC and is added to withd= rawal queue filled as part of validity requirements by childchain "miners" = until filled 1:1 on mainchain or more. Note that occasionally overpaying a = widthdrawal does not break 1:1 peg as there's no fixed size 1:1 pool of coi= ns necessary. > > mainchain -> childchain :: user burns BTC (independent of mining childcha= in) and is issued equivalent 1:1 child-BTC on the childchain > > While childchains=C2=A0are less secure than the mainchain, both the child= chain security and the 2-way-peg accuracy might be an acceptable option for= lower value tx on scale determined by the burning rate.=C2=A0 > > Childchains would replace the need for any additional Proof of Work chain= s for new blockchains to introduce any complexity (e.g. mimblewimble childc= hain). > > They would effectively use Proof of Work done on Bitcoin as proxy for unf= orgeable costliness and benefit from Bitcoin's censorship resistance and da= ta availability. Large numbers of low value tx that might be priced out of = using the main chain could possibly in bulk provide enough childchain fees = combined through childchain miners to afford much higher mainchain fees lik= e "batching for fees". > > It also has the "benefits" claimed by proof of stake like no energy consu= mption without relying on internal permissions or tokens, trusted distribut= ions, or centralizing mechanisms like staking by simulating proof of work. = It should allow both growing the Bitcoin ecosystem and replace the need to = create alternative cryptocurrencies just to make a new blockchain. > > More detailed write up available here:=C2=A0https://bitcointalk.org/index= .php?topic=3D5214173.0=C2=A0=C2=A0 > > I am hoping for a review if there's an overlooked issue or maybe interest= to create a proof of concept. > > Thank you > -CS