From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3F43DC077D for ; Tue, 14 Jan 2020 04:13:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 268D0836A5 for ; Tue, 14 Jan 2020 04:13:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CflZS4kXUPlz for ; Tue, 14 Jan 2020 04:13:03 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by whitealder.osuosl.org (Postfix) with ESMTPS id C0671810FE for ; Tue, 14 Jan 2020 04:13:02 +0000 (UTC) Date: Tue, 14 Jan 2020 04:12:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1578975180; bh=D2rno52jwhl0d43ql5itmpeXwOfu1+Mrl8MdSTOQuio=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=QJlQBSoG6mv9yz4G6frkF+KT4b7eUZv0P64w3obm5lUqlLvzNCsWG9wLGFSHtsPgc b5slkycUyQhzE/05B6+uKES4W/EIazcTlVc8XKnaKsNfA4FtqkYQjcN3IHP1dqgE+Y DuG7wXUUj4JNwG9XsP3e4ks52okDwoUcaYVsSk0U= To: ZmnSCPxj From: Robin Linus Reply-To: Robin Linus Message-ID: <9hNzMroHNW8QOHQ9LekmLwudZnfcAz6xloMM3NRKrT8c52uI6-vztXxHQqyOkxsK2kwNmn61EvhBabZIpsnHW7QNGV1mRJtZ2Zx-UFSfx68=@protonmail.com> In-Reply-To: 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: 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 06:05:25 +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 04:13:05 -0000 Good morning ZmnSCPxj, > > > because all users must process all transactions within the blockchain > > > > Reality shows, that's wrong. Bitcoin's security doesn't require verific= ation to scale quadratically with users. Since the whitepaper, Satoshi was = explicit about that phenomena. We can discuss nuances, yet it's overall pla= usible and empirically it's true: Only a tiny minority of users ever verifi= es the blockchain, still bitcoin works perfectly well. An honest economic m= ajority 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 UTXOs set verifiable with consumer hardware. That's the core of decentra= lized 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 storag= e just like any other blockchain. However, security is strictly better beca= use double-spends are impossible. A single honest validating user guarantee= s that attackers cannot do more harm than halting a sidechain. Thus, enduse= rs won't have to validate all of each others' transactions at all. > > For most endusers such sidechains' security is strictly superior to tod= ay'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= regular 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 hi= gh on-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 custodia= l solutions. > > Excel tables connected to the LN. The LN is awesome as a settlement lay= er. In particular for anything like bitcoin banks that have been discussed = since the beginning. > > But why 1000 trusted Excel tables if we can have 1000 trustless sidecha= ins? > > First: > > > A single honest validating user guarantees that attackers cannot do mor= e 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 sidechai= n. > Thus it is not a trustless solution, but a tr\*sted one. > Replacing 1000 tr\*sted Excel tables with 1000 tr\*sted blockchains is th= e same class of error as replacing the banking system with centralized larg= e-scale blockchains: you gain the drawbacks of blockchains without gaining = its benefits. Agreed. Still, let's discuss a solution that meets the requirements of bill= ions of average users with unreliable mobile devices. Endusers payment experience should be insanely simple. The LN currently offers regular users mostly custodial services. Is there a= foreseeable roadmap to meet endusers' simplicity requirements with non-cus= todial constructions? Bitcoin-backed PoS sidechains are strictly superior to custodial hubs. They= provide all hub features such as being able to pay merchants in BTC, plus = many clear advantages such as better security including public auditability= and decentralized data storage. And they do not require any consensus chan= ges. > The security, integrity, and censorship-resistance of Bitcoin is dependen= t on there existing some sophisticated actors ("persons") who are willing t= o take on the risk of running fullnodes and providing hashpower. > This is the Risk-Sharing principle, by which the risk of keeping Bitcoin = running is spread out among many persons who are willing to keep Bitcoin al= ive. > The existence of such actors cannot be assured, but it seems to me that f= ragmenting the entire community of such limited number of actors would not = give good risk-sharing within a sidechain. Indeed, a highly fragmented market would be inefficient and insecure. Howev= er, I'd assume a free market of sidechains is intelligent enough to use its= resources efficiently. Thanks again for your detailed feedback, -Robin