diff options
| author | raymo <raymo@riseup.net> | 2021-08-08 02:11:42 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-08-08 09:11:44 +0000 |
| commit | 09401aa06cbde7596f7c66c2042f2982d58fbb29 (patch) | |
| tree | def622188252a1133f828aaf81fda79768c66c78 | |
| parent | 88c2b2383e0ec276d22f8f964f50d9736c7f5448 (diff) | |
| download | pi-bitcoindev-09401aa06cbde7596f7c66c2042f2982d58fbb29.tar.gz pi-bitcoindev-09401aa06cbde7596f7c66c2042f2982d58fbb29.zip | |
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
| -rw-r--r-- | 7e/88b1b7ed3f5256968072c10dd96b9dc9e47911 | 361 |
1 files changed, 361 insertions, 0 deletions
diff --git a/7e/88b1b7ed3f5256968072c10dd96b9dc9e47911 b/7e/88b1b7ed3f5256968072c10dd96b9dc9e47911 new file mode 100644 index 000000000..91573c884 --- /dev/null +++ b/7e/88b1b7ed3f5256968072c10dd96b9dc9e47911 @@ -0,0 +1,361 @@ +Return-Path: <raymo@riseup.net> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id D302CC000E + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <6016816a7ea36b8a88f48d69462d0308@riseup.net> +References: <bea8122aea550f1141170829aac252af@riseup.net> + <CADvTj4q42bQ0mTWwdMyJM9UpW57pV0feZk-vYynPu91N_aZSZw@mail.gmail.com> + <CAGpPWDZtRnnv-Hinn4x=9ukJcuHkZv-6Yt32AK-9e+BJ=6r-kA@mail.gmail.com> + <f46159f0286fe48720bc3f3fead1b575@riseup.net> + <CAJowKgKELBmLdA-w5ghGoiWe5RQdNkKsV3OGRFbDJCOeA04AWw@mail.gmail.com> + <d8b3ba5b940473165ad72d689a01602a@riseup.net> + <CAGpPWDYAJE4jh=G2g=KSRuLLucEAyZGAD+r4XMpcmw6nk4+Wbg@mail.gmail.com> + <e843b5c28690557402b72fcd158dc1c2@riseup.net> + <CAGpPWDYPutiURUtenkU_zr4nW_tZVe5oWykXxWCDyROwqTdW5Q@mail.gmail.com> + <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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <raymo@riseup.net> d89a49057b817be0 + + + +this post on medium.com +https://raymo-49157.medium.com/fine-tuning-sabu-in-order-to-minimize-the-protocol-risks-95361dc5282b + |