Scaling Bitcoin by Sabu protocol, risks and benefits

After introducing Sabu protocol as a solution for Bitcoin scaling, I shared this idea with Bitcoin developers through the bitcoin-dev mailing list.
I got some constructive feedbacks and critiques leading me to add this part to the proposal which I was skipped due to brevity of proposal introduction.
Here I will investigate on more real live scenarios, general usages and corner cases, and the consequences of some attacks or buggy implementation of protocol, as well as different actors (malicious, irrational, profit seeker, griefer, stupid, reckless, incompetent, etc.) activity effects.

In proposal introduction (previous post), I did not talk about Lightning deliberately, although it seems that this solution is an alternative to Lightning.
Most of readers misunderstood Sabu and asking what differs it from Lightning?
Indeed, Sabu has nothing with Lightning. It has totally different design, network architecture, security model and implementation. The only thing in common with Lightning is both are intended to cover micro payments.
The good thing about Bitcoin is that it does not require any kind of permission. Consequently, related products do not need to ask permission too. We are in a permission-less free market. I think Sabu will work perfectly and if a group of users think like me, we are done. Sabu will work parallel the other scaling solutions without need to drive them out.
However, I have made a comparison between Sabu, on-chain and Lightning transactions to get a clearer understanding of the advantages and disadvantages of Sabu and answer to “why we should implement and use Sabu in our day-to-day deals”.
Most probably this paper is not comprehensive document, therefore this article will be updated.

The protocol actors

Three actors are involved in making this protocol work.

• Issuer who is owner of UTXO which will used as transaction input.
• Creditor who pays to issuer (in forms of money, goods or services) in exchange of Satoshi. These Satoshis are not recorded in Bitcoin blockchain, instead are represented by a bunch of valid transactions. These are issuer’s liabilities and creditors will spend these liabilities as a kind of money in Sabu network.
• Miners who are the well-known actors in Bitcoin ecosystem

The core idea of Sabu protocol is about using a strictly formed transaction in small payments, in order to reduce cheating risks to near zero, based on economically rationality behaviors of actors.
Although the transactions are valid Bitcoin transaction and either issuer or creditor can send them to Bitcoin network (through the Gazin wallet and fully automatic), but due to cost of Bitcoin transaction fee they will circulate these transactions with very lower fee in Sabu network.
While some creditors with enough high amount of credit may/can aggregate their thousands small credits (transactions) in one single transaction and record it on Bitcoin blockchain (obviously by paying Bitcoin transaction fee).

The protocol risks

Sabu protocol has to defend creditors against issuers and vice versa. Given the fact that miners cannot abuse this system without penalty (they pay electricity bill in advance), and the fact that they cannot harm system unless they are issuer (in order to spend promised UTXOs in a selfish way) or creditor (in order to misuse GTs in favor of miner transactions fee) as well, or at least collaborate with one or both of them in a conspiracy, we can ignore solo miner attacks.

Since Sabu hasn’t the multi signature in its design, the funds (UTXOs) can be signed only by issuer which is literally the owner of that money. He signs a UTXO and promise a part of it to a creditor. This liability is nothing than a valid Bitcoin transaction in which one of the transaction’s outputs is dedicated to the address that controlled by the creditor.
Before, during or after delivering the signed transactions to creditor and obtaining the equal fiat money, good or services in exchange, the issuer always can sign another transaction and use the same promised UTXO as transaction input and transfer funds to himself or whoever he wants. Indeed, the issuer can act contrary to his promise and no one can stop him! In order to reduce this risk, Sabu imposes some restriction and rules in order to make enough high economic cost on fraudulent actors. The goal is hinder the “rational” issuer from fraudulent activities as explained in the previous paper (https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180). I also explained more details about Main Transaction and Guarantee Transaction in mailing list emails. For the sake of integrity, I’ll gather all these discussions here.
In order to respect the mailing list member’s time which already read these discussions, and to make the document more structured, I divided the discussions to two different parts.

• The “rational scenarios” which was my concentration on first document and most part of mailing list discussions were about analyzing the attacks assuming the rationality of actors.
• The “irrational scenarios” which is new, and we will investigate on all other possibilities in real life.

The mailing list member can simply jump the first part which has nothing new except neatness of content.

Rational scenarios

* * *
The fraudulent issuer:
what if an issuer spends all UTXOs to itself?
What if the issuer pays higher feeRate (transaction fee / transaction size) for a fraudulent transaction and outbid the GT?
Doesn’t RBF and/or CPFP effect on Sabu security model?
Guarantee Transactions (GT) being higher-fee is ***not*** assured. Fee rates are always bump able — — the issuer only needs to directly contact a miner and offer a fee to take a specific fraudulent transaction on the next block proposal, conditional on the transaction *actually* getting into a block. Such “side fees” are always possible.

The security model of Sabu is enforcing economic cost to cheater. It doesn’t matter how a cheater issuer puts the fraudulent transaction in next block. What is important is, the cheater issuer has to pay more Bitcoin comparing the honest activity and fraud will result cheater bankruptcy always.

Considering this scenario;
1. The issuer creates and signs 2 MT and GT transactions and delivers them to creditor.
2. The creditor controls very strict conditions and prerequisites of 2 transaction. See “The valid transaction criteria” for condition details.
3. If the 2 transactions meet the conditions, so they are valid, thus the deal is valid, then the creditor hand overs the equivalent of received Satoshi in other resources (fiat money, goods or services).
4. Now creditor has MT and GT document in his hand as the issuer liability. Everything looks good, but the issuer decides to spend the same promised UTXO in another cheating transaction (CT).
5. The creditor wallet becomes aware of this renege (usually in few seconds).
6. The creditor wallet sends the GT to Bitcoin network.

Now miners will face two transactions that are using same UTXO, but have different outputs and different Bitcoin-transaction-fees. Obviously, miners will choose the transaction with higher feeRate. Note the fact that Bitcoin-transaction-fee in a GT is too higher than MT.

Optimum transaction for a fraudulent issuer:
Main Transaction (40k sats):
* Issuer: 14k sats
* Creditor: 16k sats (the real credit of creditor is 20k)
* Fee: 10k sats (6k from issuer + 4k from creditor)

Guarantee Transaction (40k sats):
* Issuer: 9,800 sats
* Creditor: 2,400 sats
* Fee: 10k + 4,200 from issuer + 13,600 from creditor = 27,800 sats

Cheating Transaction (40k sats):
* Issuer: 12,199 sats
* Creditor: 0 sats
* Fee: 27,800 + 1 sats

