Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1EAEBC000E for ; Mon, 28 Jun 2021 16:58:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 00D4F400EE for ; Mon, 28 Jun 2021 16:58:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=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=riseup.net 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 pqupZ1foJddE for ; Mon, 28 Jun 2021 16:58:38 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by smtp2.osuosl.org (Postfix) with ESMTPS id 22C55400E5 for ; Mon, 28 Jun 2021 16:58:37 +0000 (UTC) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4GDDMd4FdczDrv6; Mon, 28 Jun 2021 09:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1624899517; bh=vOxtDrg4ry44QgOkxvbYVlaVQ337NOvtaqguNsKsTlI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sjj+zCfGMgozWK1ceoEndbl53sqyNG2H6zzVzi+wXHWFwLXeyOLjH/5h3wBfI0a9o lMK81kfWEgMn+KNXoHt08ToTtnuqqd+S4p6JKi+jjI4LUDHnkq11UdJBsHIh2pl+o+ zp+OWHCdij5c5/a8o8wm6BVbZEhWg0im/0qUYYjQ= X-Riseup-User-ID: 5E74EC8361DC6BA0C3E21007FF12D64DF3FF9E2ECBB2B09C3E736A016CDF1DE2 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4GDDMd33g5z20b5; Mon, 28 Jun 2021 09:58:37 -0700 (PDT) MIME-Version: 1.0 Date: Mon, 28 Jun 2021 09:58:37 -0700 From: raymo@riseup.net To: ZmnSCPxj In-Reply-To: References: <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com> <9c2cec326adee1f4d4152e2195da0e7b@riseup.net> Message-ID: <16131549ac084b58fc6cde894e43babe@riseup.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 28 Jun 2021 17:35:09 +0000 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 16:58:39 -0000 > What prevents the creditor from signing a transaction that is neither a valid MT nor a GT? Please stop comparing Sabu and Lightning. Otherwise, it won't let you true understanding of Sabu. In Sabu protocol, only the issuer (the UTXO owner) can sign the transaction and decide how much money goes to whom. The engaged UTXO(s) belonged to issuer and the creditor never put UTXO in transaction, thus never can sign the transaction because he has no ownership on the used UTXOs. As I already wrote in paper, the issuer creates and signs a transaction and delivers it to creditor(s). If a creditor intends to send all or part of his money to another person (AKA spending his money), he will ask for a new signed transaction from issuer, in which a part of his credit will transfer to another creditor. The Sabu has nothing with Lightning. Sabu has a peer-to-peer network of doc-watchers which maybe it was the cause you always compare it to Lightning. I am not presenting lightning neither condemning it. I am presenting Sabu protocol. Please let concentrate on how Sabu works or not works. On 2021-06-28 15:28, ZmnSCPxj wrote: > Good morning Raymo, > >> Hi ZmnSCPxj, >> >> Why you get the signal “trust the Gazin wallet”? >> 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’t you see the fact that in Sabu you do not need open and close >> 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’t 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 valid MT nor a GT? > > Nothing. > > In Lightning, sure one side can sign a transaction that is not a valid > commitment 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 > thing 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 Bitcoin blockchain layer, thus the scheme is simply insecure. > > Features are meaningless without this kind of basic trust-minimization security. > > Regards, > ZmnSCPxj