From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1A18DC000E for ; Wed, 7 Jul 2021 03:21:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 567C14049F for ; Wed, 7 Jul 2021 03:21:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.888 X-Spam-Level: X-Spam-Status: No, score=-0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, MONEY_FRAUD_5=1.21, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF6PNLrZ1TVt for ; Wed, 7 Jul 2021 03:20:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by smtp2.osuosl.org (Postfix) with ESMTPS id 0D02E401D3 for ; Wed, 7 Jul 2021 03:20:56 +0000 (UTC) Received: by mail-ej1-x631.google.com with SMTP id nd37so970722ejc.3 for ; Tue, 06 Jul 2021 20:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MF+yfL00d3w/2bxpk3qbB78BGo+ufxuVpIzbvWQsHh8=; b=XnIPCMDtm1SqaE1BLk0KAzEKnce2BkZjVTJfW9tMOf4Vuds93ZD8caBF3IQ9oNxjpr jrPxL6AgoO3p/h3UB2pAiLa3a9m9QzDXmZlEzDnNkcl2SwqF94Ltgkbm9bT4cqsL7XsE /0O5WN3Cxsu6wrg9e7ZSjPJCQV65yW0PL13QgTBycHWe+o8/Tr5oCq7tyH7B8YB+FeZ0 Jh509UWhNqdsVGNl4HS7QJwjTFCIj109TU0Zi+aFkqCTVmvcZ7hp9VpUsLBZ0xIHtYzZ kFwiS4wmXIDtKcRQU0qO9ZrvXaeDOPnPRNInFiICsKnSn37QYtVqwQZBiKALZ6EpG2g7 5NvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MF+yfL00d3w/2bxpk3qbB78BGo+ufxuVpIzbvWQsHh8=; b=QrF4zSwWHSe+uMoQ/o4lrY4ZFzrs1ae9TxiWHSiYsHcmbtJYPw8jsZvh6xueex1ZbN PRmzIqAaqvEalvDtX69jygEm/L0Ogyg46oFedG9cDRoKiCtdmXbstBNzfZsHW/xvnCGg groAnvSyFHDbv7jbvaCWiefZ19amKZTOVOTMsqbCjhaEgRucEV14IbU0/dk5yfXqtwKF Wq1lAfHfzTQfmbrCorJjLFdsOo/n7nFsfCsClxrGbj6jF89IJM1h3pDKfmK7m9O1YQ3q Xg0B60vblOGbrMzdP8MLEMcssierHJs+pdikl4v1AMv564WYUY4maLBY+F4xur87flKJ uobQ== X-Gm-Message-State: AOAM532CyRq8IuhdTdsQShcJ7bvNKaJuTpIjoaaBlAYShW8tnfn4bKnF 7Ig7PmSOIYVfyJeSyRZuK7Pltq8W5+5HYkIS4iM= X-Google-Smtp-Source: ABdhPJx7cKziLa+QVAtkSFTcVJQ8MtQEi7BCaiwDih7/fnAd0939X6nrCAFyYFuQS00QTP4Xd4UxHL0c/ABXJvOA5ec= X-Received: by 2002:a17:907:7708:: with SMTP id kw8mr22278710ejc.111.1625628055057; Tue, 06 Jul 2021 20:20:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Billy Tetrud Date: Tue, 6 Jul 2021 20:20:38 -0700 Message-ID: To: raymo@riseup.net Content-Type: multipart/alternative; boundary="000000000000c2371205c680064a" X-Mailman-Approved-At: Wed, 07 Jul 2021 08:20:40 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 03:21:02 -0000 --000000000000c2371205c680064a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > As far as I know the =E2=80=9Cclaw back=E2=80=9D mechanism doesn=E2=80= =99t exist in Bitcoin system, and probably most Bitcoiners won=E2=80=99t be agree on it. It certainly doesn't. And it would definitely be a hard sell. > It looks the miners still can abuse Sabu, but as I told before the miner or better say the mining pool must be issuer .. or must be creditor .. or collaborate one of them in a conspiracy. Yes. But it certainly incentivizes miners to become 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. Larger miners that mine one block every few days can scam that much more often. Even with $5 credits, that could be an extra $9000 gained in a block. That's pretty substantial when fees are totaling around $45,000 per block. > would be resolved by a slightly upgrade in Bitcoin protocol by applying the BIPxxx =E2=80=9Cfor flagging/unflagging promised UTXOs=E2=80=9D As others have mentioned tho, doing something like that 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. > The new transaction will use same 40,000 UTXO as input and the outputs will be 6,500 Sat for creditor (he pays 2,500 Sat for transaction fee) 4,500 Sat for creditor 2 This is the part I was unable to find/understand quickly enough in the original write up. So for creditor 1 to pay creditor 2, a new main transaction and guarantee transaction are created that credit the appropriate people, right? FYI, the MT and GT acronyms make it harder for me to read/understand, so I'm preferring to write them out. But that helps. Let me write this out in a different (more compact) way: 1. Creditor A $5 -> Issuer 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) Guarantee Transaction (40k sats): * Issuer: 13,300 sats * Creditor A: 1650 sats * Fee: 25,050 sats 3. Creditor A, 6k sats -> Creditor B. Issuer creates and shares transactions: Main Transaction (40k sats): * Issuer: 19k sats * Creditor A: 6,500 sats * Creditor B: 4,500 sats * Fee: 10k sats (4k from creditor, 6k from issuer) Guarantee Transaction (40k sats): * Issuer: 13300 sats * Creditor A: 975 sats * Creditor B: 675 sats * Fee: 25050 sats Is this right? > The miner attack is just a failed plan as I explained before I thought you acknowledged that the miner attack is an issue above. No? >> Sabu has slightly greater risk comparing lightning > It is not true, What I mean is that a violation of trust results in more damaging effects with Sabu than with lightning. In lightning, if your channel partner cheats, at worst you must simply pay a normal transaction fee. With Sabu, if a creditor cheats, you will likely pay an abnormally large transaction fee. This is what I mean by "greater risk". 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 griefed in Sabu than in lightning. Furthermore, while in lightning, if you perform the protocol properly, your funds can never be stolen except in very extreme circumstances (eg widespread long-running network congestion that prevents confirming a revoke transaction). By contrast, 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. Again, this is another part of what I mean by "higher risk". These are both real counterparty risks that you shouldn't simply ignore. It may be true that no rational actor will attempt an attack, however not all actors are rational. People also make mistakes, write buggy software, etc etc. The existence of risk doesn't ruin your idea - every protocol has risks. But identifying the specific risks is the only way to compare the properties against alternatives (like on chain transactions or the lightning network). I think its important to acknowledge these risks in your write up. > I explained before this kind of attacks will not happened never If people use your protocol, some will inevitably use it wrong. Those that use it wrong should be the ones that pay the price for it - but it is a downside of the protocol if the counter party of the person that makes a mistake (or attempts something malicious) is harmed as a result. Again, these kinds of trade offs are ok, but you should not be assuming that attacks like this will never happen. They will happen sometimes. You must assume that. The question is what is the result when an attack is attempted? And how will that affect what kinds of actors will attempt an attack (malicious, profit seeking, honest, stupid, wreckless, incompetent, other types of actors etc etc)? > I didn=E2=80=99t find any case Lightning can compete with Sabu. As I explained above related to risk, there are trade offs. I would like to see in your write up a clear list of these trade offs. The additional risk (as I explained it above) is one trade off. It sounds like there are limits in which a creditor or issuer can safely rely on incentives to prevent attacks. Did you specify what those limits are? The Lightning network also has limits - eg a lightning node can't allow its channel partner to spend 100% of their coins without taking on additional risk of attack. How do those limits compare in Sabu? For example, an issuer couldn't allow any creditor to spend so much of their credited bitcoin that their credit goes below the amount they would receive in any past Guarantee Transaction without taking on the risk that the creditor would post that guarantee transaction and receive coins they shouldn't own anymore. I would love to see a more detailed comparison of Sabu to lightning. If your protocol works out, there are obvious benefits: transactions that could be done with no on-chain footprint. However, even if the protocol works out, there are trade offs and those trade offs should be made very clear. Even if the comparative downsides are small. ~BT Hi Billy > > high-level overview of how all the pieces (How Sabu protocol works). > > how normal transactions happen in their entirety. > Ok, lets re-explain Sabu. 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 know 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=E2= =80=99s > address equal to the money issuer already get paid. > This transaction is a valid transaction which is signed =E2=80=9Conly=E2= =80=9D by > issuer. The outputs of transaction are just and exact balance of the > parties (issuer and creditor). > Lets, imagine the creditor payed 5$ (almost equal to 15,000 Sat) to > 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. > 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=E2=80=99s = money > (11,000 =E2=80=93 1,650 =3D 9,350 Sat) will be added to transaction fee. > In GT also issuer will lose a part of his money. New output for issuer > will be 19,000 * 70% =3D 13,300 and the rest will be added to transaction > fee (19,000 =E2=80=93 13,300 =3D 5,700 Sat) > Thus, the new transaction fee in GT will be 10,000 + 9,350 + 5,700 =3D > 25,050 Sat > 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=E2= =80=99s > 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 =E2=80=9Chow normal transactions happen in their entirety= .=E2=80=9D > Creditor 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 C2). > The new transaction will use same 40,000 UTXO as input and the outputs > will be > 6,500 Sat for creditor (he pays 2,500 Sat for transaction fee) > 4,500 Sat for creditor 2 (he has to pay 1,500 Sat for transaction fee as > well) > 10,000 for Bitcoin-transaction-fee (4,000 by two creditors and 6,000 by > issuer) and > 19,000 change back to issuer account address. > This is the new MT, and as you can see the C1 and C2 have their new > credit in transaction. > You can calculate the new GT as well. > 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. > Although I expected more Bitcoiners to react about Sabu proposal and > comment for or against it, so far, I have not seen any serious criticism > or real threat about protocol. > The miner attack is just a failed plan as I explained before. > > Sabu has slightly greater risk comparing lightning > 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 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 a 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$. And as I explained before this kind of attacks will not > happened never. And as you told Sabu provides cheaper and a larger > number of transactions. > > This would be essentially worse than the lightning network in some ways= , > Disagree! Please explain the scenario exactly. I didn=E2=80=99t find any = case > Lightning can compete with Sabu. > > ledger of accounts and their balances, along with proof that the entity > owns=E2=80=A6 > It is almost what I designed in Sabu. They are doc-watcher servers. They > are a set of records of UTXOs and the proper Merkle root hash of related > transaction in Sabu network. The intention was stopping issuer from > spend and promises same UTXO to different people (that they are not > aware of the existence of the other). So, any individual creditor (or > their software) could verify that total liabilities (in account > balances) are less than the half of the total bitcoins the entity owns. > And if something doesn't match up, they won=E2=80=99t yell, instead they = refuse > the deal in first place, or send the GT to Bitcoin network and hurt the > cheater issuer by slashing his money. it is =E2=80=9CTit-for-tat=E2=80=9D= . > > I think it likely has critical security holes. Perhaps you can fix them= ! > There is no critical security hole. Please refer it by facts, numbers > and proves. > I think I already fixed all critics. > > Billy! I am actively working on this proposal and if no one cannot show > a real problem or security issue in the project, I will start > implementing it. > Just imagine people regularly using Sabu protocol and send/receive > Bitcoin (Satoshi) in billions of small amount transactions every day. > This protocol will outspread Bitcoin and will attract a new crowd of > penny investors to Bitcoin. The people who can afford 20$ or less > monthly to invest on Bitcoin. > Sabu brings Bitcoin to a whole new life. > It will be the true scalable and mass adaption, and I do not know how to > attract more real Bitcoin fans to this proposal! > Guys! Here is the Bitcoin renascence. > Maybe you can help it. > Regards > Raymo On Sat, Jul 3, 2021 at 1:02 AM wrote: > Hi Billy, > > > What if it was possible for the creditor to claw back the funds > As far as I know the =E2=80=9Cclaw back=E2=80=9D mechanism doesn=E2=80=99= t exist in Bitcoin > system, and probably most Bitcoiners won=E2=80=99t be agree on it. > Even if we want to add claw back to Bitcoin in general, and Sabu in > particular, it would add too complexities and uncertainty to Bitcoin. > So, it would be better to not touch that part, instead focusing on > reduce the cheating risk by putting some penalty for both issuers, > creditors and miners. > We already have the penalties for both issuers and creditors. > It looks the miners still can abuse Sabu, but as I told before the miner > or better say the mining pool must be issuer (to be able to sign the > promised UTXO in cheating way) or must be creditor (in order to have a > copy of GT and not lose his money in favor of a stranger miner. Remember > the fact that creditor will lose 70% of their money in favor of Bitcoin > transaction fee in a typical GT) or collaborate one of them in a > conspiracy. Otherwise, there will be no economic benefit in this attack. > > All these 3 cases of the attacks, theoretically could be happened, but > the risk to reward ratio is enough high to hinder potential malevolent > from a practical act. > Even this very small risk of miner attacks (which don=E2=80=99t care the = attack > costs, since he is not interested in economic benefit, but he wants to > ruin Sabu), would be resolved by a slightly upgrade in Bitcoin protocol > by applying the BIPxxx =E2=80=9Cfor flagging/unflagging promised UTXOs=E2= =80=9D. > 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 the BIPxxx. > > Best > > On 2021-07-02 17:57, Billy Tetrud wrote: > > Thanks for the details Raymo. A thought occurred to me. Given the fact > > that miners can abuse this system without penalty, it would be useful > > to be able to fix this. What if it was possible for the creditor to > > claw back the funds even if the cheating transaction was mined instead > > of the guarantee transaction? Let's say there was a way to sign a > > transaction that gives the receiver of that transaction the ability to > > override any other transaction that uses the UTXO? If this were > > possible, the issuer could give the creditor this kind of transaction > > as the guarantee transaction, and in the case a cheat was done, the > > creditor could still use the GT to reallocate that UTXO to themselves. > > > > Now there are issues with this. First of all, it could give anyone the > > ability to double spend. So it would be prudent to limit this in some > > way. The revocation probably should only be valid for up to 6 blocks, > > such that if the transaction has 6 confirmations, it can no longer be > > reallocated (thus preserving the 6 block finality rule). It could also > > be required that the UTXO be marked as opting into this behavior (so > > receivers would know about the possibility it could get revoked). This > > second requirement would require Sabu issuers to make an on-chain > > transaction to set themselves up as an issuer. > > > > Another issue is that this would make it possible for transactions to > > expire. Any claw-back transaction would expire 6 blocks after the > > initial transaction happened. This has been generally avoided in > > bitcoin, but I think the relevant issues are solvable. You can find > > additional discussion of that in this thread [1]. > > > > I would imagine this kind of ability would be pretty controversial, > > but since it can close out the possibility for miners to escape > > punishment, it could make this protocol viable. > > > > On Thu, Jul 1, 2021 at 3:15 PM wrote: > > > >> Hi Erik > >> > >> Please correct me if I misunderstood. > >> > >>> email is fully compromised. > >> > >> 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. > >> 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 server uses end-to-end encryption, the provider company still > >> can > >> read the packets content. > >> In my model the passive listener only can discover who is > >> communicate to > >> whom and 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,=E2=80=A6). > >> If you are worried about the way of exchanging PGP public key, you > >> are > >> right. The most secure way is in-person PGP key exchanging. > >> 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 using 3rd parties services to > >> hide > >> their Bitcoin payment addresses. > >> > >> If I missed some points about =E2=80=9Cfully compromised=E2=80=9D plea= se write > >> it to me. > >> > >>> public keys / addresses are sent > >> As I told before ALL communication in Sabu are PGP encrypted. > >> > >>> other routing data encrypted with public keys > >>> (not sure how data is routed in sabu) > >> > >> Sabu is not responsible for routing at all. It simply sends emails. > >> Indeed the wallets peer-to-peer network in Sabu is pretty straight > >> forward. Each mobile wallet has one email address as its handler and > >> identifier in mobile-wallets-network. Each mobile can send message > >> to > >> another mobile by knowing its email address and the PGP public key. > >> This information can be prepared in first face-to-face contact of > >> mobile > >> owners, or later (something like signing the other=E2=80=99s public ke= y in > >> web > >> of trust) when a creditor wants to spend his money and transfer it > >> to > >> another creditor. The creditor1 send the signed money transfer > >> request > >> alongside the email and public key of creditor2 all in a PGP > >> encrypted > >> message to issuer. > >> > >>> separate the Sabu protocol from the app... allow others to > >> implement > >>> desktop version, or other versions that use other routing systems > >> > >> Indeed, it is my approach too. As I told before users will decide > >> 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. > >> > >>> you can allow direct-entry of a BIP-word-representation > >>> of a public key/address to avoid privacy/central system concerns > >> Agree. Actually, I was thinking about an easy mechanism to share > >> your > >> public key like what you suggested here. > >> But what I consider for a =E2=80=9Ccentral system concerns=E2=80=9D is= the > >> ability of > >> communication without dependency to any company. > >> As an example, what can you do if the twitter bans your account? > >> Nothing! Your content and entire connections will be lost. > >> 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 service > >> provider without losing your connections and your control over it. > >> You just sign your new email address and send it to your friends > >> 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). > >> > >> Best > >> Raymo > >> > >> On 2021-07-01 20:49, Erik Aronesty wrote: > >>> your protocol should always assume the email system is fully > >>> compromised, and only send public information over email: > >>> > >>> - public keys / addresses are sent > >>> - other routing data encrypted with public keys (not sure how data > >> is > >>> routed in sabu) > >>> > >>> your end user should be able to verify public keys / addresses > >>> > >>> - use QR-codes > >>> - phone calls with users reading BIP words out loud > >>> - other in-person information exchange > >>> > >>> separate the Sabu protocol from the app... allow others to > >> implement > >>> desktop version, or other versions that use other routing systems > >>> > >>> - you can allow direct-entry of a BIP-word-representation of a > >> public > >>> key/address to avoid privacy/central system concerns > >>> > >>> On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev > >>> wrote: > >>>> > >>>> Hi Billy, > >>>> Sorry for late reply. Let=E2=80=99s jump in proposal. > >>>> > >>>>> Some more information about the benefits of this approach vs > >> alternatives (mainly lightning) > >>>> The most important different is unlike the lightning, in Sabu no > >> one > >>>> have to open a channel and pay Bitcoin transaction fee, > >> subsequently no > >>>> one has to close channel and pay another Bitcoin transaction fee. > >> It is > >>>> the huge improvement since it drops the overhead cost of > >> transactions. > >>>> So, it will be more convenience to trade under Sabu protocol. > >>>> 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. > >>>> Since Sabu protocol is designed to motivate people to circulate > >>>> transactions (AKA debt documents) in Sabu network, if every actor > >> act > >>>> rationally no one will aware how much money transferred from who > >> to > >>>> whom. > >>>> In case of fraudulent activity by issuer, the creditor will send > >>>> Guarantee Transaction (GT) to Bitcoin network in order to > >> recapture the > >>>> part of his credit. So, in this case the transaction is literally > >>>> recorded on bitcoin blockchain. > >>>> There is only one another reason to recording transaction on > >> Bitcoin > >>>> blockchain. Where one creditor eager to pay Bitcoin transaction > >> fee in > >>>> order to aggregate thousands or even millions different small > >> amount > >>>> debt-documents in a single transaction on Bitcoin blockchain. > >>>> despite these two cases, the rest of transactions all occur in > >> the Sabu > >>>> network (supposed to be over 99%). Thus, no footprint no > >> bottleneck and > >>>> no over process. > >>>> > >>>> Another important power point of Sabu is its pure-peer-to-peer > >> network > >>>> architecture. In Sabu the mobile wallets communicating to each > >> other > >>>> directly without any central server. There is no centralization > >> at all. > >>>> As a result, there will be no routing as well. > >>>> Since only issuer and creditors are aware of the content of > >> transaction > >>>> (who pay how much to whom) it is a huge privacy improvement, > >> which > >>>> doesn=E2=80=99t exist in other layer 2 solutions. > >>>> > >>>> About the usability of Sabu, although the protocol based on the > >>>> collaborating 2 different peer-to-peer network and 3 classic > >>>> server/client networks, but the end user (mobile wallet user) > >> doesn=E2=80=99t > >>>> see any of these complexities. > >>>> The end user simply installs the mobile/desktop wallet and add > >> her/his > >>>> friends to his phonebook by adding their email address or > >> scanning their > >>>> email (and/or PGP public 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. For more details, > >> please > >>>> read my previous answer to Alex Schoof. > >>>> The issuer, by using his UTXOs and selling them to creditors earn > >> money. > >>>> the issuer creates the debt document (transaction) by which > >> promises to > >>>> creditor an amount of satoshi. These debt documents are valid > >> Bitcoin > >>>> transaction. The only difference is these transactions are > >> intended to > >>>> circulate in Sabu protocol instead of sending to Bitcoin > >> blockchain. > >>>> Each transaction is a small money transfer. 40,000 Satoshi as > >> input and > >>>> maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as > >> Bitcoin > >>>> transaction fee. > >>>> The creditors will use these received transactions as money and > >> will pay > >>>> it in exchange of goods or services. For each transaction the > >> creditor > >>>> pays 10 Satoshi as Sabu-transaction-fee to issuer. > >>>> Sabu is not custodial service and the UXTOs are always under > >> issuer > >>>> control, unless issuer or creditor send the signed transaction to > >>>> Bitcoin network. When the transaction was recorded in Bitcoin > >>>> blockchain, the creditor can spend proper UTXO in Bitcoin > >> network. > >>>> Imagine million people use their UTXOs in Sabu, they are issuer > >> and > >>>> issue/update/cancel million transactions per second. All they > >> need is a > >>>> mobile wallet. On the other hand, every one by knowing an issuer > >> can buy > >>>> some Satoshi (whit absolutely no KYC), even 1 Dollar or less, and > >> spend > >>>> it, this time Alice really can buy caffe by Bitcoin ;) > >>>> The Bar can install the mobile wallet and every day receives > >> thousands > >>>> of debt documents (transactions), each worth maximum 20,000 > >> Satoshi in > >>>> exchange of coffee. And every evening aggregates those small > >>>> transactions to one single transaction and send it to Bitcoin > >> network. > >>>> > >>>> > >>>> The security model of Sabu is pretty straight forward. > >>>> Issuer is the owner of UTXO(s) which will be used in > >> transactions. The > >>>> issuer is and will the only person who creates transactions and > >> sign > >>>> them. The transactions are valid transaction which either issuer > >> or > >>>> creditor can send them to Bitcoin network, but they will never > >> send > >>>> these transactions to Bitcoin network, because of the high > >> Bitcoin > >>>> transaction fee for each single transaction. > >>>> Since issuer is the only one who can sign transaction (spend > >> UTXOs), > >>>> there is a risk of issuer cheating. And no one can stop issuer > >> from > >>>> cheating, because these are his UTXOs and he has the proper > >> private > >>>> keys. > >>>> The Sabu solution is Guarantee transaction. It is a valid > >> transaction > >>>> that issuer has to sign it alongside the Main transaction. In GT > >> both > >>>> issuer and creditor cut a part of their output in favor of > >> Bitcoin > >>>> transaction fee. > >>>> We suppose miners always seeking for more profit, thus in a case > >> there > >>>> are 2 or more transaction are spending same UTXO as input, miner > >> will > >>>> choose transaction with highest feeRate. There is no economically > >>>> benefit for issuer to cheat creditors and pay less transaction > >> fee > >>>> simultaneously. So rationally the issuer won=E2=80=99t cheat credito= r. > >>>> It was the simplest explanation of Sabu security model. > >>>> > >>>>> I agree with others that using email is probably not > >> appropriate for a protocol like this. I would highly recommend > >> making your protocol transport-agnostic, allowing users of your > >> protocol to use any transport they want. > >>>> Indeed, the protocol is transparent-agnostic, if I insist of > >> email as a > >>>> user identifier and communicating tool is because of the idea of > >>>> reforming part of internet architecture and make it more > >> decentralized. > >>>> The wallet users can choose classic architecture. In this case > >> mobile > >>>> wallets will connect to a central server and communicate through > >> that > >>>> server (pretty much like all existed mobile wallets). While some > >> users > >>>> decide to use a pure peer-to-peer communication. I knew email has > >> some > >>>> privacy issues but as always it is a tradeoff. 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. > >>>> Let me know the critics about email. Hopefully this would lead us > >> to > >>>> improve email instead of letting it die. I strongly suggest email > >>>> because it is the ONLY neutral, free =E2=80=9Cnonproprietary=E2=80= =9D and > >> open > >>>> protocol/technology for communication in the world that its > >>>> infrastructure is well-established and is accessible all over the > >> glob. > >>>> > >>>> I tried to explain it more, hope was useful. By the way the > >> complete > >>>> explanation is here > >>>> > >> > > > https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-= transactions-per-second-and-privacy-1eef8568d180 > >>>> > >>>> > >>>> > >>>> Regards > >>>> Raymo > >>>> > >>>> > >>>> > >>>> On 2021-06-22 18:20, Billy Tetrud wrote: > >>>>> I would be interested in seeing some more information about the > >>>>> benefits of this approach vs alternatives up front in this > >> write up. > >>>>> Eg how does the security, cost, usability, and privacy compare > >> to the > >>>>> lightning network, which would be the most likely competitor to > >> this > >>>>> idea. It seems clear that there is more counterparty risk here, > >> so it > >>>>> would probably also be very helpful to compare against > >> traditional > >>>>> custodial solutions as well. If you have specific claims on how > >> this > >>>>> system is better than eg lightning in certain contexts, it > >> would be > >>>>> far easier to evaluate the protocol against those claims, and > >> would > >>>>> also be a lot easier for readers to be motivated to read the > >> whole > >>>>> protocol and do a more full analysis. > >>>>> > >>>>> I agree with others that using email is probably not > >> appropriate for a > >>>>> protocol like this. I would highly recommend making your > >> protocol > >>>>> transport-agnostic, allowing users of your protocol to use any > >>>>> transport they want. > >>>>> > >>>>> On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev > >>>>> wrote: > >>>>> > >>>>>> I think you're making a number of assumptions about mining > >> that are > >>>>>> not accurate. > >>>>>> > >>>>>>> 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! > >>>>>> > >>>>>> You're making the assumption that miners won't build on top of > >> a > >>>>>> block > >>>>>> with transactions they have not seen before or transactions > >> that may > >>>>>> contain double spends of unconfirmed inputs, this is not how > >> mining > >>>>>> works, as long as the block passes the consensus rules > >> effectively > >>>>>> all > >>>>>> miners will mine on top of it by default, this behavior is > >>>>>> fundamental > >>>>>> to how mining currently works and is fairly deeply baked into > >> the > >>>>>> current mining infrastructure. > >>>>>> > >>>>>>> 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. > >>>>>> > >>>>>> What would this BIP look like? I don't see how this could work > >> in a > >>>>>> decentralized way as you would need another way of reaching > >>>>>> consensus > >>>>>> on what defines a valid block. Right now the chance is nearly > >> 100 > >>>>>> percent that a miner will mine on top of the latest valid > >> block, > >>>>>> many > >>>>>> pools(most last I checked) will even mine on the next block > >> before > >>>>>> they validate the latest block fully(ie validationless mining) > >> to > >>>>>> reduce their orphan rates. > >>>>>> > >>>>>>> We suppose the miners always control transactions with > >>>>>> doc-watchers and avoid accepting transaction with same UTXO > >> but > >>>>>> different output. > >>>>>> > >>>>>> Miners have different mempool policy/rules for what > >> transactions > >>>>>> they > >>>>>> themselves mine but all miners must mine on the most work > >> chain of > >>>>>> valid blocks otherwise they risk their own blocks being > >> orphaned, > >>>>>> any > >>>>>> miner that does not do this is effectively guaranteed to have > >> their > >>>>>> block orphaned right now. > >>>>>> > >>>>>>> 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. > >>>>>> > >>>>>> When a new transaction is broadcast miners do not immediately > >> start > >>>>>> mining on a block template that includes that transaction, the > >>>>>> template won't even be generated immediately when it enters a > >> miners > >>>>>> mempool in practice, for bandwidth/network efficiency reasons > >> mining > >>>>>> pools batch update the stratum templates/jobs they mine > >> against so > >>>>>> there can be significant latency between the time a > >> transaction is > >>>>>> actually broadcast and hits the miners mempool and the time > >> the > >>>>>> miners > >>>>>> actually switch to mining on top it, these batched updates are > >>>>>> essentially like point in time snapshots of the mempool and > >>>>>> typically > >>>>>> remain valid(as in the pool will accept shares submitted > >> against > >>>>>> that > >>>>>> job as valid) until the bitcoin network finds the next block. > >> I > >>>>>> don't > >>>>>> think these batch updates are done more often than every 30 > >> seconds > >>>>>> typically, while often it is on the order of multiple minutes > >>>>>> depending on the pool. > >>>>>> > >>>>>> Regards, > >>>>>> James > >>>>>> > >>>>>> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev > >>>>>> 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=3D5344020.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 > >>>> _______________________________________________ > >>>> bitcoin-dev mailing list > >>>> bitcoin-dev@lists.linuxfoundation.org > >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > Links: > > ------ > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.= html > --000000000000c2371205c680064a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 As far as I know the =E2=80=9Cclaw back=E2=80=9D mechanism doesn=E2=80=99t = exist in Bitcoin
system, and probably most Bitcoiners won=E2=80=99t be a= gree on it.

