Hi Alex, 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 worth 40,000 Sat and issue a debt-document(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 dictates the fiat to BTC exchange rate in first step, and can earn even more benefits by selling BTC a little higher than market price. The target would be penny savers which potentially buy very small amount each time(teenagers or people with low income specially). About your double-spend scenario please write a clear scenario and use the conventional terms such as issuer, creditor, MT, GT, CT etc... to study its feasibility. Maybe there are corner cases which I missed. So we will fix it as well. About p2p Gossiping, you are right. 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 transactions 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) to receiver wallet, already exist on the doc-watcher sites. If that particular document exist in doc-watcher , the wallet consider it as a valid transaction, otherwise creditor won't accept the deal as a settled deal. >I think you will end up reinventing a lot of the problems solved by bitcoin. No, that's not true. Because I proposed 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 at all and all consensus are between small set of users (most of time between an issuer and a creditor). In Sabu there is no obligation for everyone know 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]. These gossip nodes (doc-watchers) are not corruptible since it works in a simple proof-of-existance (true-positive) model. And no one can mutilate it by censor transactions. >Why did you pick email as the RPC mechanism to transfer these notes? First of all I have to explain a part of design spec. Each mobile wallet 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. In my opinion email is the ONLY neutral, free (non proprietary) and open protocol/technology for communication in the world that its infrastructure is well-established and is accessible all over the glob. 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 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. Once the user install the Sabu-supporter-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 take place behind the scene and user only sees its wallet is ready. So these 12 worlds are users wealth protector and identity sovereignty as well. User adds friends 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 Cypher punk 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-respector-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 issues. 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. Later we will see the wallet users will choose which solution. Speed vs privacy, sovereignty and independence. Regards Raymo On 2021-06-18 13:44, Alex Schoof wrote: > A few questions/comments: > > Why is there a 10 sat fee on each tx? Where does that fee go? > > I don’t think this design sufficiently protects against double > spends by the “issuer” (the person who actually has the UTXO). > Your guarantee tx mechanism only really covers the case where someone > tries to double spend part of a UTXO balance (in other words, if the > penalty lost is less than the value gained by doing a double spend, > its worth it to double spend, and in a world where you’re passing > around digital IOUs, it’s easy to make it worth it). Later in the > post, 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. > I think you will end up reinventing a lot of the problems solved by > bitcoin. > > Why did you pick email as the RPC mechanism to transfer these notes? > Email is going to add variable amounts of latency and things like spam > filters will cause issues. > > Alex > > On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > >> for very small transactions, this seems to make a hell of a lot of >> sense. >> >> it's like lightning, but with no limits, no routing protocols... >> everything is guaranteed by relative fees and the cost-of-theft. >> >> pretty cool. >> >> On Thu, Jun 17, 2021 at 4:14 PM raymo via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> Hi, >>> I have a proposal for improve Bitcoin TPS and privacy, here is the >> post. >>> >> > https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180 >>> https://bitcointalk.org/index.php?topic=5344020.0 >>> Can you please read it and share your idea about it. >>> >>> Cheers >>> Raymo >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- > > Alex Schoof _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev