Time to boost Bitcoin circulation (Million Transactions Per Second) and privacy
Sabu, An off-chain small payments protocol, based on Bitcoin UTXOs
by Ray Makan Otas (Raymo)
I am going to introduce a solution for Bitcoin low throughput (TPS) and its week privacy. It solves Bitcoin scaling problem and help its prevalence, particularly in small payments. It also highly increases the privacy level of Bitcoin users. It is a layer two protocol named “Sabu” and works perfectly with current Bitcoin core protocol. Sabu protocol is fully decentralized although it does not implemented based on blockchain or side-chains or any kind of DLT. In order to use Sabu protocol users only need to download the mobile wallet app (Gazin) and install it. No need to pay Bitcoin transaction fee, no need to open/close channels, no need to record transaction in Bitcoin blockchain, no need to run any server, no need to deposit or block money or Bitcoin in smart contract or stacking or any other third parties interference, even no need to have technical skills. And the last but not least no KYC at all.
How Bitcoin transaction works?
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. So 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, “Everyone” will be aware of the new owner(s) of that particular spent coins.
How Sabu protocol works?
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. As long as this document is not registered in the Bitcoin blockchain, it is nothing more than a debt-document. 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 transaction. Thus s/he has a copy of this transaction in her/his wallet. The creditor can send this transaction to Bitcoin blockchain network aimed to record this money transformation in Bitcoin blockchain, or keep this transaction in wallet. The creditor always can broadcast this transaction to Bitcoin network, but due to the high transaction fee on the Bitcoin blockchain and the insignificance of the amount transferred (a few Dollars), the creditor will not send the document to the Bitcoin network, instead s/he prefers to use this document as a payment method and exchange these documents in Sabu protocol and in an off-chain manner.
In this exchange process, you as the issuer will be informed of this credit transformation between two Sabu users and you have to issue a new document in which you owe the new creditor(s).
Sabu protocol is an off-chain protocol in which the UTXO owners (issuers) can issue debt documents and give them to creditors in exchange for fiat money or goods or services. The creditors can spend these documents and give them to other creditors or other issuers in exchange of money, goods, or services.
The issuers earn small Sabu-transaction-fee per each money transfer (10 Sat per transaction). Millions of issuers and creditors can exchanging these documents (transactions) in a pure peer-to-peer network continually, with no central authority. There is no blockchain nor public ledger. Users do not need to open/close channel or pay Bitcoin transaction fee neither routing fee at all.
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 protocol protect issuers against wicked creditors and vice versa?
I’ll explain all cheating cases and proper solutions later in this paper, but for now I just want to explain the core idea of cheating prevention mechanism. The main concept is issuers always have to issue two different copy of any transaction. The “main transaction” (MT), and the “guarantee transaction” (GT). While either issuer or creditor can send the MT to Bitcoin network, the creditors have GT as a kind of guarantee.
In any case in which the issuer spends the promised coins(the used UTXOs in particular transaction) in a counter-promising manner, the creditor will send the GT to Bitcoin network. So the miner will face two different transaction which are using same UTXOs as input. Which one the miner will chose is up to the transaction fee. That is the point of Sabu protocol. The Guarantee transaction (GT) has a far higher transaction fee comparing the Main transaction. Indeed the GT cuts a portion of issuers and creditors money and dedicates it to miner transaction fee. So in 99 % of times miners will put the GT transaction in next block instead of MT. If a creditor send the GT to Bitcoin network he will lose a portion of his money as well as issuer, but this lost is less than what he lose if issuer cheat him.
There are precise and delicate formulas for calculating the amount of loss of the issuer and the creditor, which ensures that just and true act in both parties are cost-effective in all situations. Thus no fraud can be happen in order to benefit one of the parties.
As a result million of people communicate each other and transfer money(Bitcoin) in a real peer-to-peer system. The coins are safe and secure and none of users really need to record this money ownership on Bitcoin blockchain at all. Only issuer and its creditors know from/to who and how much money are transferred. There are million anonymous issuers and creditors without any KYC, central bottleneck or any DLT. The highest level of privacy.
Going into deep understanding of Sabu protocol
Starting a deal
To initiate all deals and money transfers we need a Bitcoin owner(issuer) download the Gazin wallet, install it on his mobile and transfer some Bitcoin from a Bitcoin wallet or an exchange to his Gazin wallet address. Now the Gazin has some UTXOs under its control. The wallet now can issue debt-documents. The debt-document simply is a valid Bitcoin transaction plus some complementary information. Generally this debt-document is intended to circulate in Sabu network, instead of sending to Bitcoin network, but users can send it to Bitcoin network as well.
Now the issuer can accept fiat money, goods or services from people, and in exchange he can send debt-document to their wallet through their email address. In this debt-document there are some outputs for the creditor. So issuer owes creditor. On the other hand, people download and install the Gazin wallet on their mobile and set a dedicated email address on wallet. So they are ready to receive Bitcoin.
Users install the Wallet and configure a dedicated email address. It is all they need. They add other people simply by adding their wallet email address and send and receive Bitcoin. The Gazin wallet does all behind the scenes. The creditors can deal together as well. They can transfer their credit in exchange fiat money, goods or services.
Lets take a look at an example of money transfer.
For example, The creditor 1 (C1) pays some dollars to issuer 1(I1) and the issuer in exchange delivers him a signed transaction in which there is an output for C1 wallet address equal to say 5000 Satoshi. All parties have a copy of this transaction (AKA dept-document) in their wallet.
Once C1 goes to C2 and buy something worth 1000 Satoshi and asks I1 to update transaction. Thus I1 issues a new document in which there are two outputs for C1(4000 sat) and C2(1000sat). Now all C1, C2 and I1 have a same copy of new document. C1 paid to C2 successfully. Everyone can send this document(transaction) to Bitcoin network in order to record this money transferring on Bitcoin blockchain or just keep it in his wallet for future deals.
How can prevent the issuer from not spend UTXO in a cheating way?
In other words, the issuer already issued a debt document and delivered it to creditors, but what prevents him to spend the same UTXO and transfer it to himself before creditors?
To resolve this issue the Sabu protocol obliges the issuer to issue a guarantee transaction(GT) alongside the main transaction(MT).
While the main transaction contains the exact and just balance of issuer and creditors, the guarantee transaction uses the same UTXO(s) and cuts a portion of both issuer and creditors outputs in favor of Bitcoin-transaction-fee. The creditors have guarantee transaction in their hand. If the issuer broadcast a cheating transaction to Bitcoin network, the creditors will be aware of this in few seconds and they broadcast this guarantee transaction to Bitcoin network as well. Because of high Bitcoin transaction fee, this guarantee transaction will take place in next block, even if other transaction which are using the same UTXO as input existed in mempool. If the issuer wants to incentivize miners to put his cheating transaction in next block, he must pay even more transaction fee, comparing the honest main transaction(MT) or Guarantee transaction(GT). So in any cases cheating is not economically profitable for issuer.
In figure 1, carefully in the details of transaction GT, we realize that according to the amount of coefficients “kI” and “kC”, we can adjust the issuer loss, creditors losses and the amount of Bitcoin-transaction-fee in guarantee transactions. The kI=70% and kC=15%. Also the wallet in creditor side always controls if the sum of all creditors outputs value is less than 20,000 Satoshi? It is important that spend UTXO worth at least 40,000 Satoshi.
These numbers (20,000 and 40,000) are important numbers. Controlling them avoids conspiracy between issuers and mining pools. It also makes no counterfeiting cost-effective for the issuer or creditors.
I’ll go in detail and mathematical formula later, but for now we can relay on the calculation outcome which is: the issuer must not be able to create a transaction in which s/he is promise more than 20K Satoshi to all creditors, otherwise the creditors will consider it as an invalid document(transaction) so they can refuse the deal or just send the previous guarantee transaction (if already existed) to Bitcoin network. And the the spent UTXO must worth atleast 40K Satoshi.
The other doubt is, how can prevent issuer from not issuing many valid debt documents (transaction) using the same UTXO?
In other words, the issuer can create a valid (output value less than half of input value) transaction for a group of creditors(group A) and deliver it to them, meanwhile he can use the same UTXO and creates another valid transaction in favor of group B of creditors, and C, D… So he can receive money, goods or services much more than the value of his spent UTXO, since different groups of creditors have been delivered different valid transactions, but they aren’t aware of the others.
To address this issue, the Sabu protocol uses a peer-to-peer network of clients that mirror entire records of the used UTXOs and correlated creditors, considering all privacy issues. These clients are called “doc-watcher” (figure 2. The network architecture) and work like torrent clients. No central server and no head. The doc-watcher traffic bandwidth is very efficient (only UTXO and a proper Merkle Root Hash).
So the serious creditors(such as physical shops or online shops) which receive notably debt-documents daily, can run this doc-watcher clients in order to protect their wealth on off-chain network. and, while the other small creditors will use this doc-watcher services as well. Every creditors can transfer enough large amount of credits to Bitcoin network if they prefer as well as spend it in a batch transaction in Sabu network.
The Sabu network architecture in detail
As you can see in the network architecture, Sabu network is formed by mixing two different peer-to-peer networks and three classic client-server connections. The heart of network are mobile phones which acting as network nodes. Users by installing Gazin wallet will join to Sabu network. The wallets communicate each other in a peer-to-peer decentralized network via emails. The wallets send and receive PGP encrypted emails and manage the money remittance process. So there is no central website or entity. The wallet owners directly communicate together. Users create and dedicate an (preferably anonymous) email address to their wallet and use that email to send and receive Bitcoin. The wallet uses this email and behind the scene reads & parses received emails and generates and sends proper emails.
The wallet in creditors side, needs to read Bitcoin blockchain info, in order to control the existence of a certain UTXO and validate the issuer signature. So the wallet communicate with Bitcoin full-nodes via APIs (probably through the Electrum community powered full-nodes).
Additionally the wallet in creditor side needs to be assure that the issuer issued only one document which spends that particular UTXO(s), so the wallet communicate to doc-watcher clients in a peer-to-peer network. The doc-watcher clients are running by different businesses and/or privates.
The wallets (in both side for issuers and creditors) also need ability to broadcast a Bitcoin transaction to Bitcoin network. In order to achieve this capacity the wallet can connect to a full-node (which relaying the transaction towards mining pools) or the wallet connect directly to one or more mining pools through API.
And finally the wallet in creditors side must be aware if the issuer broadcasted the cheating transactions. So the wallets must have access to mining pools in order to be able monitor the waited transactions (mempools) and publish the guarantee transaction if they found the suspicious activity from issuer.
All these connections and communications are managed dynamically by wallet and it update itself automatically and behind the scenes, so user must not be worry about all these complexities.
User sees a list of email addresses as his friends and send & receive Bitcoin with them. User can easily add new people to his circle just by adding new email addresses.
Details on cheating scenarios and calculations
The Sabu protocol has to defend creditors against fraudulent issuers and vice versa. If issuer wants to spend the same UTXO which already spent in debt-document(MT) and its paired guarantee document(GT), he has to pay high Bitcoin transaction fee to convince miners to put his cheating transaction(ICT) in next block instead the main honest transaction(MT) or even guarantee transaction(GT).
The cheater issuer must gain more money by sending cheating transaction(ICT) comparing honest main transaction(MT).
So looking figure 1 (introducing transactions) for the sake of simplicity I denied the Sabu transaction cost. This cost is 10 Satoshi per transaction per creditor, and regardless of the transaction value. Going back to figure 1 you see the green main transaction. It is a typical transaction. You can see the transaction spend I amount of Satoshi and as outputs you see the issuer pays C amount of Satoshi to creditor(s). The Bitcoin transaction fee is feeBTC and the rest is the issuer’s change back. It is “I-C-feeBTC”.
The issuer also has to create a Guarantee transaction alongside the main transaction. You can see it in details in figure 1 the purple color transaction. The kI and kC coefficients are between zero and one so the outputs for creditor(s) and issuer are smaller than outputs in MT. Instead the feeBTC in GT is much much higher than MT. That means in most cases the miners will chose this transaction to put in next block. If wicked issuer wants to encourage miner to put his greedy transaction in next block, the issuer has to pay even more Bitcoin transaction fee comparing the GT to compete with GT. In this case the issuer benefits drop drastically.
Lets check it out in formulas.
Looking in details of GT we will find the Bitcoin transaction fee equal to
(feeBTC of MT) + (1 - kC)*C + (1 - kI) * (I- C - feeBTC)
and after replacing the (feeBTC of MT) with its proper value will be
feeBTC + (1 - kC)*C + (1 - kI) * (I - C - feeBTC)
and we knew the issuer must pay more transaction fee to compete with GT, so the final BTC fee will be:
feeBTC + (1 - kC)*C + (1 - kI) * (I - C - feeBTC) + Delta
this is what the ceater issuer has to pay to miner so the issuer change back will be
I - (feeBTC + (1 - kC)*C + (1 - kI) * (I - C - feeBTC) + Delta)
and this value must be greater than honest main transaction change back of issuer so this equation must be true.
I- (feeBTC + (1-kC)*C + (1 - kI) * (I - C - feeBTC) + Delta) > I-C-feeBTC
then after simplifications we will have this conditions:
The minimum transaction input must be 40,000 Sat and despite the input amount the total amount of debt to creditors must be less than 20,0000 Sat. In this case cheating won’t be profitable for issuers. The wallet in creditors side can easily control this condition before accepting the deal. Look at the sabu_tx_security_check.py file on project Github page for calculation details.
On the other hand the Sabu protocol has to support issuers from wicked creditors that wish hurt issuers even by hurting themselves. Therefore not all creditors are qualified to have a copy of guarantee transaction(GT) or even main transaction(MT). It depends on the creditor’s credit amount in a certain transaction. For example, if in a MT transaction a creditor output amount is more than 5k Satoshi (almost 2.5 dollar), this particular creditor has to have a copy of both signed MT and signed GT by the issuer as a guarantee of the deal. On the other hand if one or more creditors of a transaction have a very small amount of credit (less than 5k Satoshi almost to 2.5$), they are not allowed to have neither MT nor GT, since s/he can send the transaction to Bitcoin network and hurt the issuer by paying the transaction fee and losing 30 % of his input UTXO.
So now we need to find another protective solution to protect small creditors against wicked issuers, since these small creditors have nothing in their hand. In order to solve this issue, the wallet in creditor side always controls the transaction.
Each transaction can contain some outputs less than 1000 Satoshi but the sum of these outputs must be less than 1000 Satoshi. And also transaction can not contain outputs between 1000 and 5000 Sat. Remained outputs has to be greater than 5000 Sat. By this arrangement, the issuer won’t cheat small creditors since it is not cost efficient. Later we’ll come back to this part and formulas in more details.
What if issuer is miner as well?
Imagine an issuer (or a group of issuers) in a conspiracy with a mining pool, decided to spend all promised UTXOs in a cheating way. They will create the cheating transactions and absolutely won’t broadcast these transactions to Bitcoin network and will try to put all these transactions in a block and mine that block. So after solving puzzle they broadcast this block to Bitcoin network. Everything is fine and before creditors be aware of this UTXO spending the new block will be approved by other miners. The miners/issuers will fill the entire block with cheating transactions to maximize their gains. Each block in average will contain 6,000 transaction. Each transaction in best case will gain 20,000 Satoshi, so the block cheating income will be 1.2 Bitcoin plus block reward in time.
First of all, how much chance in finding next block the corrupted miners have? One percent of all Bitcoin hash powers? Or maximum 5 percent or 10? The cheaters must come up in dividing that 1.2 Bitcoin between. After all the risk/reward must fit them. They can not be a big mining pool since there is no benefit, so they will be small miners with low hash rate. If they solve the puzzle and broadcast the block, no one in the entire Bitcoin network has block transactions or seen it before in their mempool! Will they accept this block? In theory it is possible and have 0.01 percent chance but we can eliminate this small possibilities by a simple BIP for miners. We suppose the miners always control transactions with doc-watchers and avoid accepting transaction with same UTXO but different output.
More details about different operations
Accept credit document or increase the credit
If a creditor (C1) can not trust an issuer (I1), they can start by the smallest amount of Bitcoin that C1 can take its risk. For example C1 wants to buy 100$ in Bitcoin (200k Satoshi for 50K Bitcoin price). C1 can risk on 10$. so he send 10$(almost 20k Satoshi) to I1 alongside his Bech32 address. I1 issues a transaction in which there is one output to C1 address and 10$ value (almost 20k Satoshi). I1 also issue the GT for C1. C1 after receiving both MT and GT documents sends another 20k Satoshi to I1 alongside the NMT. The I1 will send another two GT to C1 to cover 40k Satoshi credit for C1 (two Gt each for 20K). C1 sends back NGT to I1. I1 sends two MT with overall 40k output for C1.
They repeat these steps to reach 200k Satoshi credit of C1.
All these steps take place behind the scene. It is creditor option to set minimum risk amount. He can also send entire money in one shot in exchange of MT & GT from issuer.
Note: These NMT & NGT are necessary in “every” increasing, decreasing or transferring or withdraw credits.
Decreasing credit:
It is a process by which the creditor decrease his credit near an issuer. It happens when a creditor wants to sell his Bitcoins to an issuer and get fiat money in exchange or he wants to send his credits to Bitcoin network. The process is a loop of decreasing credits and updating documents by a risk-able amount of Bitcoin until reaching the desired balance. This process is intended to address missing trust shortcoming in Sabu protocol.
For example in figure 8 (decreasing credit) the creditor5 has 15,000 Satoshi credit near issuer4. Since the Maximum Credit Acceptable by Creditor5 for issuer4 Without Guarantee (MCACIWG) is 5,000 Sat, the creditor5 will neutralizer 5,000 Sat of his credit in each round and ask issuer4 for update in documents (Round 1.1). In response the issuer4 creates 3 documents and deliver them to creditor5. Two of these documents are MT and GT in which the creditor5 outputs are decreased. In addition the issuer creates a Bitcoin transaction by which the creditor own a 10,000 Sat credit. The creditor and issuer doing these rounds until the credit amount in Bitcoin transaction reach the desired amount.
Aggregate transactions:
In some cases a creditor prefers to aggregate different debp-doc from different issuers to a certain issuer. In this case he needs to transfer some of his credits to the selected issuer and in exchange of receive new credits from issuer. Looking at figure 6, you will find the creditor 5 has 3 debt-doc(transaction) in his wallet. MT1, MT4 and MT5.
It is also depicted that the issuer 4 is the most trustworthy issuer for the creditor. The creditor accepts up to 10,000 Satoshi debt of issuer 4 without Guarantee transaction. So probably the issuer 4 is the best issuer to integrate all creditors transactions. Looking figure 6.1 the creditor 5 will contact issuer 4 and ask him does he have enough Bitcoin to integrate all 35k Satoshi of creditor 5? issuer 4 will answer yes alongside his address, then creditor will contact issuer 1 and issuer 3 and ask them to transfer his credit to issuer 4 address. The outcome will be a new debt-document in issuer 4 hands that denotes issuer 4 has some credits beside issuer 1 and issuer 3. The issuer 4 also updates the MT4 transaction and add 2 new outputs for creditor 5. Now creditor 5 has 31,000 Satoshi credit aggregated in issuer 4. The creditor can keep this credit beside issuer 4 or he can send it to Bitcoin network directly or ask issuer 4 to send it to Bitcoin network.
Withdraw in BTC:
It is a procedure by which the creditor aggregates some of or all of its debt-documents and transfers the credit amounts to Bitcoin network in order to record this credit as a UTXO on Bitcoin blockchain. But before this step, the creditor needs to aggregate its dept-docs from different issuers near one issuer. See the “aggregate transactions” for more details.
The creditor can ask issuer to prepare him a customized transaction and send it to Bitcoin network.
First creditor neutralize the latest main transaction outputs, and send it to issuer. Depends on the trust level between creditor and issuer, the creditor can neutralize all or a part of its output. Read the “decreasing credit” for more detail on this process. Then issuer creates 3 new transactions and sends to creditor. These are 3 transactions.
- The withdrawal transaction which will go to the Bitcoin network.
- The new updated Main Transaction
- The new updated Guarantee transaction
Withdraw in fiat:
Almost same as withdraw in Bitcoin except in each step issuer sends fiat money to creditor.
Sabu transaction fee:
Every transaction in Sabu protocol has a fixed fee. It is 10 Sat and same for all transactions (despite the transaction value and transaction length) and issuers. Later it will be enhanced and can be dynamically and optionally adjusted, depends on issuer interest. This fee goes to the issuer. In some complicated operation such as “aggregate transactions” the creditor may pay for multi transactions. Another place where creditor pay Sabu fee is withdrawing in BTC. In this case in addition to the Bitcoin transaction fee, the creditor have to pay Bitcoin-withdraw-fee, which currently is 1,000 Satoshi. Later this amount could be set dynamically as well. The Bitcoin-withdraw-fee is an economical incentive for issuers to ease exporting Bitcoin from Sabut protocol.
Appendix:
I: minimum cost for spending one UTXO
Each UTXO imposes atleast 200 bytes to transaction length. If we set 5 Sat/Byte, the minimum cost for adding a UTXO to an already existed transaction(in case of free riding for issuer) is 1000 Satoshi. So the mimimum value by which the small creditor can trust the issuer is 1000 Sat(0.5 $). Because of this cost, for a bad issuer won’t be ecconomical benefit spending that UTXO to cheat small creditors.
II: micro connections between issuers and creditors
In order to depicting debt-documents and connections between users we need to consider a main transaction in detail (figure 3.).
As you can see all transactions in Sabu protocol has to has at least 40,000 Satoshi as input. It is because of security issue. So in transaction MT1 we have a UTXO as input (inputA) owned by issuer 1(I1) and under his wallet control.
These are the controls about a main transaction which every creditors done in creditor wallet(Gazin) before accept the deal.
If sum of creditors outputs is less than 20K Satoshi?
Outputs sum = (500 + 499 + 5,000 + 6,500 + 7,300) = 19,799 < 20,000If sum of small credits is less than 1,000 Satoshi?
500 + 499 < 1,000
Here you can find more details of tipic issuers and creditors relations.
As you can see in this figure the issuer 1 has issued 2 debt-documents(transactions) MT1 & MT3. Both transactions have same input value 40,000 Satoshi from two different addresses InputA & InputC.
In each transaction there are different outputs for different creditors. For example MT1 has 500 Sat ouput for creditor 1 and also MT3 has another 999 Sat output for creditor 1. So the Issuer 1 has debt to creditor 1 equal to 1,499 Sat. Since this number is much less than 5,000 Sat the creditor 1 has no right to have MT or GT documents in his hands. He has to trust issuer 1. Thus in worth case he will lose 1,499 Sat (less than 1$) which will not happend because it is not convenience for issuer to cheat it.
The issuer 1 also is in debt to creditor 2 for 499 Satoshi. The creditor 2 has other credits as well, 5,300 Sat from issuer 3 and 6,000 Sat from issuer 2 and 5,000 Sat from issuer 4. In sum the creditor 2 has 4 debt-document(transaction) in his hands equal to 16,799 Satoshi and so on.
Each creditor wallet keeps a bunch of paired transactions(NT and GT) in mobile memory to prove its credit or spend it.
As you can see it is an N to N relation. Each issuer can owed to many creditors and each creditor can have credit from many issuers.
III: Creditor1 pays to creditor 2
looking figure 7, the creditor 1 has 20,000 Sat credit near issuer. He wants to pay 8,000 Satoshi of his credit to creditor 2. So as step 1 the creditor 2 expose necessary information to creditor 1. In second step the creditor 1 sends signed remittance request and proper data to issuer. And finally issuer sends proper updated dept-docs to both creditors.
IV: Main transaction Bitcoin fee details
The Bitcoin transaction fee is fixed number 10,000 Sat regardless of transaction value or length. The issuer always pay 4,000 Sat of this cost. The remained 6,000 Sat will be divided by all creditors in proportion of their output value. Who has more credit pays more fee. Looking figure 3 MT1.1 the Bitcoin transaction fee is 10,000. The creditors are paying 1/5 of their output worth as BTC fee.
V: Recycling UTXOs
In order to reduce the risk of fraud, the issuer regularly uses the UTXOs (that used in MT and GT transactions) and creates new UTXOs. So the already existed debt-docs will be invalid for all. That is, the issuer changes the UTXO set. Depends on the transaction numbers — for example every 500 transactions — or depends on life time — for example every 6 hours — the issuer uses a new UTXO set to create debt-docs, and transfers all previously used UTXOs to new addresses.
It is an automatic process that wallet does regularley.
In order to reduce Bitcoin transaction fee, and increasing the privacy, the issuers can communicate together and pre-sign this UTXO-recycler transaction and finally send it to Bitcoin network a big bach transaction file.
Some coefficients:
Maximum Credit Acceptable by Creditor from a certain Issuer Without Guarantee: MCACIWG = 5,000 Satoshi
The MCACIWG can be set by creditor. That is, the creditor decide about this number for every issuer. He can trust a creditor 5,000 Sat(almost 2.5$) or 200 million Sat (almost 100,000$).
Conclusion:
Bitcoin is a great technology and supported by great mindset. Nevertheless its TPS limitation and transparency are some important shortcoming.
Here I supposed a practical solution to address these drawbacks. There are enough economical and philosophical incentives for people to install wallet and enjoy of Bitcoin new privacy and cheep money transfer features.
Issuers can act like small banks and earn steady income by transaction fees, meanwhile creditors can transfer Bitcoin with very small fees.
Sabu needs experts consultations and helps in order to realize it. The Gazin mobile wallet is under heavy development and needs experts helps as well.
Here is the project Github page: https://github.com/raymaot
Tags: Bitcoin, Scalability, Privacy, No KYC, Transaction Fee, Peer-To-Peer Electronic Payment System
Raymo <raymo@riseup.net> d89a49057b817be0