It certainly doesn't. And it would defin= itely be a hard sell.

> It looks the miners sti= ll can abuse Sabu, but as I told before the miner
or better say the mi= ning pool must be issuer ..=C2=A0or must be creditor .. or collaborate one = of them in a
conspiracy.

Yes. But it certainly incent= ivizes miners to become creditors and scam people. Even if a small miner wh= o mines one block a year does this, they can mine all Guarantee Transaction= s in their possession. Larger miners that mine one block every few days can= scam that much more often. Even with $5 credits, that could be an extra $9= 000 gained in a block. That's pretty substantial when fees are totaling= around $45,000 per block.=C2=A0

> would be res= olved by a slightly upgrade in Bitcoin protocol by applying the BIPxxx =E2= =80=9Cfor flagging/unflagging promised UTXOs=E2=80=9D

<= div>As others have mentioned tho, doing=C2=A0something like that would be a= t very least quite complex, and at worst impossible to do securely. The who= le 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 tr= uth for consensus. The Sabu network could not be a source of truth either f= or consensus, without some serious innovations (that may not be possible). = It isn't as simple as you seem to be thinking.=C2=A0

>=C2=A0 The new transaction will use same 40,000 UTXO as input and the outputs will= be 6,500 Sat for creditor (he pays 2,500 Sat for transaction fee) 4,500 Sa= t for creditor 2

This is the part I was unable to find/u= nderstand quickly enough in the original write up. So for creditor 1 to pay= creditor 2, a new main transaction and guarantee transaction are created t= hat credit the appropriate people, right? FYI, the MT and GT acronyms=C2=A0= make it harder for me to read/understand, so I'm preferring to write th= em out. But that helps. Let me write this out in a different (more compact)= way:

1. Creditor A $5 -> Issuer=C2=A0

2. Issuer creates and shares transactions:

<= /div>
Main Transaction (40k sats):
* Issuer: 19k sats
* Creditor A: 11k sats
* Fee: 10k sats (4k from creditor, 6k f= rom issuer)

Guarantee Transaction (40k sats):
* Issuer: 13,300 sats
* Creditor A: 1650 sats
* F= ee:=C2=A025,050 sats

3. Creditor A, 6k sats -> = Creditor B. Issuer creates and shares transactions:

Main= Transaction (40k sats):
* Issuer: 19k sats
* Creditor A:=C2= =A0=C2=A06,500=C2=A0sats
* Creditor B:=C2=A0 4,500 sats
*= Fee: 10k sats (4k from creditor, 6k from issuer)

= Guarantee Transaction (40k sats):
* Issuer: 13300 sats
* Cre= ditor A: 975 sats
* Creditor B: 675 sats
* Fee:=C2=A025050 sats

