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 2D5ECC000E for ; Thu, 1 Jul 2021 20:11:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 06FE840583 for ; Thu, 1 Jul 2021 20:11:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net 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 B0kSl4u2-ZKM for ; Thu, 1 Jul 2021 20:11:11 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by smtp2.osuosl.org (Postfix) with ESMTPS id 1835040195 for ; Thu, 1 Jul 2021 20:11:10 +0000 (UTC) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4GG8VQ3fXjzF4Nc; Thu, 1 Jul 2021 13:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1625170270; bh=qxA0E05Nz8lMGOJOBzmaykJywTi5SZ5JD69kmIfOfeE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WaFzv7c5h1ctjNQ0t4xMrM3DF2taj39eke0nRINdQZryMuDmbJq/CsHW47Y7TADBB JNIMpllP/wZMpjxuUk69dOhnNB/2j708FYbO2e5PWN2hw9O2MOY4cMdbH3ofQnZDUt 47/qojYSAV0p8qVvBVNWYhKWefY7YReoCMoN8BPM= X-Riseup-User-ID: CFB48D37FAE3BB6A55ED20AC1EC883AC54154DA4276C5A54E1F64B3B610FCACB Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4GG8VQ2LBQz1yT1; Thu, 1 Jul 2021 13:11:10 -0700 (PDT) MIME-Version: 1.0 Date: Thu, 01 Jul 2021 13:11:10 -0700 From: raymo@riseup.net To: Billy Tetrud In-Reply-To: References: Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 01 Jul 2021 20:20:05 +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: Thu, 01 Jul 2021 20:11:13 -0000 Hi Billy, Sorry for late reply. Let’s 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’t 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’t 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’t 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 “nonproprietary” 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=5344020.0 >>> Can you please read it and share your idea about it. >>> >>> Cheers >>> Raymo >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev