From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6D5C3C000E for ; Thu, 1 Jul 2021 20:49:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 4EAE560A51 for ; Thu, 1 Jul 2021 20:49:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKYacMpou9LR for ; Thu, 1 Jul 2021 20:49:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) by smtp3.osuosl.org (Postfix) with ESMTPS id E42B86064E for ; Thu, 1 Jul 2021 20:49:29 +0000 (UTC) Received: by mail-pg1-x531.google.com with SMTP id e20so7370043pgg.0 for ; Thu, 01 Jul 2021 13:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8Dm3veKQS6f1WBWhD8tLgDw1r/fbN9YP44HCB8sAM/Y=; b=IFVWfDNRSxRf2cOML2vMze1tkZ/mbeHZoSlUqnXoNFPHZnlv21NL8HpJMnZyQRSJG9 ypopj5D4WHgOM0T5unJf822i2FLkpIfFBLdXdXly2NqHoBOpkOpDPjm/D6ZZvob+kNvs GjHQfRE5qoIdOq/RzcBmW/IKEBwdqjRijv54kC2mKr8wogAKypB+bIcfT/Np46ZYZMKr aQn4BtuHgFvJnvdJyd+l3Y/E/awj35j4MHr5fjUOGNCJ5PbdaTlH3kK5vcAY/SMC4xTD BVyidmapRqSTLeUWZ/lSw0ZrBtJU+9JNBQ5av/qb9fV+f281YGmbPSwu9yjWgvOimuC4 Kcug== 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:content-transfer-encoding; bh=8Dm3veKQS6f1WBWhD8tLgDw1r/fbN9YP44HCB8sAM/Y=; b=AuhqLrQzcAXxJLq+eFE93ZZxvw61mn/6UMg+PBjf1Ec5Fo+P6EPSDlpjZ6b/7bnOH6 zMZ4LLVqofYcvTw02brTUrT6sHho7/62nn9gdUlOaedQ1daRgBlGJF9UvXgVlfNy6T7L uEQ3zlWKNygu2ktECAQWROhZfLuuARKn6OF1+zvmBthcRSAeiUfN1pn7yYsj4djFooCB An2vwJihU6P9mTqbfFNeXmn6ff0dijls43lc56H3ef2RdMgHeofrZmqkFKBQXrGrVjNF UxGY4p/iZnT4dbeSCpdwDzEPZB2czseGy/dNTBcDRUSSDAhSoLNLrjHwPhZqvYGFQh4b gaMw== X-Gm-Message-State: AOAM531HkKIj6eGGLb2kXYeMszjro46LJAF1GKPj+5STfErnTsNeyGl+ opFNQr+uWSCY6tsgBORqxg+ueLjisi8l4nCDrzJFtVM= X-Google-Smtp-Source: ABdhPJxL49Dp/4l4FkEPlCIrHQSjP5itcSPi68b++ulWXrzdtbX7zpZLvzXa5KtsXkftJYf4+ARI5/I1XAYcfWveXUw= X-Received: by 2002:a65:6555:: with SMTP id a21mr1434809pgw.53.1625172569278; Thu, 01 Jul 2021 13:49:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Thu, 1 Jul 2021 16:49:16 -0400 Message-ID: To: raymo@riseup.net, Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 01 Jul 2021 22:22:39 +0000 Cc: Billy Tetrud 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: Thu, 01 Jul 2021 20:49:31 -0000 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 alternativ= es (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 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 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-millio= n-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