Is this right?=C2=A0

&g= t; The miner attack is just a failed plan as I explained before
<= br>
I thought you acknowledged=C2=A0that the miner attack is an i= ssue above. No?

>> Sabu has slightly greater= risk comparing lightning
> It is not true,=C2=A0

What I mean is that a violation of trust results in more damaging eff= ects with Sabu than with lightning. In lightning, if your channel partner c= heats, at worst you must simply pay a normal transaction fee. With Sabu, if= a creditor cheats, you will likely pay an abnormally large transaction fee= . This is what I mean by "greater risk". Some attackers are what&= #39;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 t= han=C2=A0schadenfreude). It seems clear there is a greater risk of being gr= iefed in Sabu than in lightning.=C2=A0

Furthermore= , while in lightning, if you perform the protocol properly, your funds can = never be stolen except in very extreme=C2=A0circumstances (eg widespread lo= ng-running network congestion that prevents confirming a revoke transaction= ). By contrast, Sabu has a significant likelihood that a cheating transacti= on could be mined instead of the guarantee transaction. Perhaps the likelih= ood is approximately 2 seconds / 10 minutes (0.3% chance), but a 0.3% is cl= early larger than approximately 0% chance in lightning. Again, this is anot= her part of what I mean by "higher risk".
=C2=A0=C2=A0<= /div>
These are both real counterparty risks that you shouldn't sim= ply ignore. It may be true that no rational actor will attempt an attack, h= owever not all actors are rational. People also make mistakes, write buggy = software, etc etc. The existence of risk doesn't ruin your idea - every= protocol has risks. But identifying the specific risks is the only way to = compare the properties against alternatives (like on chain transactions or = the lightning network). I think its=C2=A0important to acknowledge=C2=A0thes= e risks in your write up.=C2=A0

