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 285C6C001A for ; Tue, 29 Jun 2021 21:42:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 770956089C for ; Tue, 29 Jun 2021 21:42:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 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, RCVD_IN_MSPIKE_H4=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=protonmail.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 PG_iAfBFYfkb for ; Tue, 29 Jun 2021 21:42:32 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp3.osuosl.org (Postfix) with ESMTPS id 29ED860859 for ; Tue, 29 Jun 2021 21:42:31 +0000 (UTC) Date: Tue, 29 Jun 2021 21:42:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1625002949; bh=B8tsZ5ZZm/ZpRBg6HygE2lguNwprgnZrg8hrWEAW/kg=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=RHfvf1Q4SWusgdX8B9hP/mofUbpeAV4FOS0cmznFcwDK6jWkCt0fEKDWb9V450+NH LsFXAiZGC2ZHdxD8MOZp0DqkI4hwaaRSz/UCrFrcPR+eRblOzjuHdF+zvl8OovqHyU 51SztEiN3SztB99f8SjRABucEFJ/2Tahk1QrU19M= To: "raymo@riseup.net" From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <878e0de9f6b08d8aad07fc7b7760e01b@riseup.net> References: <16131549ac084b58fc6cde894e43babe@riseup.net> <878e0de9f6b08d8aad07fc7b7760e01b@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: Tue, 29 Jun 2021 21:42:36 -0000 Good morning Raymo, > Hey Alex, > > Your scenario works perfectly unless we put some restrictions on > accepting transaction by creditor (in our case Bob). > These are restrictions: > Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as > transaction input. > Alice has to reserve 10,000 Sat as transaction fee (for MT transaction) > regardless of transaction length or input/output amounts. > Alice always pays at least 4,000 Sat of BTC-transaction-fee, and the > 6,000 remined fee must be paid by she and Bob in proportion to their > outputs amounts) > Alice can issue a transaction the has maximum 20,000 outputs for > creditors (Bob and others). > The rest (if exist) is change back to Alice address. > The GT is formed based on MT. > Bob considers a transaction couple (MT, GT) valid only if they respect > these rules. > > Let=E2=80=99s put it in practice using some numbers (although you can fin= d more > detailed explanation in paper). > > The MT would be like that: > Input: 40,000 Satoshi > Outputs: > Bob: 20,000 > BTC-fee: 10,000 > Change back to Alice: 10,000 > > Based on this MT the GT will be > Input: 40,000 Satoshi > Outputs: > Bob: 20,000 =E2=80=93 20,00070% =3D 6,000 > BTC-fee: 10,000 + (14,000 of Bob=E2=80=99s output) + (1,500 of Alice= =E2=80=99s change > back) =3D 25,500 > Change back to Alice: 10,000 =E2=80=93 10,00015% =3D 8,500 > > Now if Alice wants to spend UTXO to Charlie with higher fee, she has to > pay at least 25,500 + 1 Satoshi as BTC fee in order to convince miners > to put his fraudulent transaction instead the GT in next block. > Alice already got 20,000 Sat profit from Bob. Now she can earn another > 14,999 Sat profit from Charlie because of same UTXO worth 40,000 > Satoshi. > Indeed, she spent 40,000 Sat and in total got equal to 34,999 Sat goods > or services. > Is she a winner? > I am not sure! > What do you think? You assume here that Alice the issuer only has a single UTXO and that it cr= eates a single transaction spending that UTXO. It is helpful to remember that miners consider fee*rate*, but your security= analysis is dependent on *fee* and not fee*rate*. Now consider, what if Alice creates 1000 UTXOs, promises GTs and MTs to 100= 0 different Bobs? Now, a GT has one input and two outputs. 1000 GTs have 1000 overheads (`nLockTime` and `nVersion` and so on), 1000 i= nputs, and 2000 outputs. Now Alice the issuer, being the sole signer, can create a fraudulent transa= ction that spends all 1000 UTXOs and spends it to a single Carol output. This fraudulent transaction has 1 overhead, 1000 inputs, and 1 output. Do you think Alice can get a better fee*rate* on that transaction while pay= ing a lower aggregate *fee* than all the GTs combined? Remember, you based your security analysis on Alice being forced to pay a l= arger *fee*, but neglect that miners judge transactions based on fee*rate*,= which is subtly different and not what you are relying on. I am sure that there exists some large enough number of UTXOs where a singl= e aggregating fraudulent transaction will be far cheaper than the tons of l= ittle GTs your security analysis depends on. This is why we do not use 1-of-1 signers in safe offchain protocols. Not your keys, not your coins. -- In addition, your analysis is based on assuming that miners are perfect rat= ional beings of perfect rationality, ***and*** are omniscient. In reality, miners possess bounded knowledge, i.e. they do not know everyth= ing. Even if Alice is in possession of only a single UTXO, Alice can still feed = miners a transaction with lower feerate than the MT, then feed the rest of = the network with a valid MT. Because transactions propagate through the network but this propagation is = ***not*** instantaneous, it is possible for the MT to reach the miners late= r than the fraudulent transaction. In this window of time, a block may be mined that includes the fraudulent t= ransaction, simply because the lucky miner never managed to hear of the cor= rect MT. This attack is essentially costless to Alice, especially for big enough tra= nsactions where mining fees are a negligible part of the payment. This is why we do not use 1-of-1 signers in safe offchain protocols. Not your keys, not your coins. Regards, ZmnSCPxj