From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id AC901C000A for ; Wed, 17 Mar 2021 04:11:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 86704836C3 for ; Wed, 17 Mar 2021 04:11:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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_DNSWL_NONE=-0.0001, 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: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHMlOIdkPvew for ; Wed, 17 Mar 2021 04:11:42 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by smtp1.osuosl.org (Postfix) with ESMTPS id D8B9E83658 for ; Wed, 17 Mar 2021 04:11:41 +0000 (UTC) Date: Wed, 17 Mar 2021 04:11:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1615954297; bh=nIOnh5Mw1xb/uOKAfqRG1mG9StxZDmEcWf66wSCh/FE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=A+xHGaTDunDFxeI8KV4lWWEjcIw1H0EpggXbU74F/qnwPJGA8fdhOougeozhBy05W MkQJVYZ309SAKcMkxgFrGrisVjSPvR40lkihOWP2Ryhdx6EbSEeWs3Xu9eiA1ICLjN u6UuZOYBiqIL8++OS6eKPruPn8k9wZQ3WTX8LJyQ= To: DA Williamson From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <4ltFpTt8QxX44nedimzJ7J4F1bIhwxb9rbqf1DeGlYX8W7CduYCy64miuq2IIjee_K5rBV6ofEPzdYQniEq6IR4I7ZO5ENlk9z-mQPs-YZE=@protonmail.com> In-Reply-To: <932f2f2866cac087a207f8757c9df4b776ccdb04.camel@willtech.com.au> References: <170b27c0-436f-c440-e3c3-f9577b764972@riseup.net> <932f2f2866cac087a207f8757c9df4b776ccdb04.camel@willtech.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Taproot NACK 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: Wed, 17 Mar 2021 04:11:43 -0000 Good morning JAMES, > Good Afternoon, > > Verifiable and independantly verifiable are not the same. Independantly > scrutinable means any public can scrutinise blockchain to determine it > is honest. It does not rely on involved parties but insistently on the > data published in the blockchain. The involved parties ultimately publish the data on the blockchain, and the= result is independently validatable. All that each involved party has to do is validate for itself that it does = not lose any funds, and, by the operation of math, the summary result does = not result in any loss (or creation) of funds, thus CoinJoin cannot lead to= fraud. I do not see much of a point in your objection here. For example, in the case of Lightning, the individual payments made by the = participants in the channel cannot be verified by anyone else (they can lie= about the payments that occurred on their channel). But both participants in the channel need to agree on a single result, and = it is that summary result that is independently verified onchain and publis= hed. Indeed, one major technique for privacy improvement in Bitcoin is the simpl= e technique of creating summaries of multiple actions without revealing det= ails. Such a general class of techniques works by reducing the data pushed onchai= n which provides both (a) scale because less data on chain and (b) privacy = because less data is analyzable onchain. Basically --- 1. The entire point of a public blockchain is to prevent uncontrolled forg= ery of the coin. Only particular rules allow construction of new coins (in Bitcoin, the = mining subsidy). 2. Various techniques can be used to support the above central point. * The simplest is to openly publish every amount value in cleartext. * However, this is not necessarily the ***only*** acceptable way to a= chieve the goal! * Remember, the point is to prevent uncontrolled forgery. The point is **not** mass surveillance. * Another method would be to openly publish **summaries** of transactio= ns, such as by Lightning Network summarizing the result of multiple payment= s. * CoinJoin is really just a way to summarize multiple self-payments. * Another method would be to use homomorphisms between a cleartext and = a ciphertext, and publish only the ciphertext (which can be independently v= erified as correctly being added together and that inputs equal outputs plu= s fees). No privacy technique worth discussing and development in Bitcoin gets aroun= d the above point, and thus fraud cannot be achieved with those (at least i= f we define fraud simply as "those who control the keys control the coins" = --- someone stealing a copy of your privkeys is beyond this definition of f= raud). Any privacy improvement Taproot buys (mostly in LN, but also some additiona= l privacy for CoinSwap) will still not allow fraud. Regards, ZmnSCPxj