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 E1C33C000E for ; Sun, 27 Jun 2021 11:05:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id D005A6061B for ; Sun, 27 Jun 2021 11:05:08 +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: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net 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 HCtYemzrdt1t for ; Sun, 27 Jun 2021 11:05:06 +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 smtp3.osuosl.org (Postfix) with ESMTPS id EEB5D60609 for ; Sun, 27 Jun 2021 11:05:05 +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 4GCSZ93Zs4zDs97; Sun, 27 Jun 2021 04:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1624791905; bh=778dzSdVFlzeZIAMVkfgoSlWx0/FB1xGV5jdYIWG9U0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TECTP/R650I2YiRhvh5B6p0nyo/Goj7q7np2Ey823PZAwO9xEbm/A+xXjb0Rx6ASK wcaP2zhAuKwQNSiI5tDWyritfuerlyQ00mGkcUDm3izfgyy8JKrrPT6cq/d9DIWAhT /RIcM8Jz566u7qXfYcrJk0Cneg1iDZrVgJOBU+gw= X-Riseup-User-ID: 4646665CED2D74D08D59EA8CE7B7B4D946D5CE5D1D2CFD9C1B90B3537A1D72F8 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4GCSZ91fvTz1yj4; Sun, 27 Jun 2021 04:05:04 -0700 (PDT) MIME-Version: 1.0 Date: Sun, 27 Jun 2021 04:05:04 -0700 From: raymo@riseup.net To: ZmnSCPxj In-Reply-To: References: <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com> <9c2cec326adee1f4d4152e2195da0e7b@riseup.net> Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 27 Jun 2021 12:19:38 +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: Sun, 27 Jun 2021 11:05:09 -0000 On 2021-06-27 04:53, ZmnSCPxj wrote: Good evening ZmnSCPxj It looks you already missed the entire design of Sabu and its restrictions. First of all, the Gazin wallet always controls the Sabu restrictions for every transaction in order to consider it as a valid transaction in a valid deal. That is, the creditor wallet controls the MT and GT in first place. Then if the transactions are valid the creditor consider entire process as a valid deal and give the services or goods in exchange of received Satoshis. So, in this scenario the issuer has to sign a MT transaction in which the issuer spends a UTXO worth at least 40,000 Sat, and issuer can issue maximum 20,000 Sat debt-document. So, the transaction can have One or more outputs for creditor(s), they must worth in total less than 20,000 Sat. Each transaction has to pay fixed 10,000 Sat as BTC-transaction-fee regardless the transaction length or the inputs/outputs amounts. The issuer always pays at least 4,000 Sat of BTC-transaction-fee, and the 6,000 remined fee must be paid by issuer and creditors in proportion to their outputs amounts) Finally, the transaction can have one change-back output to issuer address (same as input address) worth less than (40,000 – 4,000=36,000) Sat to issuer. This value depends on the debt amount and the issuer BTC-transaction-fee portion. The maximum issuer change back could be (40,000 -10,000 = 30,000) Sat for a transaction with no debt issuance. The minimum amount of change back would be (40,000 – 10,000 – 19,999 = 10,001 Sat). For more details, please take a look at figure 3. (Transaction in detail) in article https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180 also investigate on code https://github.com/raymaot/transaction-numbers-and-coefficients . The creditor controls all these criteria and after passing all these tests the creditor accept transaction as a valid transaction. Now creditor has 2 MT and GT transaction in his hand. Because of these number limitations, no arbitrary UTXO spending by issuer nor self-paying transaction can make more output and more benefits to him than respecting the already issued MT. please investigate on figure 1.0. (Security checks) for more details. Now show me a case (with precise amounts of inputs and outputs) that fits in Sabu restrictions AND issuer can make an arbitrary transaction with more benefit than MT! > the *largest* safe payment will vary depending on onchain mempool state, and if the mempool is almost empty, the largest safe payment will be much smaller than at other times. All these transactions are formed relatively (the numbers in GT are calculated based on MT), so they are relative, so no matter how much mempool is full or empty. The only consideration for mempool is the propagation delay which is another story and has its own solution as well. > I think your UX will be fairly awful. All validations and communications are behind the scene, so the UX will be enough smooth and friendly except the latency of email-based communications, which needs to be considered in details. BTW this is not a big deal considering the sovereignty and the freedom are bringing to our financial activities. > Good morning Raymo, > > >> Good morning ZmnSCPxj >> Sorry for late reply. >> >> > Guarantee Transactions (GT) being higher-fee is not assured. >> >> The question is “assuring what?”. >> The whole point of my proposal is the fact that issuers and creditors >> act rationally and won't harm their selves. The numbers (input and >> output amounts), the relation between inputs and outputs amounts, the >> minimum and maximum of inputs and outputs amounts, and conditions of a >> valid trans-action in Sabu protocol are all designed precisely to >> leading the rational users toward the making profit from the system. And >> irrationals (either issuer or creditor) can harm the others and >> inevitably in con-sequence will hurt themselves too. So, there is a fair >> and just transaction (MT). >> The creditor can send the GT to Bitcoin network and lose 70% of his >> money and damage 15% of is-suer money! >> Vice versa the issuer can send GT to Bitcoin network and harm itself 15% >> in cost of hurt creditors 70% which is none sense. Or issuer can pay >> even more money directly to miner and hurt itself even more which is >> even more irrational! Or the miner will ignore the transaction fees of a >> GT and put the fraudulent transaction in next block, which I cannot >> imagine a miner that pass up his legal and legiti-mate income in favor >> of a greedy issuer! >> Please write me a scenario (preferably with clear amount of inputs and >> outputs) by which the cheater (either issuer or creditor) gains more >> profit than playing honestly. >> Only in this case we can accept your claim about weakness of protocol. >> >> > Every offchain protocol needs the receiver as a signatory to any unconfirmed transaction. the receiver must be a signatory --- the receiver cannot trust an unconfirmed transaction where the spent UTXO has an alternate branch that does not have the receiver as a signatory. >> >> I intentionally decided to not using 2 of 2 signature, because I didn't >> want to fall in same trap as Light-ening. I wanted to avoid this long >> drilling 2 of 2 signings and routing. Instead, I just proposed to >> cre-ate and sign a valid Bitcoin transaction between only 2 people in a >> pure-peer-to-peer communication. The only signer is the issuer (the UTXO >> owner). >> Again, same logic. Please write me a scenario by which the cheater >> (issuer or creditor) can cheat this only-issuer-signed transactions and >> gains more profit than playing honest. Due to numbers and trans-action >> restrictions and the insignificance of the amount of each transaction >> this scenario of fraud will fail too. > > As the issuer is the only one signing, it can trivially create a > self-paying transaction by itself that is neither a valid MT nor a > valid GT. > > Suppose I have an MT that pays 1 BTC to you and has a 1 BTC change > output back to me. > After you hand over the equivalent of 1 BTC in other resources, I then > create an alternative transaction, signed only by myself, paying 0.5 > BTC to miners and 1.5 BTC to myself, and since the fee is so high, the > miners have every incentive to mine it. > > Yes, that is not a valid MT or GT, but nothing in the Bitcoin > blockchain layer requires that the *single* signer follow the > protocol. > The point here is that a single signer can sign anything, including a > transaction that is not an MT or a GT, but has arbitrary numbers that > are neither a valid GT nor a valid MT. > That is the reason why every trust-minimized offchain system requires > 2-of-2, somebody else has to countercheck the validity of a protocol > that is *not* directly on the blockchain. > The blockchain only cares about signature and timelock validity; it > does not care about (and check for validity) MTs and GTs. > > In essence, this is a trusted system where every creditor trusts every > issuer to *only* sign GTs and MTs, thus uninteresting --- you might as > well just use Coinbase as your offchain if you are going to inject > trust. > > Now you can counterargue that you intend this system to be used for > small payments and thus the fee for this non-MT non-GT clawback can > approach the security levels you so carefully computed for GT and MT, > but again --- the *largest* safe payment will vary depending on > onchain mempool state, and if the mempool is almost empty, the largest > safe payment will be much smaller than at other times. > This uncertainty is not handled well by most users, thus I think your > UX will be fairly awful. > > Regards, > ZmnSCPxj