Issuer already got equal to 20k Sats in form of fiat money, goods or services from creditor. He created the Main Transaction in exchange. As you can see 14k of this liability is a direct output to creditor, and 4k of this credit is used to pay the transaction fee (if the transaction was sent to Bitcoin network).
By the way the creditor always can spend 20k Sats in Sabu network.
The Guarantee transaction (GT) is prepared based on the Main Transaction. The formula is straight forward. Cut 30% of issuer money and 85% of creditor money in favor of Bitcoin transaction fee.

Looking at these 2 transactions, you will find while the Bitcoin transaction fee for MT is 10K Sat, this fee for GT is almost 28K Sat.
And please consider the fact that maximum liability amount the issuer can issue is 20K Sat for a transaction with at least 40K Sat input. It means the maximum amount of trick in a single transaction will gain 20,000 Sat.
Now the question is how much Bitcoin-transaction-fee the issuer has to pay to miner in order to convince him to put cheating transaction in next block and outbids the GT and MT?
The answer is the GT fee plus at least 1 Sat. it will be 27,801 Sat. So, the issuer will lose 27,801 Sat to gain 20,000 Sat for each transaction. The issuer is a loser. It is whole the scenario and for issuer always is better to not cheat creditors.
Indeed, because of strict number limitations in Main Transaction and Guarantee Transaction, no arbitrary UTXO spending by issuer nor self-paying transaction can make more output and more benefits to issuer than respecting the already issued MT. please investigate on figure 1.0. (Security checks) and the proper script on https://github.com/raymaot/transaction-numbers-and-coefficients/blob/main/sabu_tx_security_check.py for more details.
Any external action like RBF or CPFP or directly talking to miner, must be economically beneficial to be considered as a threat to protocol, otherwise it is a possibility of an irrational action and wasting funds by issuer.
There is one possibility of attack which I explained in “Conspiracy between a miner (mining pool) and a group of …”
After all, this protocol intended to use for very small amount (less than 20,000 Satoshi worth), so in worst case, the attacker can only “hurt the other side” equal to 20,000 Sat for each single attack to a single transaction while not earned benefit at all.
Additionally, because the system is distributed and there is no central server containing issuers and creditors info and the transactions detail, bots or mass attack scenarios won’t work properly on this model.

* * *
You assume here that Alice the issuer only has a single UTXO and that it creates a single transaction spending that UTXO. Miners consider feeRate (transaction fee / transaction length), but your security analysis is dependent on *fee* and not feeRate.
What if Alice creates 1000 UTXOs, promises GTs and MTs to 1000 different Bobs?
Now, a GT has one input and two outputs. 1000 GTs have 1000 overheads (`nLockTime` and `nVersion` and so on), 1000 inputs, and 2000 outputs.
Now Alice the issuer, being the sole signer, can create a fraudulent transaction that spends all 1000 UTXOs and spends it to a single Carol output.
This fraudulent transaction has 1 overhead, 1000 inputs, and 1 output.
Do you think Alice can get a better feeRate on that transaction while paying a lower aggregate *fee* than all the GTs combined?

I didn’t suppose Alice has only one UTXO, instead I expect every issuer use hundreds or even millions UTXOs (for optimal benefit each worth exactly 40,000 Satoshi) in Sabu protocol in order to earn notable Sabu-transactions-fees daily.
Your scenario is correct and Alice can send a batch transaction which has higher fee rate, but less fee comparing total fees of N number of GT transaction.
It is true, the batch transaction will win the race and will go to next block instead of N small GT transactions. But Alice herself is not the winner, since she paid a huge transaction fee to miner, while in honest acting didn’t have to pay at all.

Let’s show it by numbers.
Imagine Alice convinced some people to pay her money and accept the MT and GT transactions in exchange.
Alice issued N transactions and delivered to these guys.
Till now Alice got money equal to N * Maximum liability per transaction, which is equal to N * 20,000 Sat.

a single GT length = length of Critical part of GT (named C) + length of Redundant part of GT (named R)

Coefficient of Honesty benefits (called H) = C/R
The bigger H means less Redundant part, means less benefit in Batch transaction.
The worst H would be 1 or less than 1. I can guess H in Bitcoin transactions is 4 or higher, but for now we take it 4. Probably experts can help us and tell what H is exactly.

The N single GTs length = N * (C + R)
One batch transaction length = (N * C) + R

The GT feeRate = GTfee / (C + R)
The batch transaction feeRate = batchFee / ((N * C) + R)
We need to batch transaction fee rate be higher than each single GT fee rate (more or less the fee rate for all GTs are same).
Thus
batchFee / ((N * C) + R) must be bigger or at least equal to GTfee / (C + R)
so,
batchFee / ((N * C) + R) >= GTfee / (C + R)

we already knew H = C/R then C = HR

after simplifying we will have:
batchFee >= (GTfee * ((N * H) + 1)) / (H + 1)

So, this is the minimum fee that Alice has to pay for her batch transaction in order to outbid the GTs.

Let’s put the numbers
From my previous examples and calculations, we already knew the GTfee is almost 25,500 Satoshi
H is 4
I think N in maximum exploitation of block space would be 10,000. If Alice takes entire block space, she won’t be able to put more than 10,000 inputs for a single batch transaction in one block.
So,
batchFee must be higher than (25,500 * ((10,000 * 4) + 1)) / (4 + 1)
batchFee must be higher than 2.04 Bitcoins. While if Alice was acting honestly, she had to pay absolutely zero BTC-transaction-fee, since the Sabu transactions are aimed to be circulated in Sabu network forever.
But how much benefit Alice got? We already knew that Alice had fooled Some people by N transactions and got 10,000 transaction * 20,000 Max liability per transaction. She got 2 Bitcoins.
After all, she lost 0.04 BTC. She definitely is a loser, unless she has conspiracy with miners which is another scenario and I already explained it in “Conspiracy between a miner (mining pool) and a group of …”

Note these facts:
H is higher than 4.
It is impossible to fit a batch transaction with 10,000 inputs and one output in a block.
And after all we can simply hedge batch transaction benefits by fine tuning the “maximum allowed liability per transaction”.
Finally, the complementary protection would be the BIPxxx “mark/unmark promised UTXOs”.

* * *
What if the issuer promise a UTXO to a Sabu user, then tries to double-spend same UTXO and create a fraudulent transaction and tries to get services in exchange of the zero-confirmation transaction? Why do you think nobody accepts zero-confirmation transactions?
What about he builds a bot that would wreak havoc on Sabu.

True, there are few businesses that accept zero confirm transactions already. In first step they simply can double-check the received transactions with doc-watchers. It is matter of couple of hours coding. In second step they can use Sabu protocol literally. Since the zero-confirmation existed for support fast small payments they can switch their businesses to use Sabu payment instead of classic Bitcoin transactions. The use of Sabu will be more beneficial, flexible and reliable for their businesses.

