path: root/5e/3a00db72fc217bb3ef021d4b04e95c05c2a1e3

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 8452DC077D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Jan 2020 00:53:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 73C7C85D97
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Jan 2020 00:53:34 +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 Io01dzLzvxR1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Jan 2020 00:53:32 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
 [185.70.40.132])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id CE7D485D8E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Jan 2020 00:53:31 +0000 (UTC)
Date: Tue, 14 Jan 2020 00:53:24 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=default; t=1578963209;
 bh=w466FwEEmXp9z7/rMNgxzexwicSnLPwh9oEugOsi6uI=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
 Feedback-ID:From;
 b=JtbTqeNAPTK4dnq4MM5XR+mRZDpWnqSkOzk/OHS8z1a8OS++rz+Y9DmYgOrnUeQEv
 8KUD7QLrObQz/+nN2TZAj4+0Z/dMVStkXhMe+T1Dn7n7sZi4rBIVqT84VEmAZ+wDko
 NJHhD+0BiEgc4ULD6VycuYbAhIurc2uxFI/oEd0g=
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: <-XqpIGL2s4yhkiWLsuqhvfpQKm1iRdTZHoTy83d_rKW9bY0Qhz5WHxcET5JSzEMxQUXiq5e-VmDqgp2zZ8locphCSjnztSB_yNV_esq111s=@protonmail.com>
In-Reply-To: <6pcznun9_VnOIV7D28YeCiWqSLtPnN7syJvgGVp_VIo_DAZyp2mDYZQxg6IT5dJagroU-TKgUUjLrJm12TlbhLCzwjftY6_OhIB3ej6o44E=@protonmail.com>
References: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@protonmail.com>
 <ILtIOT_2wq-ld0mk5kPev5mw8RQD6pgzSF_EPuY1PE-mdsy8eJqsCaSU-zIyNZw-4W4p5JtLJs5d451PnHvQly-3V1q225bKmdanMZVOmGE=@protonmail.com>
 <0RSAH-PjblJV6Q7TGosFHAEdc9QGauCQ_knCzMwcoGdW4Qt49ts-egDkIwM-X_f0RjsPMquwdnmB6spunH379ICEAJQgUH7R1SE8CuZs7pI=@protonmail.com>
 <6JaReZbjL3U0QrirtiCdgk107cNmQHiLbbJIDctf8uGUiqJOLvZwRLLPUQXAjzfAqRQBpaqtytcKhq1hvtSDwwaKGthwy40SWHDRnTpBkJA=@protonmail.com>
 <6pcznun9_VnOIV7D28YeCiWqSLtPnN7syJvgGVp_VIo_DAZyp2mDYZQxg6IT5dJagroU-TKgUUjLrJm12TlbhLCzwjftY6_OhIB3ej6o44E=@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: Tue, 14 Jan 2020 00:53:34 -0000

Good morning Robin,

> Hi Joachim,
>
> > > Regarding Reason #1:
> > > This proposal is less like Bitcoin vs. Altcoins and much more like Et=
hereum vs. ERC20 tokens, because the derivatives are not in competition wit=
h BTC, but depend on it heavily. You support Bitcoin's growth by supporting=
 such a sidechain.=C2=A0
> > > Also, they won't work as separate currencies. For endusers you can ab=
stract away all underlying complexities such that they have to think only i=
n BTC. Exchanges rates can be hidden in TX fees. The sidechain derivatives =
would be nothing but a means of transfer. The unit of account is still BTC.=
=C2=A0
> >
> > I can't see any difference and advantage over doing the same with say L=
itecoin. All you need is to create a special wallet which offers atomic swa=
ps LTC-BTC and its unit of account displayed to user is going to be BTC. Al=
l you say will work perfectly with this special LTC wallet. Therefore your =
idea is as good as any other altcoin. In your case, someone else should ind=
eed be able to create such a wallet in which the unit of account will be th=
e new token, thus emulating the current LTC wallets. So the only difference=
 in Litecoin is that the special wallet with BTC as unit is going to be cre=
ated after the native one, while in your case it is vice versa.
> >
> > I simply can't see why I'd call this construction of yours a Bitcoin si=
dechain and any other altcoin not. So I'd call both altcoins.
>
> Let me try to explain where I am coming from: Whenever I want to onboard =
a not-so-techy friend to Bitcoin by sending him $5 worth of BTC, I don't ha=
ve many good options. Usually we end up using BlueWallet. It works great. T=
hough it only works so well because it is fully custodial. That is how they=
 solve all the tough LN problems like inbound-capacity of new users, watcht=
owers and channel backends. Their service is just an Excel table connect to=
 the LN. Unfortunately, that is the best UX we can currently offer to endus=
ers. To me that's unsatisfying. Is that how we want to enter the emerging m=
arkets and on-board the next Billion users? I like that BlueWallet gives me=
 the option to run my own LndHub for my friends. Still, does that scale glo=
bally? More importantly, do we want that?
>
> Now let's think about the altcoins argument. We want to serve a billion u=
sers. Blockchains do scale well to about a couple Million UTXOs, so we requ=
ire a network of a couple thousand altcoins to serve our users.
> We know how to build a nice LN for all of our altcoins with a star-shaped=
 topology around Bitcoin as the central settlement layer. Atomic swaps FTW.=
 We can abstract away their native currencies. We display to our users only=
 BTC, hide the exchange rates in the TX fees and we're done. That is actual=
ly a scalability solution. So why don't we do that?

Because Lightning remains a superior *scalability* solution to microchains.

(The below is a Fermi estimate; it is intended to give an intuition on the =
rough orders of magnitude that we are discussing, not strict predictions of=
 how the world works)

Let us suppose that N users would produce N * t bytes of transactions.

Under Lightning, that data is sent to a tiny subset of the entire LN.
As Lightning limits routes to at most 20 hops, let us take the worst case a=
nd say that under Lightning, those users will force 20 * N * t bytes to be =
processed globally.

If all users were to use a *single* blockchain, because all users must proc=
ess all transactions within the blockchain, that will mean everyone has to =
process N * N * t bytes.

Now the microchain concept is that, we can split the N in half, so instead =
of a single N * N * t bytes being processed, we get two (N / 2) * (N / 2) *=
 t, or more generally, if there are c chains: c * ((N / c) ^ 2) * t or N * =
N * t / c.

So for microchains to beat Lightning, you would have to make N * N * t / c =
< 20 * N * t, or equivalently N / c < 20, i.e. 20 users per sidechain.

If you have as low as 20 users per sidechain, you might as well just use ch=
annel factories to host Lightning channels, so channel factories + channels=
 (i.e. Lightning Network) is probably better than having tiny sidechaisn wi=
th 20 users each.

Again the above is a very rough Fermi estimate, but it gives you a hint on =
the orders of magnitude you should consider, i.e. about a few dozen users p=
er sidechain, and a few dozens users in a sidechain is probably not a lot t=
o give security to that sidechain, whereas with Lightning channel factories=
 you can drop onchain any time to upgrade your security to the full mining =
hashpower (and we hope that the threat of being able to do so is enough to =
discourage attempts at theft).

What Lightning cannot do is add certain kinds of features other than scalab=
ility, for example Turing-complete disasters (RSK) or confidential assets (=
LBTC).
Sidechains are for features, not scale, so your proposed sidechain concept =
remains of interest at least as a possible way to anchor sidechains with ne=
w features.

Regards,
ZmnSCPxj