From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id D302CC000E for ; Sun, 8 Aug 2021 09:11:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B5F5E6070B for ; Sun, 8 Aug 2021 09:11:44 +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: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IClnxvNmhNQG for ; Sun, 8 Aug 2021 09:11:43 +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 smtp3.osuosl.org (Postfix) with ESMTPS id 646426058D for ; Sun, 8 Aug 2021 09:11:42 +0000 (UTC) Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (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 4GjD3y3hxBzDrvt for ; Sun, 8 Aug 2021 02:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1628413902; bh=JJ0g/mrUvEPonTocT6VrL2LovGR7xySk5Q92W7yGC1Y=; h=Date:From:To:Subject:In-Reply-To:References:From; b=CcmD08uVN2gXKKromrtH6c1VPSOn1IFeNUjS4k4OOC1jM6KKOxrfGAHV11sTOkL+T YmDn09dgo+l8scjSPoSXVQFUXAJxqtjWrdzvDliMOJE35rDCNAVq16wqbhJP+R2Gsm aCuo7vE16Sy8Nxw2YH2oTOJaMqj/hQd4cxVoxwJE= X-Riseup-User-ID: 518B94281B636752FE7E01FC4B03F01988E152499B125B1A0C5E0ECEEF8AD1BE Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4GjD3y2XXlz5vNL for ; Sun, 8 Aug 2021 02:11:42 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 08 Aug 2021 02:11:42 -0700 From: raymo@riseup.net To: Bitcoin Protocol Discussion In-Reply-To: <6016816a7ea36b8a88f48d69462d0308@riseup.net> References: <6016816a7ea36b8a88f48d69462d0308@riseup.net> Message-ID: <0555e82561666007e7ce367e3a204f53@riseup.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 08 Aug 2021 13:13:52 +0000 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: Sun, 08 Aug 2021 09:11:44 -0000 Fine tuning Sabu in order to minimize the protocol risks After representing Sabu protocol here (https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180) and answer some comments and critics here (https://raymo-49157.medium.com/scaling-bitcoin-by-sabu-protocol-risks-and-benefits-62157f8a664e), I dedicated some days to tuning the Sabu transaction criteria in order to reduce the risks either for issuers or creditors. After that fine tuning, most of risks were decreased dramatically. In this post I’ll represent these details. For whom may forget about how Sabu protocol work, the core points are repeated for concept recall. Why should we use Sabu protocol? The main goal of Sabu is “boosting Bitcoin C2C circulation” by distributing it between far more people. The protocol incentivizes the small Bitcoin owners (people who has a tenth of Bitcoin or less) to sell few Satoshi (4 or 5 dollar or so) in person with no KYC due to Bitcoin ethos and earn small transaction fees for each transaction. This movement will end up to 10x or more bigger Bitcoin users, which definitely improves Bitcoin’s community and its proper ecosystem. How Bitcoin transaction work? Owning Bitcoin, means having some UTXO (recorded in Bitcoin blockchain) under your control. That is, you can sign that UTXO to prove you are the legitimate owner of that money. Thus, if you want to spend your Bitcoins, you create a transaction by which sign your under-controlled UTXO(s) and represent your desire to transfer this ownership to the other person. This transaction is a document that issued by you and provides a legitimate order for this money transfer. In order to execute this money transfer, you need to broadcast your signed document to Bitcoin network aimed to record it in Bitcoin blockchain, otherwise, no money transfer has taken place. After recording this transaction in Bitcoin blockchain, the transfer is settled and "everyone" will be aware of the new owner(s) of that particular spent coins. How Sabu protocol work? You -as a UTXO owner- are an "issuer", and always can issue a document (AKA transaction) by which you represent your will to transfer some of your UTXOs to others. Thus, Sabu is a non-custodial protocol. As long as this debt document is not registered in the Bitcoin blockchain, it is nothing more than a liability, i.e., you owe some Bitcoins to someone else. That guy naming her/him "creditor" payed money to you or provided goods or services for you, in exchange of this debt-document. Thus s/he has a copy of this transaction in her/his wallet. The issuer or creditor always can send this transaction to Bitcoin blockchain network aimed to record this money transformation in Bitcoin blockchain, or keep this transaction in wallet. But due to the high transaction fee on the Bitcoin blockchain and the insignificance of the amount transferred (a few Dollars), they will not send the document to the Bitcoin network, instead prefers to use this document as a payment method and exchange these documents in Sabu protocol and in an off-chain manner. When the creditor wants to spend his money, his wallet will send a request to the issuer’s wallet and ask it to transfer the issuer’s liability to another creditor. The issuer prepares a new transaction in which issuer owes the new creditor(s), and delivers this new transaction to both old and new creditors. The issuers earn small Sabu-transaction-fee per each money transfer (one or two Sat per transaction). Millions of issuers and creditors are exchanging these documents (transactions) in a peer-to-peer network continually, with no central authority. There is no blockchain nor public ledger. After each dealing, the issuer cancels the old transaction and creates a new document, and updates the creditor balances. These documents will be in circulation between issuers and creditors in the Sabu network forever meanwhile less than one percent of these transactions will be recorded on the Bitcoin blockchain. Either issuers or creditors in order to use Sabu protocol need to install Sabu mobile wallet (called Gazin) and start to deal. That is all they need. No technical skill or extra cost needed. How Sabu prevents frauds? The main mechanism of the system against fraud is the un-profitability of fraud in terms of economic benefits. In other words, all of malicious activities will end up in losing money of attacker. In short, the Sabu anti-fraud system works like that. The issuer always creates and signs a transaction pair. The Main Transaction which represents the real amount of outputs. And the Guarantee Transaction which pays relatively higher Bitcoin-transaction-fee. This fee increment is obtained by cutting from the issuer and creditor outputs in Main Transaction. Check out this simple transaction to learn more about how the system works. Consider Alice as an issuer. She owns a UTXO worth 20,000 Satoshi. So, she can spend it by create a transaction and sign it and broadcast it to Bitcoin network. Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys 12,000 Satoshi from Alice in exchange. Alice gets this 5$ and prepare a Main transaction that represents this liability of Alice to Bob. Main Transaction (20,000 Sat input): * Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000, but Bob has to pay 3,000 as BTC fee) * Alice (issuer): 6,000 Sat * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) This is a valid transaction and both Bob and/or Alice can send it to Bitcoin network, but none of them are interested in doing so. Because they will lose 5,000 Satoshi of their own money as Bitcoin transaction fee. Alongside this transaction Alice (the issuer) has to create the Guarantee Transaction as well and deliver it to Bob. Otherwise, Bob will not consider the deal completed. The Guarantee Transaction is another valid Bitcoin transaction. It is created based on Main Transaction and will cut a part of Bob and Alice money in favor of transaction fee. Guarantee Transaction (20,000 Sat input): * Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 = 1,740 Sat * Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520 Sat * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260 (from Bob) + 3,480 (from Al-ice) = 15,739 Sat The Guarantee Transaction applies when the issuer does not live up to its promise and intends to spend the promised UTXO(s) in a way other than that agreed upon. We already knew the fact that Sabu is not a custodial solution, neither a M of N signature schema. As a result, the UTXO owner always can spend the already promised UTXO(s) in Sabu protocol or out of Sabu on Bitcoin blockchain, Contrary to what was promised. When the Alice (issuer) breaks such a promise and sends the fraudulent transaction to the Bitcoin network, Bob's wallet realizes that she (issuer) is spending the promised UTXO(s) and it sends the Guarantee Transaction(s) to the network as a last resort. The miners will face two (or more) transactions which are spending same UTXO(s), but one of them is paying notably higher Bitcoin transaction fee, thus they chose the highest fee payer transaction, which is the Guarantee Transaction. The miner will put the Guarantee Transaction in next block and reject the rest double-spend transactions. Certainly, poor Bob cannot recoup all his Satoshis. But he can retrieve a portion of his money and forces Alice to lose some of her money as well. tit for tat! Because of this mechanism, the issuer will try to not cheat on creditor. By the way there are some attacks that have very small chance to succeed but the risk to reward ratio for these scenarios are too high to be considered as a real possible attack threat. I will review them a little later in this post. What are the advantages of Sabu over Lightning? There are four benefits to using Sabu. Cost: In Sabu unlike Lightning, the transaction parties do not need to open a channel and consequently they do not need to close it. Therefore, they do not need to pay Bitcoin transaction fees two times. The transaction parties will pay small Sabu-transaction-fee per each transaction to the issuer because of creating and signing new transaction. Every Sabu user can be an issuer (something like Lightning node) and earn Bitcoin because of issuing credit liability document (pretty much like banks). Ease of use: All a user needs to use protocol is install wallet -called Gazin- on mobile or desktop by one click. The user can be an issuer and issue transactions or be a creditor and buys Bitcoin or both simultaneously. Users can then transfer their money to each other in Sabu network. Every Sabu user can be a creditor and buy some Satoshi from issuer and spend it in small shopping. It seems that Bitcoiners can finally buy coffee with Bitcoin without worrying about transaction fee or system scalability or even recording transaction forever on Bitcoin blockchain. Privacy: Since the communication between nodes is PGP encrypted, and no transaction will go to record on Bitcoin blockchain, the Sabu protocol provides a strong privacy for transaction parties. Except sender and receiver, no one will know how much Bitcoin between who was transferred. Billions of micro transfers will be scattered between thousands of nodes without no central control point and no transaction history recording and absolutely no KYC. Scalability: Since the Sabu has no routing overhead and peers use the direct communication it will be more scalable than Lightning. New criteria: - Each transaction input must be 20,000 Satoshi or more. - Maximum liability in a single transaction would be 15,000 Satoshi. 14k for creditor whose credit is more than 1k, so he is eligible to have both MT & GT in his wallet, and 1k for the creditor without the right of having MT & GT due to his small amount of credit. - The maximum transaction fee (for Bitcoin blockchain) for Main Transaction is 5,000 Satoshi. For transaction with liability less than 4,000 Satoshi this fee would be less than 5,000 Satoshi relatively. - In Guarantee Transaction the issuer loses 1% to 68% of his output in favor of Bitcoin transaction fee depends to the liability amount. More liability more loss. - In Guarantee Transaction the creditor loses 100% to 78% of his output in favor of Bitcoin transaction fee in reverse of the credit amount. More credit less loss. - The transaction fee (for Bitcoin blockchain) for Guarantee Transaction would be transaction fee of Main Transaction plus 100% to 78% of creditor’s output plus 1% to 68% of issuer’s output. - The issuer has to issue both Main Transaction and Guarantee transaction and deliver them to creditor. Both issuer and creditor (sender and receiver) control these criteria before confirm the deal. Fraudulent activities risk: The griefers, - people who willing to spend time and money hurting someone else, even if they don't make a profit from it (other than schadenfreude). - still can hurt himself and the other party simultaneously, but the damage amount is reduced dramatically. The lowest amount that a griefer as a creditor can lose is 1,000 Satoshi to hurt the issuer 685 Satoshi (loss ratio 1.45), and the highest amount is losing 11,506 Satoshi to hurt issuer 4,720 Satoshi (loss ratio 2.43). In any case, a griefer still has trouble finding big number of victims, since the protocol is not centralized and the user’s information is scattered among thousands of different nodes. How can prevent the issuer from spending UTXO in a cheating way? There are two possible scenarios for fraudulent issuer. First is paying high Bitcoin transaction fee, even higher than Guarantee Transaction fee, with the intention of placing the transaction desired by the issuer in the next block. Even Guarantee Transaction will cause the issuer to waive part of his output in favor of Bitcoin transaction fee. Its loss is between 685 to 5,190 Satoshi. Therefore, carrying out this attack will not be economically viable. The second scenario is double spending the promised UTXO, hopping in a race condition, the cheating transaction win the Guarantee Transaction. The likelihood of success for this scenario is approximately 2 seconds / 10 minutes (0.3% chance). In other word, the issuer has 0.3% chance to win 10,000 Satoshi (15,000 Max liability in a transaction – 5,000 minimum transaction fee), and relatively he has 99.7% chance to lose 4,720 Satoshi. The risk to reward ratio is too high to consider this scenario as a practical attack at all. What if issuer is miner as well? What a wicked issuer can earn from a block full of fraudulent transactions or a real big batch transaction would be in maximum spending 10,000 promised UTXO as inputs. The issuer already got paid equal to 10,000 * 15,000 Satoshi from deceived creditors in fiat money or goods or services. He is a miner as well so the transaction fee is not the case, thus we can say all the 1.5 Bitcoin is the issuer/miner benefit. But a normal honest block usually makes same or more profit for its miner! So, what is the benefit of cheating creditors? The issuer/miner has to mine solely and take the risk of wasting energy for almost nothing advanced a normal honest participating in network! In other word, due to the small amount of inputs and outputs, spending these Satoshis on any type of Bitcoin transaction is not cost effective in most cases. What if creditor is miner as well? The wicked creditor in every case will lose part of his money, since he can only put Main transaction or Guarantee Transaction in next block. In first case he paid unnecessary Bitcoin transaction fee. In second case he paid even more unnecessary Bitcoin transaction fee. Conclusion: Till here, after tuning the transaction parameters and the criteria of a successful deal, seems most of the risks of Sabu protocol have been addressed. I intentionally didn’t talk about BIPxxx “mark/unmark promised UTXOs”, because the Sabu protocol will work enough good without touching current Bitcoin core protocol. In future, after implementing BIPxxx, the Sabu protocol can remove some limitations and improve its features and functionalities. What is the next step? The next step would be putting protocol in practice and developing a Minimum Viable Product (MVP). I am a developer and I think -for now- the best technology and stack to develop the protocol and the proper mobile wallet would be “react native”. The protocol and the software will be open source and under GPL v3.0. Let me know if you have alternate idea. At the moment I cannot work full-time on this project and I need some help, But I am gradually working on this project and looking forward to hear from Bitcoin real supporters. Regards Raymo d89a49057b817be0 this post on medium.com https://raymo-49157.medium.com/fine-tuning-sabu-in-order-to-minimize-the-protocol-risks-95361dc5282b