* * *
The fraudulent creditor:
What stops the creditor maliciously publishing the GT despite the issuer acting in good faith?

Because of Sabu defending mechanism, the creditors have a special type of valid Bitcoin transactions which can harm issuer and creditor in favor of miner income, but the creditors should/will use it as last resort. Again, it assumed a rational behavior of creditors. But we will go to cases of irrational or malevolent creditors later.
In order to minimize the losing money, the creditor charges its account equal to 5k Sats (the minimum credit by which creditor is qualified to receive the MT & GT in his wallet).

Optimum transaction for a fraudulent creditor:

Main Transaction (40k sats):
* Issuer: 29k sats
* Creditor: 1k sats (the real credit of creditor is 5k)
* Fee: 10k sats (fixed 6k from issuer + 4k from creditor)

Guarantee Transaction (40k sats):
* Issuer: 20,300 sats
* Creditor: 150 sats
* Fee: 10k + 8,700 from issuer + 850 from creditor = 19,550 sats

The economic lost prevents creditors to send GT to Bitcoin network. Since in GT the creditor would get only 150 Sats, while he paid 5,000 Sats to issuer.
In case of sending GT to Bitcoin network, the creditor loses 5,000–150 Sats = 4,850 Sats. While the issuer loses 40,000–5k (fiat money up front) — 20,300 = 14,700 Sats.
This is notable risk for issuer! One solution to reduce this risk would be changing “The valid transaction criteria” and set the new restricts. This update will reduce the issuer loses, but it still is a subject of any self-destructive attacks.

* * *
Email Address would be best avoided if possible. making your protocol transport-agnostic, allowing users of your protocol to use any transport they want.

This part should be the least important in Bitcoin scaling point of view, but it returned to a most controversial part of Sabu proposal for some developers!
On the other hand, because of particular point of view about this project and its future features I intentionally used email as a decentralized handler in cyberspace in order to find the others and to be find by the others and also a neutral communication tool in Sabu network architecture. Later I’ll explain my reasons, but for now I insist on the fact that email is an optional feature of the wallet. Indeed, the protocol is transparent-agnostic and people can use email as a wallet-to-wallet communication tool, or use another classic server-client communication (pretty much like all existed mobile wallets) or peer-to-peer models. We will implement all in Gazin mobile wallet and users can chose one or more communication method simultaneously.

* * *
Email is a central system, why you claim it is decentralized?

what I consider decentralization in Sabu is the ability of communication without dependency to any company. In order to have a successful communication you need a way to find others address and a mean to send your message. I suggest email for both. Why?
As an example, what can you do if the twitter bans your account? Nothing! Your content and entire connections will be lost. You cannot find the others (on twitter), they cannot find you neither, there will stop all connections.
But if you form your friends list in your mobile (or computer) and have their PGP public keys and they have yours, and use email as a dual-purpose tool. First as a handler (the tool for finding and to be found in internet) and second as a communication tool.
Thus, no one can stop you, ban you or limit you to send/receive transaction to/from anyone.
What I am trying to say is using email is far better than account (username) in a limited central service like twitter, Facebook, telegram… or even in future Sabu servers!
You have your connections under your control in your phone. You can easily change your email and use a new email or even a new email service provider without losing your connections and your control over it.
You just sign your new email address and send it to your friend’s circle and notify them about changes.
Of course, email is not good for millions of followers but it is obviously good for managing your payment network of hundreds of people (either issuers or creditors).
This is my definition of decentralization. The identity sovereignty. Indeed, this idea is not new, we already have it by “web of trust”. I just made it more friendly and more practical.

* * *
Email is slow and full of spam and junk.

First of all, I have to explain a part of design spec. Each mobile wallet, in order to use email-wallet-to-wallet system, has to have a fresh email address which is dedicated to Sabu protocol activities. The wallet has access to this email address and read, delete inbox or send emails. So, the spam or spam filter problem is not the case because wallet automatically read entire inbox and drops the emails which are not encrypted by proper public PGP key and so on.
In my opinion email is the ONLY neutral, free (nonproprietary) and open protocol/technology for communication in the world that its infrastructure is well-established and is accessible all over the globe. Even in countries with low internet speed.
I intentionally chose email as main communication mean. Because non-technical people can easily make an email address or change it (comparing register a domain and establish a website or use an static IP) and notify the friends about new address and they can easily send and receive Bitcoin just by knowing email addresses or scanning its QR code. Once the user installs the wallet (called Gazin), he will config and record his 12 seed words. The wallet also creates the PGP Pub/Priv key pair based on these 12 words seeds and signs the wallet email address too. All are taking place behind the scene and user only sees its wallet is ready.
So, these 12 worlds are user’s wealth protector and identity sovereignty as well. User adds friend’s wallet email address or scan its QR code. The rest is PGP encrypted emails (handshake, agreement and transactions) between two wallets. No one needs to ask a central service to have an account. Pure Cypherpunk users can run their personal email server or even better their freedombox https://freedomboxfoundation.org. So no one can stop user from using this system (Bitcoin + Sabu + Gazin) or ban his account.
The wallet owner can easily and fast immigrate to new email address (or even different email service provider) and sign new address and notify to his friends circle with no real barrier.
While these are all benefits of using email as a user identifier in system, there could be some privacy issue in some levels.
For example, most email service provider impose some sort of KYC or ask user mobile number, but there are other providers which are respecting users’ privacy. Implicitly prevalence of Sabu users creates more demands for this privacy-respecter-companies, so these companies will be increased.
Another issue would be global passive spying or full-pipe project will find who do transaction with who. Since communications are PGP encrypted it won’t be clear who is sender or receiver or how much is transferred or even if they are really parties in a transaction or it is just a fake noise connection!
The forward secrecy also would be another issue. although these are mostly the privacy issues rather than Sabu intrinsic problems.
Some other disadvantage of email is latency, so some third parties would easily provide the optional alternate communication services for wallet, e.g Matrix, Nym network, Onion, I2P, classic central servers, etc. to compensate the speed and/or privacy issues.
These are all communication means and the wallet can simply use one or more methods in parallel. Users can decide between an unstoppable, permission less, self-sovereignty and decentralized pure peer-to-peer communication network (with some resolvable privacy issues) or some efficient central limited network.
As always it is a trade-off and only after putting in practice, we will find which solution the wallet users will choose. Speed vs privacy, sovereignty and independence.

* * *
your protocol should always assume the email system is fully compromised, and only send public information over email.

