path: root/7e/88b1b7ed3f5256968072c10dd96b9dc9e47911

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