Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D9D69C077D for ; Mon, 13 Jan 2020 00:21:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id CFA3A8526D for ; Mon, 13 Jan 2020 00:21:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKq8awGeubkR for ; Mon, 13 Jan 2020 00:21:50 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by fraxinus.osuosl.org (Postfix) with ESMTPS id F006B85264 for ; Mon, 13 Jan 2020 00:21:49 +0000 (UTC) Date: Mon, 13 Jan 2020 00:21:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1578874907; bh=zR5HA4uPXMxQtoCfAS1nvn+MktxOECgMRy2iQvONuXw=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=E0uPD60AKjHXBtDshKre23IR5ELZhdHuUFeBAzZg/vlcxlKGNGKyDSmrFK5EN2xmi /5uUHJzDgIIn3/Lh6ak7B5sYlnksWw/oAzb1hqLNG5g9DPzCti1mniRXxf3H7+y8Jd RDsJIu3Vb3j0GuCfAvbX+FDZvhSQsSc8hcHvVKoA= To: Robin Linus , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Coins: A trustless sidechain protocol 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: Mon, 13 Jan 2020 00:21:52 -0000 Good morning Robin, The reason why I stopped considering sidechains for scaling and have since = moved to Lightning Network development was that, on reflection, I realized = sidechains *still* do not scale, even with stakes anchored on the mainchain= . The issue is that sidechains, like any blockchain, still require that every= one interested in it to propagate all their transaction to everyone else in= terested in it. Contrast this with Lightning Network, where you select only a tiny handful = of nodes to inform about your payment, even if you have a gigantic Lightnin= g Network. Or, more blithely: Let me get this straight, you already know blockchains c= annot scale, so your scaling proposal involves making ***more*** blockchain= s? You might point to the use of large numbers of sidechains with limited user= base, and the use of cross-chain atomic swaps to convert between sidecoins. I would then point out that Lightning Network channel are cryptocurrency sy= stems with two users (with significantly better security than a 2-user side= chain would have), and that Lightning Network payment routing is just the u= se of cross-channel atomic swaps to convert between channelcoins. Indeed, with a multiparticipant offchain updateable cryptocurrency system m= echanism, like Decker-Wattenhofer or Decker-Russell-Osuntokun ("eltoo"), yo= u could entirely replace sidechains with a mechanism that does not give cus= tody to your funds to anyone else, since you can always insist on using n-o= f-n signing with you included in the signer set to prevent state changes th= at do not have your approval. --- You could implement the collateral contract with a simple ` OP_CH= ECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG`, with a single-sign signature us= ed at the consensus layer for your sidechain. `OP_CHECKSEQUENCEVERIFY` ensures, as a side effect, that the spending trans= action opts in to RBF. Thus, if the pubkey `` is used in a single-sign signature scheme (which = reveals the privkey if double-signed), then at the end of the period, anyon= e who saw the double-signing can claim that fund and thus act as "Bob". Indeed, many "Bob"s will act and claim this fund, increasing the fee each t= ime to try to get their version onchain. Eventually, some "Bob" will just put the entire fund as fee and put a measl= y `OP_RETURN` as single output. This "burns" the funds by donating it to miners. From the point of view of Alice this is hardly distinguishable from losing = the fund right now, since Alice will have a vanishingly low chance of spend= ing it after the collateral period ends, and Alice still cannot touch the f= unds now anyway. Alice also cannot plausibly bribe a miner, since the miner could always get= more funds by replacing the transaction internally with a spend-everything= -on-fees `OP_RETURN` output transaction, and can only persuade the miner no= t to engage in this behavior by offering more than the collateral is worth = (which is always worse than just losing the collateral). A `OP_CHECKTEMPLATEVERIFY` would work better for this use-case, but even wi= thout it you do not need a *single* *tr\*sted* Bob to implement the collate= ral contract. Regards, ZmnSCPxj