What I got is:
Email is not good because the sender and receiver are compromised.
Email is not good because the message content is revealed.
So, I can claim same argue about any other client/server model. Since the server (website) service provider will ask some sort of KYC. And even if the service provider claims an end-to-end encryption, it still can read the communication content. Why we should trust their word? Why do not control our encryption keys? And just feed the service provider the locally-encrypted content.
In my model the passive listener can see the encrypted messages and only can discover who is communicate to whom. He can make a graph of connections. Although it is a threat for privacy but the server/client model has this flaw inherently, since provider already knew everything about everyone. In my model at least users can make some fake connections and send some fake emails in order to inject noise to communications.
Please note the fact that entire communication between mobile wallets (via emails) are asymmetric PGP encrypted. The PGP keys are controlled by end users unlike ALL pretending secure messengers (e.g WhatsApp, signal, zoom, etc.).
The main concern is about the way of exchanging PGP public key, the most secure way is in-person PGP key exchanging (scanning QR code). And later trusting people by signature of friend of friend of a friend.
After that for payments the wallets communicate in PGP encrypted messages and they can transfer Bitcoin address through an PGP encrypted cipher, thus no revealing Bitcoin address to public would occur. Neither the amounts of transactions will be reviled.
There for it would be a good practice for shops to put their email and PGP public key on shop website and/or PGP public key servers, instead of putting Bitcoin address on website or relying on 3rd party services to hide their Bitcoin payment addresses.
Again, it is user’s decision between an unstoppable, permission less, self-sovereignty and decentralized pure peer-to-peer communication network (with some resolvable privacy issues) or some efficient, privacy-mimic central limited network.

Let me know if I missed some drawbacks about email. Hopefully this would lead us to improve email instead of letting it die. I strongly support email technology, because of its neutrality.

* * *
You should really look at it from the perspective of the customer! What would the average Joe think of this? I think your UX will be fairly awful.

About the usability and user-friendliness of Sabu, although the protocol is based on collaborating 2 different peer-to-peer networks and 3 classic server/client networks, but the end user (mobile wallet user) doesn’t see any of these complexities.
The system will be super user friendly, the average joe will not aware of all these complexities. The end user simply installs the mobile/desktop wallet and add her/his friends to his phone-book by adding their email address or scanning their QR code (containing the email address and public PGP key). After that s/he can immediately start to send/receive Bitcoin through Sabu network. Entire communications between wallets are PGP encrypted.
Another good point in Sabu design is, the 12 seed words are using for both Bitcoin wallet private key and the PGP private key. So, it is the key of user wealth and its identity as well.
All these complexities, validations and communications are behind the scene and on our technical shoulder. We are here to make the things make the life easier for people.
The biggest challenge would be the latency of email-based communications, which needs to be investigated in details. BTW this is not a big deal, considering the sovereignty and the freedom which are bringing to our financial activities.

* * *
Do issuers going to entrust Sabu with twice the amount of bitcoins just to be able to spend?
Additionally, considering the risks of losing 30% of money + high Bitcoin transaction fee because of malevolent creditors.

It is a free market. Some Bitcoin owners will find this protocol and its business model enough profitable and will accept the risks. They will use thousands of small UTXOs and handle million transactions per day and by this earn a significant income.

* * *
Why is there a 10 sat fee on each transaction? Where does that fee go?

The 10 Sat fee is Sabu-transaction-fee and goes to issuers to incentivize UTXO owners to put their money in system and prepare money transfer service for the creditors, pretty much like banks.
This number is my suggestion, but can be changed to something higher or lesser or even being customized for each issuer (Banks with high fee and more speed/reliability or less fee and less speed but more distributed).
Typically, Issuers put an UTXOs each worth 40,000 Sat and issue a liability (transaction) worth 20,000 or less. So issuer can use thousand UTXOs (each worth 40,000 Sat) and issue thousand debt-document (worth 20,000,000 debit) and earn significant Sabu-transaction-fee daily.
No need to say the issuer also imposes the fiat to BTC exchange rate in first place. They can earn even more benefits by selling BTC a little higher than market price. The potential target would be penny savers which potentially buy very small amount each time. So, teenagers or people with low income specially can save their first Satoshis.

* * *
About doc-watchers, you mention that there will be a p2p network to gossip fund transfers and that will prevent an issuer from double spending. The problem there is that network latency is non-zero, large network partitions are both real and common, and nodes can come and go anytime (hardware failure, power failure, network partition healing, just because they feel like it, etc.). Different nodes on the network might hear about different, conflicting transactions. Nodes will need a way to all come to consensus on what the right set of “sent notes” is.

Yes, there is latency but it doesn’t hurt the consensus on Sabu protocol. Please consider figure 7. inter creditors Bitcoin transfer as an example. By the way in all money transferring between issuer -> creditor or creditor->creditor, the receiver wallet “always” controls the doc-watcher client to be ensure the fact that the delivered debt-document (aka transaction), already exist on the doc-watcher sites. If that particular document doesn’t exist on doc-watcher, the wallet won’t accept the deal as a settled deal. Therefore, in this case, it is not the Bitcoin software’s responsibility, instead it is the responsibility of creditor. To be sure the promised UTXO is broadcasted to entire network.

* * *
I think Sabu will end up reinventing a lot of the problems solved by Bitcoin.

The Sabu protocol is not a Bitcoin competitor. It proposes a complementary tool for Bitcoin which came from a different point of view. Note the fact that Sabu protocol realizes a different model of decentralization. In Sabu there is no DLT and all consensus are between small set of users (most of time between one issuer and one creditor). In Sabu there is no obligation for everyone knowing everything about every transaction. Each participant only knows about its interest. Alongside there is a gossip mirroring of all transaction that flood to the clients a light weight information of a tuple [UTXO, transaction-Merkle-root] which reveals nothing than a particular UTXO is promised to someone, to public. These gossip nodes (doc-watchers) are not corruptible since it works in a simple proof-of-existence (true-positive) model. And no one can mutilate it by censor transactions. The proposal has its innovations and it’s challenges as well. It planning to carving out a niche for itself as one of the most popular Bitcoin micro payment system around.

* * *
What happens if my issuer is offline? The creditor can’t spend his Bitcoins anymore (unless he goes on-chain which is what we’re trying to avoid here).

This is the downside of protocol, like Lightning if the party goes offline, you cannot do anything except sending the latest signed transaction(s) to Bitcoin network.
The chances are each creditor has a bunch of debt-doc (transaction) issued by different issuers. Hopefully he will find enough transaction, issued by online issuers, to cover his shopping costs.
In long run there will be some professional issuers with million dollars daily turnover and 99.99% online and secure servers, parallel to million other small issuers.