> I = explained before this kind of attacks will not happened never
If people use your protocol, some will inevitably use it wrong.= Those that use it wrong should be the ones that pay the price for it - but= it is a downside of the protocol if the counter party of the person that m= akes a mistake (or attempts something malicious) is harmed as a result. Aga= in, these kinds of trade offs are ok, but you should not be assuming that a= ttacks like this will never happen. They will happen sometimes. You must as= sume that. The question is what is the result when an attack is attempted? = And how will that affect what kinds of actors will attempt an attack (malic= ious, profit seeking, honest, stupid, wreckless, incompetent, other types o= f actors etc etc)?

> I didn=E2=80=99t find any = case Lightning can compete with Sabu.

As I explain= ed above related to=C2=A0risk, there are trade offs. I would like to see in= your write up a clear list of these trade offs. The additional risk (as I = explained it above) is one trade off. It sounds like there are limits in wh= ich a creditor or issuer can safely rely on incentives to prevent attacks. = Did you specify what those limits are? The Lightning network also has limit= s - eg a lightning node can't allow its channel partner to spend 100% o= f their coins without taking on additional risk of attack. How do those lim= its compare in Sabu? For example, an issuer couldn't allow any creditor= to spend so much of their credited bitcoin that their credit goes below th= e amount they would receive in any past Guarantee Transaction without takin= g on the risk that the creditor would post that guarantee transaction and r= eceive coins they shouldn't own anymore. I would love to see a more det= ailed comparison of Sabu to lightning.

If your pro= tocol works out, there are obvious benefits: transactions that could be don= e with no on-chain footprint. However, even if the protocol works out, ther= e are trade offs and those trade offs should be made very clear. Even if th= e comparative downsides are small.

~BT
=

Hi Bi= lly
> high-level overview of how all the pieces (How Sabu protocol wo= rks).
> how nor= mal transactions happen in their entirety.
Ok, lets re-explain Sa= bu. In Sabu protocol we have two type of actors.
The issuers who own Bit= coin (they own UTXOs on Bitcoin blockchain), and
the creditors who will = own Bitcoins (the UTXOs on Bitcoin blockchain),
if the issuer or the cre= ditor sends the prepared transaction to Bitcoin
network. But for know cr= editors have the transaction in their hand.
Before sending this transact= ion 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 UTX= O and as a one of
the outputs of the transaction, there will be an outpu= t for creditor=E2=80=99s
address equal to the money issuer already get p= aid.
This transaction is a valid transaction which is signed =E2=80=9Con= ly=E2=80=9D by
issuer. The outputs of transaction are just and exact bal= ance of the
parties (issuer and creditor).
Lets, imagine the creditor= payed 5$ (almost equal to 15,000 Sat) to
issuer. Thus, issuer will crea= te 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 cre= ditor and 6,000 by
issuer) and
19,000 change back to issuer account a= ddress.
It is our Main Transaction (MT) which is a pretty normal and val= id
transaction.
Alongside the MT, issuer creates and signs a Guarante= e Transaction (GT).
In GT issuer spends same 40,000 Sat UTXO as input, a= nd as outputs
the creditor will get 15% of his 11,000 Sat in Main Transa= ction. Thus
the creditor output will be 1,650 Sat and the rest of credit= or=E2=80=99s money
(11,000 =E2=80=93 1,650 =3D 9,350 Sat) will be added = to transaction fee.
In GT also issuer will lose a part of his money. New= output for issuer
will be 19,000 * 70% =3D 13,300 and the rest will be = added to transaction
fee (19,000 =E2=80=93 13,300 =3D 5,700 Sat)
Thus= , the new transaction fee in GT will be 10,000 + 9,350 + 5,700 =3D
25,05= 0 Sat
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 cas= es,
he will lose a portion of his money in favor of transaction fee (min= er=E2=80=99s
income). So, rationally he will never send transactions to = Bitcoin
network unless he wants consciously hurt himself.
The credito= r always prefers to spend his credit inside the Sabu
protocol. It is =E2= =80=9Chow normal transactions happen in their entirety.=E2=80=9D
Credito= r has equal to 15,000 Sat credit. Say he wants to buy a caffe
worth 6,00= 0 Sat. He has to ask the issuer to nullify previous MT and GT,
and creat= e and sign new transaction and cut 6,000 Sat from his credit
and transfe= r it to a new creditor (say C2).
The new transaction will use same 40,00= 0 UTXO as input and the outputs
will be
6,500 Sat for creditor (he pa= ys 2,500 Sat for transaction fee)
4,500 Sat for creditor 2 (he has to pa= y 1,500 Sat for transaction fee as
well)
10,000 for Bitcoin-transacti= on-fee (4,000 by two creditors and 6,000 by
issuer) and
19,000 change= back to issuer account address.
This is the new MT, and as you can see = the C1 and C2 have their new
credit in transaction.
You can calculate= the new GT as well.
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 sn= apshot of Sabu network, we will see millions of valid
transactions flowi= ng in network and none of the issuers or creditors
will send these trans= actions to Bitcoin network due the transaction fee,
while in Bitcoin blo= ckchain 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.=
Although I expected more Bitcoiners to react about Sabu proposal andcomment for or against it, so far, I have not seen any serious criticismor real threat about protocol.
The miner attack is just a failed plan = as I explained before.
> Sabu has slightly greater risk comparing lig= htning
It is not true, since creditors can manage they risk, and limit t= heir
credit to 5, 10 or 20 Dollar or 50$. It is totally up to creditor t= o
accept more liability from issuers or not.
The creditor can keep hi= s 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 paye= d 5$ to a issuer and you got 15,000 Sat
credit in your wallet. So, you w= ill 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 cos= t you are not obliged to charge your
wallet 200$ in one shot.
It is a= bsolutely low risk deal. In worst case the creditor (you) will
lose 5$. = And as I explained before this kind of attacks will not
happened never. = And as you told Sabu provides cheaper and a larger
number of transaction= s.
> This would be essentiall= y worse than the lightning network in some ways,
Disagree! Please= explain the scenario exactly. I didn=E2=80=99t find any case
Lightning = can compete with Sabu.
> ledger of accounts and their balances, along= with proof that the entity owns=E2=80=A6
It is almost what I designed i= n Sabu. They are doc-watcher servers. They
are a set of records of UTXOs= and the proper Merkle root hash of related
transaction in Sabu network.= The intention was stopping issuer from
spend and promises same UTXO to = different people (that they are not
aware of the existence of the other)= . So, any individual creditor (or
their software) could verify that tota= l liabilities (in account
balances) are less than the half of the total = bitcoins the entity owns.
And if something doesn't match up, they wo= n=E2=80=99t yell, instead they refuse
the deal in first place, or send t= he GT to Bitcoin network and hurt the
cheater issuer by slashing his mon= ey. it is =E2=80=9CTit-for-tat=E2=80=9D.
> I think it likely has critical security holes. Perhaps you ca= n fix them!
There is no critical security hole. Please refer it b= y facts, numbers
and proves.
I think I already fixed all critics.
=
Billy! I am actively working on this proposal and if no one cannot show=
a real problem or security issue in the project, I will start
implem= enting it.
Just imagine people regularly using Sabu protocol and send/re= ceive
Bitcoin (Satoshi) in billions of small amount transactions every d= ay.
This protocol will outspread Bitcoin and will attract a new crowd of=
penny investors to Bitcoin. The people who can afford 20$ or less
mo= nthly to invest on Bitcoin.
Sabu brings Bitcoin to a whole new life.
= It will be the true scalable and mass adaption, and I do not know how toattract more real Bitcoin fans to this proposal!
Guys! Here is the Bitc= oin renascence.
Maybe you can help it.
Regards
Raymo
<= div class=3D"gmail-yj6qo gmail-ajU" style=3D"outline:none;padding:10px 0px;= width:22px;margin:2px 0px 0px">

