diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-01-13 00:21:42 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-01-13 00:21:51 +0000 |
| commit | 4b884f54201f40db5f1c8b72fd13ae42fa72f034 (patch) | |
| tree | 808f7b0658180e6680246d170202432dd1f865fb | |
| parent | 928f864c2d48531fba7c40810287fc171f625e04 (diff) | |
| download | pi-bitcoindev-4b884f54201f40db5f1c8b72fd13ae42fa72f034.tar.gz pi-bitcoindev-4b884f54201f40db5f1c8b72fd13ae42fa72f034.zip | |
Re: [bitcoin-dev] Coins: A trustless sidechain protocol
| -rw-r--r-- | 2c/5234ea99a9d959a224cb57848b77b92984573e | 118 |
1 files changed, 118 insertions, 0 deletions
diff --git a/2c/5234ea99a9d959a224cb57848b77b92984573e b/2c/5234ea99a9d959a224cb57848b77b92984573e new file mode 100644 index 000000000..dbd39628c --- /dev/null +++ b/2c/5234ea99a9d959a224cb57848b77b92984573e @@ -0,0 +1,118 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id D9D69C077D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <robinlinus@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <Qa9HJ5p2bYnXsjvgcTz-J_stEwJ80SU9UTZF5abv96i5eM_6y3pmy9Bu4tEnFXOc_lBs-y2BFoMh4xOGjl2US56hAFPvxDZM2eyhJkEdBLM=@protonmail.com> +In-Reply-To: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@protonmail.com> +References: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@protonmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 `<one year> OP_CH= +ECKSEQUENCEVERIFY OP_DROP <A> 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 `<A>` 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 + + |