From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4A93FC077D for ; Tue, 14 Jan 2020 02:20:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 3607A87807 for ; Tue, 14 Jan 2020 02:20:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQzgAD+8yAZv for ; Tue, 14 Jan 2020 02:20:00 +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 hemlock.osuosl.org (Postfix) with ESMTPS id 16F84877A0 for ; Tue, 14 Jan 2020 02:20:00 +0000 (UTC) Date: Tue, 14 Jan 2020 02:19:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1578968397; bh=jPGXnvqOynKCojBCIDtFCEqvMFqz5Sr7/mpUJLZiTns=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=dwhD//SRr7Cl0rUUVeIP+L0uYsyScYtcmzYZnoa9WhHOMj61/zxHawLNOqRqEsRBy VRu70ndM9rq7AXMogmr1XZHKYN0Uf10lzSZGPZc6/3lSu0/6DBnjkfP5T9u6b211QO FtnVdHK4zYtMEjqYoSU5lkvF4XvARvl/auvKihbI= To: ZmnSCPxj From: Robin Linus Reply-To: Robin Linus Message-ID: <2NvYkCEanXxFZvWPT3SJ-8whLGsVQYH_QbAHjPqLZIpeCO9E_mL7cCWTg6Qe4Af8gSMMeizbQQh3pZ-QW91xHDQOfZZUFdoacNOjzEEg85Y=@protonmail.com> In-Reply-To: <-XqpIGL2s4yhkiWLsuqhvfpQKm1iRdTZHoTy83d_rKW9bY0Qhz5WHxcET5JSzEMxQUXiq5e-VmDqgp2zZ8locphCSjnztSB_yNV_esq111s=@protonmail.com> References: <0RSAH-PjblJV6Q7TGosFHAEdc9QGauCQ_knCzMwcoGdW4Qt49ts-egDkIwM-X_f0RjsPMquwdnmB6spunH379ICEAJQgUH7R1SE8CuZs7pI=@protonmail.com> <6JaReZbjL3U0QrirtiCdgk107cNmQHiLbbJIDctf8uGUiqJOLvZwRLLPUQXAjzfAqRQBpaqtytcKhq1hvtSDwwaKGthwy40SWHDRnTpBkJA=@protonmail.com> <6pcznun9_VnOIV7D28YeCiWqSLtPnN7syJvgGVp_VIo_DAZyp2mDYZQxg6IT5dJagroU-TKgUUjLrJm12TlbhLCzwjftY6_OhIB3ej6o44E=@protonmail.com> <-XqpIGL2s4yhkiWLsuqhvfpQKm1iRdTZHoTy83d_rKW9bY0Qhz5WHxcET5JSzEMxQUXiq5e-VmDqgp2zZ8locphCSjnztSB_yNV_esq111s=@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: Tue, 14 Jan 2020 02:31:00 +0000 Cc: Bitcoin Protocol Discussion 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 02:20:02 -0000 > because all users must process all transactions within the blockchain Reality shows, that's wrong. Bitcoin's security doesn't require verificatio= n to scale quadratically with users. Since the whitepaper, Satoshi was expl= icit about that phenomena. We can discuss nuances, yet it's overall plausib= le and empirically it's true: Only a tiny minority of users ever verifies t= he blockchain, still bitcoin works perfectly well. An honest economic major= ity is sufficient. Yes, if you can, run your own node. Let's lower the barriers and let's help= others to run their own nodes. Let's keep the blocks small and bitcoin's U= TXOs set verifiable with consumer hardware. That's the core of decentralize= d security. But let's face it: most people on this planet will never run a bitcoin full= node. And it is not required. Bitcoin-backed PoS-sidechains scale in terms of verification and storage ju= st like any other blockchain. However, security is strictly better because = double-spends are impossible. A single honest validating user guarantees t= hat attackers cannot do more harm than halting a sidechain. Thus, endusers = won't have to validate all of each others' transactions at all. For most endusers such sidechains' security is strictly superior to today's= LN experience. Let's face it: The most popular LN apps are fully custodial. They have to be custodial because there is no way to make LN usable for reg= ular users on unreliable phones. Any payment channel which requires you to be always online excludes 99% of = the world's population. Any payment channel which potentially requires you to be able to pay high o= n-chain fees excludes most people, too. And on-chain fees keep rising. Thus, no matter what Channel Factory constructions we build, they will not = match most people's requirements. We will keep falling back to custodial so= lutions. Excel tables connected to the LN. The LN is awesome as a settlement layer. = In particular for anything like bitcoin banks that have been discussed sinc= e the beginning. But why 1000 trusted Excel tables if we can have 1000 trustless sidechains?