On Sat, Jul 3, 2021 at 1:02 AM <raymo@riseup.net> wrote:
Hi Billy,

> What if it was possible for the creditor to claw back the funds
As far as I know the =E2=80=9Cclaw back=E2=80=9D mechanism doesn=E2=80=99t = exist in Bitcoin
system, and probably most Bitcoiners won=E2=80=99t be agree on it.
Even if we want to add claw back to Bitcoin in general, and Sabu in
particular, it would add too complexities and uncertainty to Bitcoin.
So, it would be better to not touch that part, instead focusing on
reduce the cheating risk by putting some penalty for both issuers,
creditors and miners.
We already have the penalties for both issuers and creditors.
It looks the miners still can abuse Sabu, but as I told before the miner or better say the mining pool must be issuer (to be able to sign the
promised UTXO in cheating way) or must be creditor (in order to have a
copy of GT and not lose his money in favor of a stranger miner. Remember the fact that creditor will lose 70% of their money in favor of Bitcoin
transaction fee in a typical GT) or collaborate one of them in a
conspiracy. Otherwise, there will be no economic benefit in this attack.
All these 3 cases of the attacks, theoretically could be happened, but
the risk to reward ratio is enough high to hinder potential malevolent
from a practical act.
Even this very small risk of miner attacks (which don=E2=80=99t care the at= tack
costs, since he is not interested in economic benefit, but he wants to
ruin Sabu), would be resolved by a slightly upgrade in Bitcoin protocol
by applying the BIPxxx =E2=80=9Cfor flagging/unflagging promised UTXOs=E2= =80=9D.
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 the BIPxxx.

Best

On 2021-07-02 17:57, Billy Tetrud wrote:
> Thanks for the details Raymo. A thought occurred to me. Given the fact=
> that miners can abuse this system without penalty, it would be useful<= br> > to be able to fix this. What if it was possible for the creditor to > claw back the funds even if the cheating transaction was mined instead=
> of the guarantee transaction? Let's say there was a way to sign a<= br> > transaction that gives the receiver of that transaction the ability to=
> override any other transaction that uses the UTXO? If this were
> possible, the issuer could give the creditor this kind of transaction<= br> > as the guarantee transaction, and in the case a cheat was done, the > creditor could still use the GT to reallocate that UTXO to themselves.=
>
> Now there are issues with this. First of all, it could give anyone the=
> ability to double spend. So it would be prudent to limit this in some<= br> > way. The revocation probably should only be valid for up to 6 blocks,<= br> > such that if the transaction has 6 confirmations, it can no longer be<= br> > reallocated (thus preserving the 6 block finality rule). It could also=
> be required that the UTXO be marked as opting into this behavior (so > receivers would know about the possibility it could get revoked). This=
> second requirement would require Sabu issuers to make an on-chain
> transaction to set themselves up as an issuer.
>
> Another issue is that this would make it possible for transactions to<= br> > expire. Any claw-back transaction would expire 6 blocks after the
> initial transaction happened. This has been generally avoided in
> bitcoin, but I think the relevant issues are solvable. You can find > additional discussion of that in this thread [1].
>
> I would imagine this kind of ability would be pretty controversial, > but since it can close out the possibility for miners to escape
> punishment, it could make this protocol viable.
>
> On Thu, Jul 1, 2021 at 3:15 PM <raymo@riseup.net> wrote:
>
>> Hi Erik
>>
>> Please correct me if I misunderstood.
>>
>>> email is fully compromised.
>>
>> 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.
>> I can claim same argue about any other client/server model. Since<= br> >> the
>> server (website) service provider will ask some sort of KYC. And >> even if
>> the server uses end-to-end encryption, the provider company still<= br> >> can
>> read the packets content.
>> In my model the passive listener only can discover who is
>> communicate to
>> whom and make a graph of connections. Although it is a threat for<= br> >> privacy but the server/client model has this flaw inherently, sinc= e
>> provider already knew everything about everyone. In my model at >> least
>> users can make some fake connections and send some fake emails in<= br> >> 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,=E2=80=A6).
>> If you are worried about the way of exchanging PGP public key, you=
>> are
>> right. The most secure way is in-person PGP key exchanging.
>> 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 using 3rd parties services t= o
>> hide
>> their Bitcoin payment addresses.
>>
>> If I missed some points about =E2=80=9Cfully compromised=E2=80=9D = please write
>> it to me.
>>
>>> public keys / addresses are sent
>> As I told before ALL communication in Sabu are PGP encrypted.
>>
>>> other routing data encrypted with public keys
>>> (not sure how data is routed in sabu)
>>
>> Sabu is not responsible for routing at all. It simply sends emails= .
>> Indeed the wallets peer-to-peer network in Sabu is pretty straight=
>> forward. Each mobile wallet has one email address as its handler a= nd
>> identifier in mobile-wallets-network. Each mobile can send message=
>> to
>> another mobile by knowing its email address and the PGP public key= .
>> This information can be prepared in first face-to-face contact of<= br> >> mobile
>> owners, or later (something like signing the other=E2=80=99s publi= c key in
>> web
>> of trust) when a creditor wants to spend his money and transfer it=
>> to
>> another creditor. The creditor1 send the signed money transfer
>> request
>> alongside the email and public key of creditor2 all in a PGP
>> encrypted
>> message to issuer.
>>
>>> separate the Sabu protocol from the app... allow others to
>> implement
>>> desktop version, or other versions that use other routing syst= ems
>>
>> Indeed, it is my approach too. As I told before users will decide<= br> >> 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 centra= l
>> limited network.
>>
>>> you can allow direct-entry of a BIP-word-representation
>>> of a public key/address to avoid privacy/central system concer= ns
>> Agree. Actually, I was thinking about an easy mechanism to share >> your
>> public key like what you suggested here.
>> But what I consider for a =E2=80=9Ccentral system concerns=E2=80= =9D is the
>> ability of
>> communication without dependency to any company.
>> As an example, what can you do if the twitter bans your account? >> Nothing! Your content and entire connections will be lost.
>> 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<= br> >> (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 ca= n
>> easily change your email and use a new email or even a new service=
>> provider without losing your connections and your control over it.=
>> You just sign your new email address and send it to your friends >> 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).
>>
>> Best
>> Raymo
>>
>> On 2021-07-01 20:49, Erik Aronesty wrote:
>>> your protocol should always assume the email system is fully >>> compromised, and only send public information over email:
>>>
>>> - public keys / addresses are sent
>>> - other routing data encrypted with public keys (not sure how = data
>> is
>>> routed in sabu)
>>>
>>> your end user should be able to verify public keys=C2=A0 / add= resses
>>>
>>> - use QR-codes
>>> - phone calls with users reading BIP words out loud
>>> - other in-person information exchange
>>>
>>> separate the Sabu protocol from the app... allow others to
>> implement
>>> desktop version, or other versions that use other routing syst= ems
>>>
>>> -=C2=A0 you can allow direct-entry of a BIP-word-representatio= n of a
>> public
>>> key/address to avoid privacy/central system concerns
>>>
>>> On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>> Hi Billy,
>>>> Sorry for late reply. Let=E2=80=99s jump in proposal.
>>>>
>>>>> Some more information about the benefits of this appro= ach vs
>> alternatives (mainly lightning)
>>>> The most important different is unlike the lightning, in S= abu no
>> one
>>>> have to open a channel and pay Bitcoin transaction fee, >> subsequently no
>>>> one has to close channel and pay another Bitcoin transacti= on fee.
>> It is
>>>> the huge improvement since it drops the overhead cost of >> transactions.
>>>> So, it will be more convenience to trade under Sabu protoc= ol.
>>>> In Sabu none of parties of a transaction are obliged to bl= ock
>> money in
>>>> any kind of smart contract or any other m of n signature a= ccounts
>>>> on-chain, so it provides more privacy.
>>>> Since Sabu protocol is designed to motivate people to circ= ulate
>>>> transactions (AKA debt documents) in Sabu network, if ever= y actor
>> act
>>>> rationally no one will aware how much money transferred fr= om who
>> to
>>>> whom.
>>>> In case of fraudulent activity by issuer, the creditor wil= l send
>>>> Guarantee Transaction (GT) to Bitcoin network in order to<= br> >> recapture the
>>>> part of his credit. So, in this case the transaction is li= terally
>>>> recorded on bitcoin blockchain.
>>>> There is only one another reason to recording transaction = on
>> Bitcoin
>>>> blockchain. Where one creditor eager to pay Bitcoin transa= ction
>> fee in
>>>> order to aggregate thousands or even millions different sm= all
>> amount
>>>> debt-documents in a single transaction on Bitcoin blockcha= in.
>>>> despite these two cases, the rest of transactions all occu= r in
>> the Sabu
>>>> network (supposed to be over 99%). Thus, no footprint no >> bottleneck and
>>>> no over process.
>>>>
>>>> Another important power point of Sabu is its pure-peer-to-= peer
>> network
>>>> architecture. In Sabu the mobile wallets communicating to = each
>> other
>>>> directly without any central server. There is no centraliz= ation
>> at all.
>>>> As a result, there will be no routing as well.
>>>> Since only issuer and creditors are aware of the content o= f
>> transaction
>>>> (who pay how much to whom) it is a huge privacy improvemen= t,
>> which
>>>> doesn=E2=80=99t exist in other layer 2 solutions.
>>>>
>>>> About the usability of Sabu, although the protocol based o= n the
>>>> collaborating 2 different peer-to-peer network and 3 class= ic
>>>> server/client networks, but the end user (mobile wallet us= er)
>> doesn=E2=80=99t
>>>> see any of these complexities.
>>>> The end user simply installs the mobile/desktop wallet and= add
>> her/his
>>>> friends to his phonebook by adding their email address or<= br> >> scanning their
>>>> email (and/or PGP public key). After that s/he can immedia= tely
>> start to
>>>> send/receive Bitcoin through Sabu network. Entire communic= ations
>> between
>>>> wallets are PGP encrypted.
>>>> Another good point in Sabu design is, the 12 seed words ar= e using
>> for
>>>> both Bitcoin wallet private key and the PGP private key. S= o, it
>> is the
>>>> key of user wealth and its identity as well. For more deta= ils,
>> please
>>>> read my previous answer to Alex Schoof.
>>>> The issuer, by using his UTXOs and selling them to credito= rs earn
>> money.
>>>> the issuer creates the debt document (transaction) by whic= h
>> promises to
>>>> creditor an amount of satoshi. These debt documents are va= lid
>> Bitcoin
>>>> transaction. The only difference is these transactions are=
>> intended to
>>>> circulate in Sabu protocol instead of sending to Bitcoin >> blockchain.
>>>> Each transaction is a small money transfer. 40,000 Satoshi= as
>> input and
>>>> maximum 20,000 Satoshi as credit and minimum 10,000 Satosh= i as
>> Bitcoin
>>>> transaction fee.
>>>> The creditors will use these received transactions as mone= y and
>> will pay
>>>> it in exchange of goods or services. For each transaction = the
>> creditor
>>>> pays 10 Satoshi as Sabu-transaction-fee to issuer.
>>>> Sabu is not custodial service and the UXTOs are always und= er
>> issuer
>>>> control, unless issuer or creditor send the signed transac= tion to
>>>> Bitcoin network. When the transaction was recorded in Bitc= oin
>>>> blockchain, the creditor can spend proper UTXO in Bitcoin<= br> >> network.
>>>> Imagine million people use their UTXOs in Sabu, they are i= ssuer
>> and
>>>> issue/update/cancel million transactions per second. All t= hey
>> need is a
>>>> mobile wallet. On the other hand, every one by knowing an = issuer
>> can buy
>>>> some Satoshi (whit absolutely no KYC), even 1 Dollar or le= ss, and
>> spend
>>>> it, this time Alice really can buy caffe by Bitcoin ;)
>>>> The Bar can install the mobile wallet and every day receiv= es
>> thousands
>>>> of debt documents (transactions), each worth maximum 20,00= 0
>> Satoshi in
>>>> exchange of coffee. And every evening aggregates those sma= ll
>>>> transactions to one single transaction and send it to Bitc= oin
>> network.
>>>>
>>>>
>>>> The security model of Sabu is pretty straight forward.
>>>> Issuer is the owner of UTXO(s) which will be used in
>> transactions. The
>>>> issuer is and will the only person who creates transaction= s and
>> sign
>>>> them. The transactions are valid transaction which either = issuer
>> or
>>>> creditor can send them to Bitcoin network, but they will n= ever
>> send
>>>> these transactions to Bitcoin network, because of the high=
>> Bitcoin
>>>> transaction fee for each single transaction.
>>>> Since issuer is the only one who can sign transaction (spe= nd
>> UTXOs),
>>>> there is a risk of issuer cheating. And no one can stop is= suer
>> from
>>>> cheating, because these are his UTXOs and he has the prope= r
>> private
>>>> keys.
>>>> The Sabu solution is Guarantee transaction. It is a valid<= br> >> transaction
>>>> that issuer has to sign it alongside the Main transaction.= In GT
>> both
>>>> issuer and creditor cut a part of their output in favor of=
>> Bitcoin
>>>> transaction fee.
>>>> We suppose miners always seeking for more profit, thus in = a case
>> there
>>>> are 2 or more transaction are spending same UTXO as input,= miner
>> will
>>>> choose transaction with highest feeRate. There is no econo= mically
>>>> benefit for issuer to cheat creditors and pay less transac= tion
>> fee
>>>> simultaneously. So rationally the issuer won=E2=80=99t che= at creditor.
>>>> It was the simplest explanation of Sabu security model. >>>>
>>>>> I agree with others that using email is probably not >> appropriate for a protocol like this. I would highly recommend
>> making your protocol transport-agnostic, allowing users of your >> protocol to use any transport they want.
>>>> Indeed, the protocol is transparent-agnostic, if I insist = of
>> email as a
>>>> user identifier and communicating tool is because of the i= dea of
>>>> reforming part of internet architecture and make it more >> decentralized.
>>>> The wallet users can choose classic architecture. In this = case
>> mobile
>>>> wallets will connect to a central server and communicate t= hrough
>> that
>>>> server (pretty much like all existed mobile wallets). Whil= e some
>> users
>>>> decide to use a pure peer-to-peer communication. I knew em= ail has
>> some
>>>> privacy issues but as always it is a tradeoff. Users can d= ecide
>> between
>>>> an unstoppable, permission less, self-sovereignty and
>> decentralized pure
>>>> peer-to-peer communication network (with some resolvable p= rivacy
>> issues)
>>>> or some efficient central limited network.
>>>> Let me know the critics about email. Hopefully this would = lead us
>> to
>>>> improve email instead of letting it die. I strongly sugges= t email
>>>> because it is the ONLY neutral, free =E2=80=9Cnonproprieta= ry=E2=80=9D and
>> open
>>>> protocol/technology for communication in the world that it= s
>>>> infrastructure is well-established and is accessible all o= ver the
>> glob.
>>>>
>>>> I tried to explain it more, hope was useful. By the way th= e
>> complete
>>>> explanation is here
>>>>
>>
> https://raymo-49157.medium.com/time-to-boost-bitc= oin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>>>>
>>>>
>>>>
>>>> Regards
>>>> Raymo
>>>>
>>>>
>>>>
>>>> On 2021-06-22 18:20, Billy Tetrud wrote:
>>>>> I would be interested in seeing some more information = about the
>>>>> benefits of this approach vs alternatives up front in = this
>> write up.
>>>>> Eg how does the security, cost, usability, and privacy= compare
>> to the
>>>>> lightning network, which would be the most likely comp= etitor to
>> this
>>>>> idea. It seems clear that there is more counterparty r= isk here,
>> so it
>>>>> would probably also be very helpful to compare against=
>> traditional
>>>>> custodial solutions as well. If you have specific clai= ms on how
>> this
>>>>> system is better than eg lightning in certain contexts= , it
>> would be
>>>>> far easier to evaluate the protocol against those clai= ms, and
>> would
>>>>> also be a lot easier for readers to be motivated to re= ad the
>> whole
>>>>> protocol and do a more full analysis.
>>>>>
>>>>> I agree with others that using email is probably not >> appropriate for a
>>>>> protocol like this. I would highly recommend making yo= ur
>> protocol
>>>>> transport-agnostic, allowing users of your protocol to= use any
>>>>> transport they want.
>>>>>
>>>>> On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bit= coin-dev
>>>>> <bitcoin-dev@lists.linuxfoundation.org> wrot= e:
>>>>>
>>>>>> I think you're making a number of assumptions = about mining
>> that are
>>>>>> not accurate.
>>>>>>
>>>>>>> First of all, how much chance in finding next = block the
>> corrupted
>>>>>> miners have? One percent of all Bitcoin hash power= s? Or
>> maximum 5
>>>>>> percent or 10? The cheaters must come up in dividi= ng that 1.2
>>>>>> Bitcoin between. After all the risk/reward must fi= t 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! >>>>>>
>>>>>> You're making the assumption that miners won&#= 39;t build on top of
>> a
>>>>>> block
>>>>>> with transactions they have not seen before or tra= nsactions
>> that may
>>>>>> contain double spends of unconfirmed inputs, this = is not how
>> mining
>>>>>> works, as long as the block passes the consensus r= ules
>> effectively
>>>>>> all
>>>>>> miners will mine on top of it by default, this beh= avior is
>>>>>> fundamental
>>>>>> to how mining currently works and is fairly deeply= baked into
>> the
>>>>>> current mining infrastructure.
>>>>>>
>>>>>>> Will they accept this block? In theory it is p= ossible and
>> have
>>>>>> 0.01 percent chance but we can eliminate this smal= l
>> possibilities by
>>>>>> a simple BIP for miners.
>>>>>>
>>>>>> What would this BIP look like? I don't see how= this could work
>> in a
>>>>>> decentralized way as you would need another way of= reaching
>>>>>> consensus
>>>>>> on what defines a valid block. Right now the chanc= e is nearly
>> 100
>>>>>> percent that a miner will mine on top of the lates= t valid
>> block,
>>>>>> many
>>>>>> pools(most last I checked) will even mine on the n= ext block
>> before
>>>>>> they validate the latest block fully(ie validation= less mining)
>> to
>>>>>> reduce their orphan rates.
>>>>>>
>>>>>>> We suppose the miners always control transacti= ons with
>>>>>> doc-watchers and avoid accepting transaction with = same UTXO
>> but
>>>>>> different output.
>>>>>>
>>>>>> Miners have different mempool policy/rules for wha= t
>> transactions
>>>>>> they
>>>>>> themselves mine but all miners must mine on the mo= st work
>> chain of
>>>>>> valid blocks otherwise they risk their own blocks = being
>> orphaned,
>>>>>> any
>>>>>> miner that does not do this is effectively guarant= eed to have
>> their
>>>>>> block orphaned right now.
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> When a new transaction is broadcast miners do not = immediately
>> start
>>>>>> mining on a block template that includes that tran= saction, the
>>>>>> template won't even be generated immediately w= hen it enters a
>> miners
>>>>>> mempool in practice, for bandwidth/network efficie= ncy reasons
>> mining
>>>>>> pools batch update the stratum templates/jobs they= mine
>> against so
>>>>>> there can be significant latency between the time = a
>> transaction is
>>>>>> actually broadcast and hits the miners mempool and= the time
>> the
>>>>>> miners
>>>>>> actually switch to mining on top it, these batched= updates are
>>>>>> essentially like point in time snapshots of the me= mpool and
>>>>>> typically
>>>>>> remain valid(as in the pool will accept shares sub= mitted
>> against
>>>>>> that
>>>>>> job as valid) until the bitcoin network finds the = next block.
>> I
>>>>>> don't
>>>>>> think these batch updates are done more often than= every 30
>> seconds
>>>>>> typically, while often it is on the order of multi= ple minutes
>>>>>> depending on the pool.
>>>>>>
>>>>>> Regards,
>>>>>> James
>>>>>>
>>>>>> On Thu, Jun 17, 2021 at 2: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-bitc= oin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>>>>>>> https://bitcointalk.= org/index.php?topic=3D5344020.0
>>>>>>> Can you please read it and share your idea abo= ut 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
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfo= undation.org/mailman/listinfo/bitcoin-dev
>=C2=A0
>
> Links:
> ------
> [1] https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html
--000000000000c2371205c680064a--