From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ZmnSCPxj@protonmail.com> Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id A0ACDC077D for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 13 Jan 2020 02:33:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 96666847AB for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 13 Jan 2020 02:33:32 +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 eYW5-ST1hMDU for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 13 Jan 2020 02:33:30 +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 whitealder.osuosl.org (Postfix) with ESMTPS id 562AC83DC2 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 13 Jan 2020 02:33:30 +0000 (UTC) Date: Mon, 13 Jan 2020 02:33:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1578882807; bh=Pj+xVJqGZzG1Cur6S6Qg0eXFBFxzo5Xu+aR09yrM+Yc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=UVy0gGRyfDOTTWhNkr8XzRlZZCYniq+F9FiE2r189XB4CnORx0KU/Z0X347/fDsYq qluJlfQK4ihojAiCxag4Ihbw/9JYvMo1yDZb4SniaVXgACgqCWg+O6BTGTasqYgO/E F5/B0vOXWsjCK4x5sobzdNXsKwvt4/xsF/m3ihtE= To: Robin Linus <robinlinus@protonmail.com> From: ZmnSCPxj <ZmnSCPxj@protonmail.com> Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> Message-ID: <P-QnOpNsFdehy_F3FJgAr0lSJ2xtmT5cwRsEC8VfnIUrSgfNDkLNizm2L1TG65AhKM430tzJ9p33WBnSmJ92ZTKEoaKXCTQzVKrZkH9vtn4=@protonmail.com> In-Reply-To: <2mw_wd_ocLESpSG9ST3yJBsJriHf1l5LsdQ2jLamTUUKTMmwUpcjEeohClnMHJl4qjXNW9mHQJiK65jmDHfLG3-nVSRse9PdXnXokGZ2_ac=@protonmail.com> References: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@protonmail.com> <Qa9HJ5p2bYnXsjvgcTz-J_stEwJ80SU9UTZF5abv96i5eM_6y3pmy9Bu4tEnFXOc_lBs-y2BFoMh4xOGjl2US56hAFPvxDZM2eyhJkEdBLM=@protonmail.com> <2mw_wd_ocLESpSG9ST3yJBsJriHf1l5LsdQ2jLamTUUKTMmwUpcjEeohClnMHJl4qjXNW9mHQJiK65jmDHfLG3-nVSRse9PdXnXokGZ2_ac=@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 Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 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 02:33:32 -0000 Good morning Robin, > Good morning ZmnSCPxj, > > Thank you for your detailed feedback! Two topics: > > Lightning vs Sidechains > > ------------------------ > > Why an either-or-solution, if we can connect sidechains via the LN to get= the best of both worlds? > > The LN works exceptionally great under the following conditions: > > - you're always online > - you have BTC to manage your channels' inbound-capacity > - you can afford BTC transactions > - in your channel is much more than the minimum on-chain TX fees > > The next Billion users do not fit that category. They are on unre= liable cell phone connections and do not have any BTC yet. > And the more popular Bitcoin becomes, the fewer people can afford= LN channels. Even Eltoo requires your funds to be significantly higher tha= n Bitcoin's TX fees, right? > > Already today, more and more services like tippin.me, BlueWallet,= etc, provide custodial solutions. > For small amounts, custody is an acceptable workaround. And I lov= e their usability. Install it and immediately I can send you $0.01. Yet, sc= aling their approach globally does not lead to desirable outcomes, since we= 'd be back to trusting banks with their Excel sheets. > > So let's make their internal ledgers public and trustless, via in= dependent sidechains. Decentralized Blockchains do scale decently up to a c= ouple Million UTXOs. So a couple thousand Sidechains is probably sufficient= for a global medium of exchange. Cross-chain communication without requiri= ng cross-chain validation is possible via atomic swaps and through Bitcoin'= s LN. That scales because it separates chain-validators from swap-validator= s. > Bitcoin's LN acts as the central settlement layer for efficient c= ross-chain transactions between all sidechains. > > So Endusers "living" in sidechains instead of directly in the LN = has many advantages: > > - no bitcoin blockspace required for on-boarding new users > - no need to lock funds to provide inbound-capacity > - no need to stay online or pay watch towers > - no need to store channel histories > - account balances can be much smaller than BTC TX fees > > Those are the exact same reasons why BlueWallet built their LndHub. B= ut sidechains can be trustless. Also a generic protocol provides flexibilit= y for sidechain innovations with arbitrary digital assets and consensus rul= es. Which is why I brought up multiparticipant offchain updateable cryptocurren= cy systems. The "channel factories" concepts does what you are looking for, except with= better trust-minimization than sidechains can achieve. Just replace "sidechain" with either Decker-Wattenhofer or Decker-Russell-O= suntokun constructions. You can even use the Somsen "statechain" mechanism, which rides a Decker-Wa= ttenhofer/Decker-Russell-Osuntokun construction, though its trust-minimizat= ion is only very very slightly better than federated sidechains. It is helpful to remember that Poon-Dryja, Decker-Wattenhofer, Decker-Russe= ll-Osuntokun, and all other future such constructions, can host any contrac= t that its lower layer can support. So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can host = HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs. Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin blockchai= n, you can host a Poon-Dryja inside the Decker-Wattenhofer, since the Bitco= in blockchain can host Poon-Dryja channels. This central insight leads one to conclude that anything you can put onchai= n, you an generally also put offchain, so why use a chain at all except as = an ultimate anchor to reality? Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits the= practical number of updates due to its use of decrementing relative timelo= cks: so you put the payment layer in a bunch of Poon-Dryja channels which s= upport tons of updates each but only two participants per channel, and crea= te a layer that supports changes to the channel topology (where changes to = the channel connectivity are expected to be much rarer than payments) and i= s multiparticipant so you can *actually* scale. Instead of using sidechains, just use channel factories. You do not need to broadcast the entire internal ledgers of those services,= only their customers need to know those internal ledgers, and sign off on = the updates of those ledgers. Regards, ZmnSCPxj