path: root/e0/3f4096da796504a05feda42207893e5f3a7a23

Return-Path: <robinlinus@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D17E3C077D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Jan 2020 02:03:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id BA94420111
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Jan 2020 02:03:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id MrOeXg5IIztI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Jan 2020 02:03:03 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
 [185.70.40.130])
 by silver.osuosl.org (Postfix) with ESMTPS id 8C3EF20023
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 13 Jan 2020 02:03:03 +0000 (UTC)
Date: Mon, 13 Jan 2020 02:02:53 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=default; t=1578880981;
 bh=eGR9DGTC+lZ+tIauODtFSN32iIHoSQFwKzuzrNc+aD4=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
 Feedback-ID:From;
 b=Q3JPLrnPGmMUytEezMVfoPpNazgOZOu33fognBtL/8itoz2mJKbsraswiJstl+Jk0
 OBCF8Pj2DbIQnoUXm1aF3zm80J8Ue8jNCBmwkRZsRBsZS2HYLza9o7GApbByKa5muJ
 wZFF/7bLYbDczsZ0s0Tuut5+GEfUJJQuYOMpYl5Y=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: Robin Linus <robinlinus@protonmail.com>
Reply-To: Robin Linus <robinlinus@protonmail.com>
Message-ID: <2mw_wd_ocLESpSG9ST3yJBsJriHf1l5LsdQ2jLamTUUKTMmwUpcjEeohClnMHJl4qjXNW9mHQJiK65jmDHfLG3-nVSRse9PdXnXokGZ2_ac=@protonmail.com>
In-Reply-To: <Qa9HJ5p2bYnXsjvgcTz-J_stEwJ80SU9UTZF5abv96i5eM_6y3pmy9Bu4tEnFXOc_lBs-y2BFoMh4xOGjl2US56hAFPvxDZM2eyhJkEdBLM=@protonmail.com>
References: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@protonmail.com>
 <Qa9HJ5p2bYnXsjvgcTz-J_stEwJ80SU9UTZF5abv96i5eM_6y3pmy9Bu4tEnFXOc_lBs-y2BFoMh4xOGjl2US56hAFPvxDZM2eyhJkEdBLM=@protonmail.com>
Feedback-ID: 6FfHo99INKExF0tkDkemTyDa-LNBAaNSuYGo9F4rOzppmymRaL_liHzoQTtSnq1Ib2NLN4047Io_xKQzk5eD1w==: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 03:25:24 +0000
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:03:08 -0000

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 t=
he 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
=09- 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 unreliable cel=
l phone connections and do not have any BTC yet.
And the more popular Bitcoin becomes, the fewer people can afford LN channe=
ls. Even Eltoo requires your funds to be significantly higher than Bitcoin'=
s TX fees, right?

Already today, more and more services like tippin.me, BlueWallet, etc, prov=
ide custodial solutions.
For small amounts, custody is an acceptable workaround. And I love their us=
ability. Install it and immediately I can send you $0.01. Yet, scaling thei=
r 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 Mill=
ion UTXOs. So a couple thousand Sidechains is probably sufficient for a glo=
bal medium of exchange. Cross-chain communication without requiring cross-c=
hain validation is possible via atomic swaps and through Bitcoin's LN. That=
 scales because it separates chain-validators from swap-validators.
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 LN has many a=
dvantages:
- 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 sid=
echains can be trustless. Also a generic protocol provides flexibility for =
sidechain innovations with arbitrary digital assets and consensus rules.




## Collateral Contract
Thanks for mentioning that! I like the simplicity of your variant! It's bet=
ter than my workarounds. I'll add it to the paper. However, in the long ter=
m, the cleanest solution is to destroy the funds. Giving it to miners assum=
es Alice does not control much Hash power, which is harder to reason about.


Regards,
robin




=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 1:21 AM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wro=
te:

> Good morning Robin,
>
> The reason why I stopped considering sidechains for scaling and have sinc=
e moved to Lightning Network development was that, on reflection, I realize=
d sidechains still do not scale, even with stakes anchored on the mainchain=
.
> The issue is that sidechains, like any blockchain, still require that eve=
ryone interested in it to propagate all their transaction to everyone else =
interested in it.
> Contrast this with Lightning Network, where you select only a tiny handfu=
l of nodes to inform about your payment, even if you have a gigantic Lightn=
ing Network.
>
> Or, more blithely: Let me get this straight, you already know blockchains=
 cannot scale, so your scaling proposal involves making more blockchains?
>
> You might point to the use of large numbers of sidechains with limited us=
erbase, and the use of cross-chain atomic swaps to convert between sidecoin=
s.
> I would then point out that Lightning Network channel are cryptocurrency =
systems with two users (with significantly better security than a 2-user si=
dechain would have), and that Lightning Network payment routing is just the=
 use of cross-channel atomic swaps to convert between channelcoins.
> Indeed, with a multiparticipant offchain updateable cryptocurrency system=
 mechanism, like Decker-Wattenhofer or Decker-Russell-Osuntokun ("eltoo"), =
you could entirely replace sidechains with a mechanism that does not give c=
ustody to your funds to anyone else, since you can always insist on using n=
-of-n signing with you included in the signer set to prevent state changes =
that do not have your approval.
>
>


>
> Regards,
> ZmnSCPxj