* * *
It is vulnerable to sybil attacks or where the recipient is a victim of a proxy attack. If the recipient is not connected to a valid Network, then double spends could be allowed. Consider a large department store. If I put a “fence” around that store and control all of its outbound peer connections, I can then allow double spends for the duration of my visit at the store.

As long as this protocol is intended for use of transactions around a dollar or so I don’t see that being a financially lucrative attack. However, in order to defend against these, large retailers would have to have their own doc-watcher node and multiple secured-encrypted connections to other doc-watcher as distributed / trusted nodes.

* * *
The *largest* safe payment will vary depending on on-chain mempool state, and if the mempool is almost empty, the largest safe payment will be much smaller than at other times.

All these MT & GT transactions are formed relatively (the numbers in GT are calculated based on MT), so the feeRate of transactions are relative, so no matter how much mempool is full or empty. Thus, because of relatively higher feeRate, the GT always takes place in next block, and before the MT, and since both GT and MT are spending the same UTXO, it is a kind of double-spending and the miner simply drops the MT. The only consideration for mempool is the propagation delay which makes almost 0.03% chance for fraudulent issuer to cheat the creditor and it is explained in detail in “GT propagation delay”.

* * *
How normal transactions happen in their entirety?

In Sabu protocol we have two type of actors.
The issuers who own Bitcoin (they own UTXOs on Bitcoin blockchain), and the creditors who will own Bitcoins (the UTXOs on Bitcoin blockchain), if the issuer or the creditor sends the prepared transaction to Bitcoin network. But for now, creditors have the transaction in their hand. Before sending this transaction to Bitcoin network it acts (in Sabu protocol and Sabu network) as a liability of issuer.
The story always starts from issuer, the person who get money or goods or services from a creditor and in exchange creates and sings a valid Bitcoin transaction by which the issuer spends his UTXO and as a one of the outputs of the transaction, there will be an output for creditor’s address equal to the money issuer already get paid.
This transaction is a valid transaction which is signed “only” by issuer. The outputs of transaction are just and exact balance of the parties (issuer and creditor).

Let’s, imagine the creditor A payed 5$ (almost equal to 15,000 Sat) to issuer.
1. Creditor A $5 -> Issuer

Thus, issuer will create and sign a transaction by which he spends 40,000 Sat and the outputs will be
11,000 for creditor (the creditor has to pay 4,000 Sat in favor of transaction fee),
10,000 for Bitcoin-transaction-fee (4,000 by creditor and 6,000 by issuer) and
19,000 change back to issuer account address.
It is our Main Transaction (MT) which is a pretty normal and valid transaction.

2. Issuer creates and shares transactions:
Main Transaction (40k sats):
* Issuer: 19k sats
* Creditor A: 11k sats
* Fee: 10k sats (4k from creditor, 6k from issuer)

Alongside the MT, issuer creates and signs a Guarantee Transaction (GT). In GT issuer spends same 40,000 Sat UTXO as input, and as outputs the creditor will get 15% of his 11,000 Sat in Main Transaction. Thus, the creditor output will be 1,650 Sat and the rest of creditor’s money (11,000–1,650 = 9,350 Sat) will be added to transaction fee.
In GT also issuer will lose 30% of his money. New output for issuer will be 19,000 * 70% = 13,300 and the rest will be added to transaction fee (19,000–13,300 = 5,700 Sat)
Thus, the new transaction fee in GT will be 10,000 + 9,350 + 5,700 = 25,050 Sat

Guarantee Transaction (40k sats):
* Issuer: 13,300 sats
* Creditor A: 1,650 sats
* Fee: 25,050 sats

Now the creditor has 2 valid transactions (MT and GT) in his hands. He can send either MT or GT or both to Bitcoin Network. But in all cases, he will lose a portion of his money in favor of transaction fee (miner’s income). So, rationally he will never send transactions to Bitcoin network unless he wants consciously hurt himself.

The creditor always prefers to spend his credit inside the Sabu protocol. It is “how normal transactions happen in their entirety.” Creditor A has equal to 15,000 Sat credit. Say he wants to buy a caffe worth 6,000 Sat. He has to ask the issuer to nullify previous MT and GT, and create and sign new transaction and cut 6,000 Sat from his credit and transfer it to a new creditor (say Creditor B).
The new transaction will use same 40,000 UTXO as input so:
3. Creditor A, 6k sats -> Creditor B. Issuer creates and shares new transactions:

Main Transaction (40k sats):
* Issuer: 19k sats
* Creditor A: 6,500 sats
* Creditor B: 4,500 sats
* Fee: 10k sats (4k from creditors 2.5k + 1.5k, 6k from issuer)

Guarantee Transaction (40k sats):
* Issuer: 13,300 sats
* Creditor A: 975 sats
* Creditor B: 675 sats
* Fee: 25,050 sats

This is the new Main Transaction, and as you can see the Creditor A and Creditor B have their new credit in transaction.
Note: due to simplicity I just rounded the numbers and skipped the Sabu-transaction-fee.
I just wrote this long story to explain how creditors just transfer money in between.
If we take a snapshot of Sabu network, we will see millions of valid transactions flowing in network and none of the issuers or creditors will send these transactions to Bitcoin network due the transaction fee, while in Bitcoin blockchain nothing is changed! The UTXOs are untouched, and no one can say which UTXO is promised to who.
It is a pretty secure off-chain protocol.

* * *
What would this BIPxxx “mark/unmark promised UTXOs” look like, though it’s unlikely to get much positive feedback?
Would this BIPxxx lead the mining to centralization?
Doing something like that BIPxxx would be at very least quite complex, and at worst impossible to do securely. The whole reason why bitcoin’s blockchain exists in the first place is to be a single source of truth for transactions. The mempool is not a source of truth for consensus. The Sabu network could not be a source of truth either for consensus, without some serious innovations (that may not be possible). It isn’t as simple as you seem to be thinking.

I am not in rush to apply this upgrade on Bitcoin protocol, instead I am actively working in order to realize the Sabu protocol and Gazin wallet.
Later the Sabu community will carry out the BIPxxx. Hopefully we will have enough time to discuss about BIPxxx and its implementation and so on. Definitely it wouldn’t be an easy-going process.
The doc-watcher implementation is not centralized at all. The doc-watchers network will be a peer-to-peer torrent-like network where nodes just gossip the very light information about used UTXOs in Sabu protocol. All nodes will receive information and flood it to other nodes. So, all nodes just mirror same information.
Two types of information are transferring through this peer-to-peer doc-watcher network.

