Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id C094FC000E for ; Mon, 28 Jun 2021 15:28:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id BCD804029F for ; Mon, 28 Jun 2021 15:28:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqZsujW21Ohz for ; Mon, 28 Jun 2021 15:28:51 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) by smtp2.osuosl.org (Postfix) with ESMTPS id AAAF140209 for ; Mon, 28 Jun 2021 15:28:51 +0000 (UTC) Date: Mon, 28 Jun 2021 15:28:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1624894128; bh=bXDLLqA+3L9NThfjg5J38ad327NW6umxtm7oJSseJL8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=IHI14Eta4BV9JY4nBTh36kYkSJK2WWI/R90aJGiRV5GrZhtkIC1oRygCDJxKUveot tnD4/tMcxfoeP/kbWpuSpk5UmtkMDnc1Ej/NBaSfVn6Rs7L/n1aYuzqWSUqlXQ3mbc JF5ZoawRcFnUWJmA+a9+w98vNiQXcxUO01jxfcw8= To: "raymo@riseup.net" From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com> <9c2cec326adee1f4d4152e2195da0e7b@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 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: Mon, 28 Jun 2021 15:28:52 -0000 Good morning Raymo, > Hi ZmnSCPxj, > > Why you get the signal =E2=80=9Ctrust the Gazin wallet=E2=80=9D? > Sabu is a protocol and the Gazin wallet will be an implementation of > that protocol. We will implement it in react-native language to support > both Android and iPhone. Of course it will be open source and GPL3. > Here is the repository and yet is empty :) > https://github.com/raymaot/Gazin > > I wonder why you do not look carefully into the proposal! IMHO the Sabu > will be far better than Lightning. > Can=E2=80=99t you see the fact that in Sabu you do not need open and clos= e > channels ever? Can you imagine only this feature how dramatically > decrease the transactions cost and how increase the distribution of > nodes and improve privacy level? it makes every mobile wallet act like a > lightning network. > Did you note the fact that in Sabu protocol there is no routing? And the > only people knew about a transaction are issuer and creditor? No one > else won=E2=80=99t be aware of transactions and million transactions per = second > can be sent and received and repeal dynamically without any footprint on > any DLT? > > The English is not my mother language and probably my paper is not a > smooth and easy to read paper, but these are not good excuse to not even > reading a technical paper carefully and before understanding it or at > least trying to understanding it start to complaining. What prevents the creditor from signing a transaction that is neither a val= id MT nor a GT? Nothing. In Lightning, sure one side can sign a transaction that is not a valid comm= itment transaction, but good luck getting the other side to *also* sign the= transaction; it will not. Thus, you need n-of-n. 1-of-1 is simply not secure, full stop, you need to redesign the whole thin= g to use *at least* 2-of-2. At which point you will have reinvented Lightning. Otherwise, you are simply trusting that the wallet is implemented correctly= , and in particular, that any creditor will not simply insert code in your = open-source software to sign invalid transactions. With a 1-of-1, any invalid-in-Sabu transaction can still be valid in the Bi= tcoin blockchain layer, thus the scheme is simply insecure. Features are meaningless without this kind of basic trust-minimization secu= rity. Regards, ZmnSCPxj