From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8452DC077D for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <-XqpIGL2s4yhkiWLsuqhvfpQKm1iRdTZHoTy83d_rKW9bY0Qhz5WHxcET5JSzEMxQUXiq5e-VmDqgp2zZ8locphCSjnztSB_yNV_esq111s=@protonmail.com> In-Reply-To: <6pcznun9_VnOIV7D28YeCiWqSLtPnN7syJvgGVp_VIo_DAZyp2mDYZQxg6IT5dJagroU-TKgUUjLrJm12TlbhLCzwjftY6_OhIB3ej6o44E=@protonmail.com> References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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