• One is a very minimal record history of the promised UTXOs and a Merkle root of proper Sabu transactions. This information will be used by mobile wallet to be ensure issuer didn’t promise same UTXO to different creditors.
• The second data type are moving through doc-watchers’ nodes are signed UTXOs in order to signal to miners the fact that this UTXO is promised to some creditors. So, miners won’t allow this UTXO to be used in counter-promise usages. In order to release (un-pledge) this promised UTXO and unmark it on doc-watcher servers, the issuer has to sign UTXO alongside a release request.

It is roughly what I suppose to be implemented and be respected by miners in future. It wouldn’t be centralized unless you believe torrent is centralized. Miners can/will control UTXOs status (in sense of is promised to someone or not) before putting them in next bock batch template.
After implementing BIPxxx, the doc-watcher will be a part of Bitcoin core code and the doc-watcher servers will be literally the Bitcoin nodes.

By implementing BIPxxx indeed, we will go to equip miners with a useful tool to recognize promised UTXOs and not putting them in next block. This feature will be useful not only for Sabu, but also for any other future innovative features (for example smart contracts).
No matter why a UTXO owner mark his UTXO as un-spendable and by which circumstance will be again spendable. It provides an off-chain conditional payment system on top of current Bitcoin.

As far as Sabu is concerned, the process is starting from the issuer (UTXO owner). He signs a UTXO as a promised UTXO (a kind of liability) and broadcasts its signed document to Bitcoin network, pretty much like broadcasting a normal signed transaction. Every node receives this signed-promised-UTXO doc, adds a proper record row to promised UTXOs, and relay and broadcast it to the peers.

The related rules to these liability docs are simple, clear and explicit.

• The Gazin wallet considers a transaction (or a deal) as a valid transaction if and only if the spent UTXO(s) is already marked as a promised UTXO in miners records.
• The miner adds the UTXO to marked-as-promised UTXO records immediately after receiving the signed document and validating it. The promised UTXO would remain as marked for hours, days or even months.
• Miners won’t put marked UTXOs in next block, unless the UTXO owner requests for unmarking and sings that request.
• The miner unmarks a promised UTXO after 2 blocks (or whatever secure gap) after receiving signed unmark request.

* * *
Sabu has slightly greater risk comparing lightning.

Somehow It is not true, since creditors can manage they risk, and limit their credit to 5, 10 or 20 Dollar or 50$. It is totally up to creditor to accept more liability from issuers (or a group of certain issuers) or not.
The creditor can keep his credit around a fix number. That is, the creditor spends a part of his credit and then again increase its credit. Let imagine you already payed 5$ to an issuer and you got 15,000 Sat credit in your wallet. So, you will spend this 15,000 Sat (buy coffee, ice-cream, etc.) till your wallet run out of Satoshi and again you will pay another 5$ to issuer and get new 15,000 sat credit. Since all of these transactions has near zero cost you are not obliged to charge your wallet 200$ in one shot.
It is absolutely low risk deal. In worst case the creditor (you) will lose 5$.
On the other hand, the issuers also can manage their risks by deciding about UTXOs amount. An issuer can put one shot or million shots (each shot is a UTXO worth at least 40k Satoshi) in Sabu protocol and takes his affordable risks.
In general Sabu provides cheaper and a larger number of transactions comparing the Lightning.
Finally, once the BIPxxx was implemented, the risks will be absolutely zero.

* * *
Conspiracy between a miner (mining pool) and a group of issuers.
Conspiracy between a miner (mining pool) and a group of creditors.
Miners regularly change block headers, and if they don’t broadcast the transactions there wouldn’t really be a time limit, so even a relatively small miner would be able to stealthily mine the fraudulent transactions given enough time.
By the way this risk of miner attacks certainly incentivizes miners to become issuers or creditors and scam people. Even if a small miner who mines one block a year does this, they can mine all Guarantee Transactions in their possession or double spend the UTXOs they already promised. Larger miners that mine one block every few days can scam that much more often.

In this scenario a miner (or a mining pool) and an issuer (or a group of issuers) decide to cheat the creditors. The issuers get money from creditors and in exchange deliver them the MT & GT as debt-document. In parallel the miners aggregate all promised UTXOs in a giant transaction as the inputs and divide the outputs in between miners and issuers. Miners start to mine this block.
We already knew that maximum liability the issuer can issue per each transaction with at-least 40k Sat input is 20k Sat.
I guess maximum exploitation of block space would be 10,000. If they take entire block space, they won’t be able to put more than 10,000 inputs for a single batch transaction in one block. So, at most they can misuse 10,000 promised UTXOs. Total illicit gain of miner, issuers conspiracy attack will be 10,000 * 20k Sat equal to 2 Bitcoin.
The second scenario is about conspiracy between miners and a group of creditors in order to grab high transaction fees of Guarantee Transactions. In this scenario the creditors cannot create a giant transaction, since they cannot sign anything. They have to fill the block space by Guarantee Transactions. Maximum 6,000 normal transactions they can put in a block. For each Guarantee Transaction issuer pays 6k Sat + 30% of maximum change back of issuer = 6k Sat + 30% * 15k Sat = 10,500 Sat.
So, the maximum total illicit gain of miner, creditors conspiracy attack will be 0.63 Bitcoin.
It looks for miner collaborating with issuers is more profitable. 2 extra Bitcoin per block!
This income is enough big, but must be divided between issuers and miners somehow.

Some facts:
In order to achieve this conspiracy, the mining pool has to mine the block in stealth, lonely and without broadcasting any of transactions to Bitcoin network.
More hashrate = more success chance.
More hashrate = more electric cost = less profit per each participator
If mining pool cannot solve the puzzle in 10 minutes or so, he has to change the block header and re-start the puzzle solving, so he has wasted his hash power in a race with minimum chance of win. Indeed, there is a minimum hashrate to have a minimum chance to solve the puzzle in next 10 minutes, otherwise it doesn’t make sense to participate in an activity that doesn’t fit the minimum hope.
How much is this minimum hashrate?
How much costs this hashrate?
Note the fact that the maximum extra income is a fixed 2 BTC. Would it be economically cost effective (risk to reward) to dedicate hashrate to mine this block, or it is better to participate in finding the honest next block? The attacker can not use same equipment to participate in both honest and fraudulent activities!
“maybe” the small miner is enough lucky to mine a block full of fraudulent transactions but he has not unlimited time to solve the certain puzzle, since there is another protection that won’t let the miner to mine stealthily a particular UTXO set for unlimited time. It was explained in the appendix “V: Recycling UTXOs” in previous post.
By the way this risk still exists and would be a real threat but not for now. It will be a serious problem when Sabu is enough popular and the Gazin wallet users have reached a certain number that a percentage of fraudulent actors (either, issuers, creditors or miners) can gain by this attack. In this case the scenario has economically beneficial for cheaters.
I do not know exactly this threshold number of users and proper percentage, but I am pretty sure the Sabu users will carry out and implement the BIPxxx “for mark/unmark promised UTXOs”, before they touch that threshold. This BIPxxx will resolve any imaginary attack scenario.
Before reaching that point, some may lose 5$, 10$ or so. But comparing the benefit of system it worth for either issuers or creditors to taking the risks and use Sabu protocol for a widely distributed micro payment system.

* * *
A violation of trust results in more damaging effects with Sabu than with lightning. In lightning, if your channel partner cheats, at worst you as a payment party must simply pay a normal transaction fee. With Sabu, if a creditor cheats, the issuer will likely pay an abnormally large transaction fee. This is the greater risk in Sabu. Some attackers are what’s known as griefers — these are people willing to spend time and money hurting someone else, even if they don’t make a profit from it (other than schadenfreude). It seems clear there is a greater risk of being griefer in Sabu than in lightning.

Here I have to clarify some facts about Sabu transactions format. These are the criteria that every main transaction must meet in order to be recognized as a valid transaction by both creditor and issuer wallet.
The valid transaction criteria:

• The input amount must be at least 40k Satoshi.
• The total amount of outputs to addresses other than the issuer change back address must be equal or less than 20k Satoshi.
• The transaction fee for a Main Transaction must be 10k Satoshi regardless of transaction length or the input(s) or outputs amounts. 6k of this fee always paid by issuer and the remind 4k Satoshi will be divided between creditor(s) in proportion to their output value.
• Each transaction can have 1 output less than 1,000 Satoshi.
• All the rest outputs (except the issuer change back output) must be higher than 5k Satoshi.

Considering these conditions, each transaction can have maximum 4 outputs for 4 creditors (one without debt-doc and 3 having MT and GT in their hands) and one for issuer change back (if exists).
Going back to the attack scenario, if a creditor cheats and sends the GT to Bitcoin network he will hurt itself in first place. He imposes also high fee payment to other creditor(s) and issuer involved in this particular transaction.
The fraudulent “creditor” will lose 85% of his money and impose the other creditors lose 85% of their money in favor of miner fee. He also imposes the issuer lose 30% of his money in favor of miner fee.
How can we reduce this damage? Simply by changing some criteria.
For example, we can add new criteria that “each transaction has to have only one creditor in output”. So, the griefer will harm only himself, and 30% of issuer money. But in this case the incentives for issuers will be reduced dramatically. He put 40k Satoshi in order to earn 10 Sat per each transaction of a single creditor (instead of 4 potential creditor). Thus, we need to change input amount and maximum liability amount as well. What about using 20k Satoshi as input, and set the maximum liability to 10k Satoshi per transaction and 10k for transaction fee?
By these new conditions, the issuer won’t pay abnormally large transaction fee.
As you can see, it is all about fine tuning the numbers, input amount, outputs counts and outputs total amounts, coefficients and relation between input value and the liability value and Guarantee Transaction details.
I am sharing my idea and thoughts and related mechanisms of Sabu in order to collaborating experts in statistic and mathematician and find the best practices. Hopefully finally we will end up with a robust off-chain micro payment system which everybody uses it with minimum risks.
Here is a primitive script which graphically represents these numbers and relations and the optimum points, etc.…
Interested readers can download it and adjust it to achieve best results and share the results.

The fact is “everything is a trade-off”, and our virtue is to find the best configuration.

* * *
GT propagation delay:
Sabu has a significant likelihood that a cheating transaction could be mined instead of the guarantee transaction. Perhaps the likelihood is approximately 2 seconds / 10 minutes (0.3% chance), but a 0.3% is clearly larger than approximately 0% chance in lightning.

That is true. In this situation Sabu has higher risk, but we should consider pros and cons all together. If the issuer cheats and unluckily the GT goes to next block, the wicked issuer will lose 30% of his money plus 6k Satoshi as Bitcoin transaction fee, on the other hand if he was enough lucky to gain that 0.3% of his chance, will get max 20K Satoshi for each transaction in current criteria setting, but he still has to pay Bitcoin transaction fee for each transaction. The minimum transaction fee would be 5k Sat. Thus, the cheater issuer has 0.3% chance to gain 15k Sat.

On the other hand, the transactions will be:

Main Transaction (40k sats):
* Issuer: 14k sats
* Creditor: 16k sats (the real credit of creditor is 20k)
* Fee: 10k sats (6k from issuer + 4k from creditor)

Guarantee Transaction (40k sats):
* Issuer: 9,800 sats
* Creditor: 2,400 sats
* Fee: 10k + 4,200 from issuer + 13,600 from creditor = 27,800 sats

In case the GT goes to next block, the issuer will lose 6k + 4,200 = 10,200 Sats.
While chances GT goes to next block is 99.7%.

=>

99.7% chances of losing 10,200 Sat are far higher than 0.3% chance of earn 15,000 Sat.

In my opinion the risk to reward ratio is too high, especially if we apply new criteria and reduce the max liability to 10k Satoshi. While if issuer act honestly, he will gain more (or better say lose less).
Again, the BIPxxx will eliminate this small chances as well.

Irrational, malicious, incompetent or griefer actors

To be clear, it should be noted that all the scenarios examined in this section have a very low probability of occurrence. Since, this probability is not zero, thus mustn’t be ignored.
Some of these attacks require a minimum number of system users to succeed or considering as a kind of serious threat.
However, after implementing of BIPxxx, the probability of success of all these attacks will be declined to zero.
By the way in this section, I am going to examine the possible losses of the system from the day of launching to the day of full implementation of the BIPxxx.

The fraudulent issuer
We already knew the issuer attack will end up to economically lost for attacker, but let’s assume attacker actively aimed to ruin the system.
As we knew from “Optimum transaction for a fraudulent issuer” In an optimum attack the issuer will lose (27,801–20,000) Sats = 7,801 Sats
On the other hand, the creditor will lose maximum 20,000 Sats
This is a downside of protocol which cannot stop malevolent issuers from hurting themselves and creditors simultaneously.
These types of attacks to cause serious and fundamental damage to the protocol, must be batch executed which are not easy at all. Look at “Can the attacker (either creditor or issuer) carry out the masse attack”.

