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 F350CC077D for ; Tue, 14 Jan 2020 02:59:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id DC82C8788B for ; Tue, 14 Jan 2020 02:59:36 +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 Q6R+EUETSVEn for ; Tue, 14 Jan 2020 02:59:35 +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 B835C87852 for ; Tue, 14 Jan 2020 02:59:34 +0000 (UTC) Date: Tue, 14 Jan 2020 02:59:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1578970772; bh=/yz4lazinKP3mWobRHmX+XUOcFaB6aC11jVAABncpXU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=vB1TfQXh949G5IAUsVW4tEaBLBPvkOLfiMM4zEhiAS2oZsM1FyyyCew8oygEX+7Mw EAM+hnDjHXPfOp2onsQY2qImadMAqmBQFTp5fmyFN+Wvihd0HhOUzRaBildslYUHj5 KoNRTCwIws2spRVpX0yJuAo+pGZMz3bx56Nuk3uM= To: Robin Linus From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <2NvYkCEanXxFZvWPT3SJ-8whLGsVQYH_QbAHjPqLZIpeCO9E_mL7cCWTg6Qe4Af8gSMMeizbQQh3pZ-QW91xHDQOfZZUFdoacNOjzEEg85Y=@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> <2NvYkCEanXxFZvWPT3SJ-8whLGsVQYH_QbAHjPqLZIpeCO9E_mL7cCWTg6Qe4Af8gSMMeizbQQh3pZ-QW91xHDQOfZZUFdoacNOjzEEg85Y=@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 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:59:37 -0000 Good morning Robin, > > because all users must process all transactions within the blockchain > > Reality shows, that's wrong. Bitcoin's security doesn't require verificat= ion to scale quadratically with users. Since the whitepaper, Satoshi was ex= plicit about that phenomena. We can discuss nuances, yet it's overall plaus= ible and empirically it's true: Only a tiny minority of users ever verifies= the blockchain, still bitcoin works perfectly well. An honest economic maj= ority is sufficient. > > Yes, if you can, run your own node. Let's lower the barriers and let's he= lp others to run their own nodes. Let's keep the blocks small and bitcoin's= UTXOs set verifiable with consumer hardware. That's the core of decentrali= zed security. > > But let's face it: most people on this planet will never run a bitcoin fu= ll node. And it is not required. > > Bitcoin-backed PoS-sidechains scale in terms of verification and storage = just like any other blockchain. However, security is strictly better becaus= e double-spends are impossible. A single honest validating user guarantees = that 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 r= egular users on unreliable phones. > > Any payment channel which requires you to be always online excludes 99% o= f the world's population. > Any payment channel which potentially requires you to be able to pay high= on-chain fees excludes most people, too. And on-chain fees keep rising. > > Thus, no matter what Channel Factory constructions we build, they will no= t match most people's requirements. We will keep falling back to custodial = solutions. > 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 si= nce the beginning. > But why 1000 trusted Excel tables if we can have 1000 trustless sidechain= s? First: > A single honest validating user guarantees that attackers cannot do more= harm than halting a sidechain. Is not compatible with: > 1000 trustless sidechains You are *tr\*sting* that there exists at least ***one*** ***honest*** user = per sidechain. Thus it is not a trustless solution, but a tr\*sted one. Replacing 1000 tr\*sted Excel tables with 1000 tr\*sted blockchains is the = same class of error as replacing the banking system with centralized large-= scale blockchains: you gain the drawbacks of blockchains without gaining it= s benefits. The security, integrity, and censorship-resistance of Bitcoin is dependent = on there existing some sophisticated actors ("persons") who are willing to = take on the risk of running fullnodes and providing hashpower. This is the Risk-Sharing principle, by which the risk of keeping Bitcoin ru= nning is spread out among many persons who are willing to keep Bitcoin aliv= e. The existence of such actors cannot be assured, but it seems to me that fra= gmenting the entire community of such limited number of actors would not gi= ve good risk-sharing within a sidechain. Regards, ZmnSCPxj