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 A8425C077D for ; Mon, 13 Jan 2020 17:34:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 9F28783DA4 for ; Mon, 13 Jan 2020 17:34:25 +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 lYzXhGRNxzSo for ; Mon, 13 Jan 2020 17:34:23 +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 EFD38815EA for ; Mon, 13 Jan 2020 17:34:22 +0000 (UTC) Date: Mon, 13 Jan 2020 17:34:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1578936860; bh=DMcDEIqm3ndHgFIKrVF6KNOtl8CaYU4FkFAR/TNwVh4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=wdjejkfduoGVPg559KnHIWoD646D/e5of5Dd3Kn5fc4sv/Wq77iUhcc9FyUPuXxbR uw9g7HLfsSNXPCLx0M4UJW+fnqmD03Y1rCEmqaA1UI+zD96ruHh1B1eXe4a/JjI4DX o03RAtRWGnrZvzzsZCVroykOx1ca2feGvfCa1PLA= To: ZmnSCPxj , Bitcoin Protocol Discussion From: =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= Reply-To: =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= Message-ID: <-8y3dnfO2vpyLPeOF5scfp0c5AZd9FF-_xkr1jL2iT1j02fSMJHix2YQupuOeBRF9v5icwGQbriKFXqd5B1AusZp0X7ENOvQ_q4OGCazueU=@protonmail.com> In-Reply-To: References: <2mw_wd_ocLESpSG9ST3yJBsJriHf1l5LsdQ2jLamTUUKTMmwUpcjEeohClnMHJl4qjXNW9mHQJiK65jmDHfLG3-nVSRse9PdXnXokGZ2_ac=@protonmail.com> Feedback-ID: rtGq1wInl4cYyZOA2iZwaHP-4FBFY67Qt3DcVBMZh8YR1tV-3hijnv7SxpdDwGlNdSPgHEykKLn6PcHDKa0D8A==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 13 Jan 2020 17:40:51 +0000 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 17:34:25 -0000 > Instead of using sidechains, just use channel factories. I am not familiar enough with the latest advancements in this field. Is it = possible using LN/channel factories to achieve off-line-like participation = user experience without previous registration with any kind of gateway prov= ider? For example, can you go online, join the network [somehow instantly],= generate address/invoice and then put it somewhere for others to later use= it when you are off-line? Can you also participate while being off-line fo= r very long periods of time without relying on third party providers to sec= ure your channels? If not, is using sidechains really equally replaceable w= ith LN/CF constructions? Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Monday, January 13, 2020 2:33 AM, ZmnSCPxj via bitcoin-dev wrote: > 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 g= et 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 un= reliable cell phone connections and do not have any BTC yet. > > And the more popular Bitcoin becomes, the fewer people can affo= rd LN channels. Even Eltoo requires your funds to be significantly higher t= han Bitcoin's TX fees, right? > > Already today, more and more services like tippin.me, BlueWalle= t, etc, provide custodial solutions. > > For small amounts, custody is an acceptable workaround. And I l= ove their usability. Install it and immediately I can send you $0.01. Yet, = scaling 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 = independent sidechains. Decentralized Blockchains do scale decently up to a= couple Million UTXOs. So a couple thousand Sidechains is probably sufficie= nt for a global medium of exchange. Cross-chain communication without requi= ring cross-chain validation is possible via atomic swaps and through Bitcoi= n's LN. That scales because it separates chain-validators from swap-validat= ors. > > Bitcoin's LN acts as the central settlement layer for efficient= cross-chain transactions between all sidechains. > > So Endusers "living" in sidechains instead of directly in the L= N 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.= But sidechains can be trustless. Also a generic protocol provides flexibil= ity for sidechain innovations with arbitrary digital assets and consensus r= ules. > > > > Which is why I brought up multiparticipant offchain updateable cryptocurr= ency systems. > The "channel factories" concepts does what you are looking for, except wi= th better trust-minimization than sidechains can achieve. > Just replace "sidechain" with either Decker-Wattenhofer or Decker-Russell= -Osuntokun constructions. > You can even use the Somsen "statechain" mechanism, which rides a Decker-= Wattenhofer/Decker-Russell-Osuntokun construction, though its trust-minimiz= ation is only very very slightly better than federated sidechains. > > It is helpful to remember that Poon-Dryja, Decker-Wattenhofer, Decker-Rus= sell-Osuntokun, and all other future such constructions, can host any contr= act that its lower layer can support. > So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can hos= t HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs. > Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin blockch= ain, you can host a Poon-Dryja inside the Decker-Wattenhofer, since the Bit= coin blockchain can host Poon-Dryja channels. > This central insight leads one to conclude that anything you can put onch= ain, you an generally also put offchain, so why use a chain at all except a= s an ultimate anchor to reality? > Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits t= he practical number of updates due to its use of decrementing relative time= locks: so you put the payment layer in a bunch of Poon-Dryja channels which= support tons of updates each but only two participants per channel, and cr= eate a layer that supports changes to the channel topology (where changes t= o the channel connectivity are expected to be much rarer than payments) and= is 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 service= s, only their customers need to know those internal ledgers, and sign off o= n the updates of those ledgers. > > Regards, > ZmnSCPxj > > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev