From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B10C0C000E for ; Sun, 27 Jun 2021 04:54:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 89EA44033B for ; Sun, 27 Jun 2021 04:54:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 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, FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr8qO4JHJn2E for ; Sun, 27 Jun 2021 04:54:06 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) by smtp4.osuosl.org (Postfix) with ESMTPS id 5BDC4402C6 for ; Sun, 27 Jun 2021 04:54:06 +0000 (UTC) Date: Sun, 27 Jun 2021 04:53:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1624769642; bh=Y266dpzedqlN+nv/Ldl0kw7+ZbJN91IstvSnKWdhc/k=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=aaOl5Cy1TmhTCxqSKazzjtYEScfthArguUG/410A4LP2Uq37xCNqX6pt7IhRqmT+f w8GcdWzZzW1hpb+Ky2Cj/O9ONj9MhKQo/RtILJA4JjevXYdNsgIP48TRkf4GqHPRQu 8oiv4vA+fEqlyYZleDwna5lssvPck8/fyI2Lx6Cs= To: "raymo@riseup.net" From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <9c2cec326adee1f4d4152e2195da0e7b@riseup.net> References: <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com> <9c2cec326adee1f4d4152e2195da0e7b@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 04:54:08 -0000 Good morning Raymo, > Good morning ZmnSCPxj > Sorry for late reply. > > > Guarantee Transactions (GT) being higher-fee is not assured. > > The question is =E2=80=9Cassuring what?=E2=80=9D. > 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 unconf= irmed transaction. the receiver must be a signatory --- the receiver cannot= trust an unconfirmed transaction where the spent UTXO has an alternate bra= nch 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-payin= g 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 b= ack to me. After you hand over the equivalent of 1 BTC in other resources, I then crea= te an alternative transaction, signed only by myself, paying 0.5 BTC to min= ers and 1.5 BTC to myself, and since the fee is so high, the miners have ev= ery incentive to mine it. Yes, that is not a valid MT or GT, but nothing in the Bitcoin blockchain la= yer requires that the *single* signer follow the protocol. The point here is that a single signer can sign anything, including a trans= action that is not an MT or a GT, but has arbitrary numbers that are neithe= r 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 *no= t* directly on the blockchain. The blockchain only cares about signature and timelock validity; it does no= t care about (and check for validity) MTs and GTs. In essence, this is a trusted system where every creditor trusts every issu= er to *only* sign GTs and MTs, thus uninteresting --- you might as well jus= t 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 p= ayments and thus the fee for this non-MT non-GT clawback can approach the s= ecurity 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 wi= ll be fairly awful. Regards, ZmnSCPxj