The fraudulent creditor
We already knew the creditor attack will end up to economically lost for attacker, but let’s assume attacker actively aimed to ruin the system.
Again, these types of attacks to cause serious and fundamental damage to the protocol, must be batch executed which are not easy at all. Look at “Can the attacker (either creditor or issuer) carry out the masse attack”.

Miner attacks
As we know, a solo miner attack cannot be done. He needs to be an issuer or creditor or both or collaborate with them to be able to attack the protocol. I explained enough details about this kind of attacks on “Conspiracy between a miner (mining pool) and a group of …”.
The key point is; in order for such an attack to be profitable, the miner needs to fill the block space with as many counterfeit transactions as possible. To achieve this volume of transaction, the conspirators need a lot of victims. They need to exercise a group attack which is not easy at all. Look at “Can the attacker (either creditor or issuer) carry out the masse attack”.

Can the attacker (either creditor or issuer) carry out the masse attack?
How can the fraudulent issuer trap creditors?
How can the fraudulent creditor trap issuers?
It looks the mass attack won’t work properly. Sabu has no central point to catch the issuers or creditors information.
The only way for a fraudulent issuer is that the issuer runs a fake exchange, website or so and sell Bitcoin to people, get the fiat money from enough number of people, then cheat them.
Indeed, this scenario does not need Sabu protocol or Gazin wallet! Dozens of such scam projects are observed every day. The only notable case is the misusing of the brand name, which should be considered.
On the other hand, the only way for a fraudulent creditor to find many issuers is to run a website (a business) and accept the Sabu payment in exchange of his services (or goods). So, the attacker gets the transaction from a creditor. This transaction already signed by an issuer. Finally, the attacker sends the Guarantee transaction to Bitcoin network in order to harm itself and the issuer simultaneously.
These are possible mass attacks by issuers or creditors and need more scrutiny. Maybe some statistic experts represent these possibilities by some number or graphs.

GT propagation delay
Based on what we already calculated in “GT propagation delay” for a potential fraudulent issuer there are almost 0.3% chance to earn 15,000 Sat against 99.7% chances to losing 10,200.
This risk to reward ratio is too high, especially if we apply new criteria and reduce the max liability to 10k Satoshi.
Again, we cannot ignore this probability and we have to take it into account in the final cons and pros of the project.

Sabu vs Lightning vs on-chain transaction

Transactions Per Second:
While Bitcoin is strictly limited to 7 TPS or so, the Lightning claims to increase it to millions. I have no idea about all complexities and routing overloads for millions of transactions per second in Lightning. But I am pretty sure about Sabu. It can handle millions of transactions per second, since It has no routing mechanism and no middle actor at all, thus there will be no over-process on all transactions. The issuer communicates with creditor directly (or through a server). There is no bottleneck or single failure point in Sabu architecture. Millions of transactions per second can be sent and received and repeal dynamically without any footprint, because Sabu protocol is designed to motivate people to circulate transactions (AKA debt documents) in Sabu network.

Privacy:
Sabu concentrates on face-to-face or in person deals where people send Bitcoin to each other in exchange of goods or services or cash money with no KYC, which is what Bitcoin promised in early days. It also supports online payments with high level of privacy without revealing the account addresses and transaction amount. Unlike Bitcoin and Lightning, all communications by default are PGP encrypted. As long as transaction are circulated in Sabu protocol, the only people who knew about a transaction are issuer and creditor. This kind of privacy doesn’t exist in on-chain transaction, neither in Lightning where you literally have to record your transaction information on Bitcoin blockchain for on-chain transaction, or at least opening and closing transactions on Bitcoin blockchain for Lightning transactions. While in Sabu none of parties of a transaction are obliged to block money in any kind of smart contract or any other m of n signature accounts on-chain, so it provides more privacy.

Cost & on-chain footprint:
In lightning both parties (sender & receiver) have to open channel and put the fund in a multi-sig account, but in Sabu no one has to replace its fund. Consequently no one has to pay the opening and closing channel transaction fee.

User base:
The Bitcoin network currently has the larger number of users compared to Lightning, and the Sabu network will have more users than both users in the future due to the economic incentives for issuers (each small Bitcoin owner can establish a small bank and earn services fee) and ease of use for creditors (each poor person can enter to crypto world, especially the no-bank people). The solution does not need technical skills or dedicated servers, notable internet bandwidth or even high speed internet. In original design having a mobile and an email address is enough to start as an issuer or creditor or both simultaneously.

Security level:
Definitely on-chain transactions are the most secure Bitcoin transactions; the Lightning transactions seems enough secure since they use the 2 of 2 signature.
The Sabu protocol is not custodial service and the UXTOs are always under issuer’s control. The Sabu protocol is enough secure since it is designed for small payments (a few dollars). The issuer or creditor always can manage their risk and increase/decrease the amount of money involved in debt-documents.
There is still a low probability of self-destructive attacks that will be eliminated if the proposed BIPxxx is implemented.

Stability:
Like Lightning, if one of parties goes offline, the other party can not spend the funds. While in Lightning, there is also the problem of routing and at any moment, the created path between parties may be lost due to the exit of one of the path nodes. In Sabu the communications are directly between creditor and issuer. Over time, issuers become more professional and increase their uptime by dedicating servers to Sabu.

Efficiency:
On-chain transactions are the worst! They force over process (every node has to control every transaction). They waste huge bandwidth of nodes in order to being synchronized and needs terabytes of memory to keep track transactions history. Lightning is less process consuming and more efficient. Sabu is the most efficient system, since each node (either issuer or creditor) receives exactly what it needs and validate exactly what it needs and keep in memory exactly what it needs. No wasting bandwidth, memory or process power at all.

Architecture:
Bitcoin architecture is the best architecture to meet the characteristics of Bitcoin itself.
Lightning architecture is a kind of centralized due to complexity of routing. In long run we will see the limited number of lightning nodes which are mostly custodial, instead of having lots of scattered nodes.
But Sabu is a pure peer-to-peer network. In Sabu the mobile wallets communicating to each other directly without any central server. There is no centralization at all. Nodes can find each other and communicate to each other by just knowing their email address.

conclusion
In these two posts tried to do the best I can and explain all my thoughts about this stage of Sabu development, hoping the serious Bitcoiners join it and help the project to realizing this payment method.
The horizon of Sabu proposal is making a real scalable small payment rail and put it in practice, in order to spread and expand the use of Bitcoin in our day-to-day life.
Sabu brings Bitcoin to a whole new life.
I am actively working on this proposal and need some confirmations about the proposal from Bitcoin community experts.

Tags: Bitcoin, Scalability, Privacy, No KYC, Transaction Fee, Peer-To-Peer Electronic Payment System

Raymo <raymo@riseup.net> d89a49057b817be0