Return-Path: <ZmnSCPxj@protonmail.com> Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 747AFC077D for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 29 Dec 2019 10:23:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 5E9A984489 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 29 Dec 2019 10:23:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0ldmgIaeUg7 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 29 Dec 2019 10:23:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 8CC5A84415 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 29 Dec 2019 10:23:45 +0000 (UTC) Date: Sun, 29 Dec 2019 10:23:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1577615023; bh=pNNFp+629K8+W8wzEdcoAaVljFe4Tuo7JET7ZZVbhPE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=X+hl2/YgpM+ybcW0YZirmx0RmhkkT7MJJh5GDOrgxBuYaZ0crlyO0qz4IkIEPpiBX uu3fOgJONl2QtUNKKIrmC5u4oUXeyokuSF9CaOHGbWhSEC+oyHUQjBlOrwZrGLS51W l9yZRMxYUOGOL0VQfIrQeJXXjrn0MdAJg6yKkBCs= To: Yuval Kogman <nothingmuch@woobling.org>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> From: ZmnSCPxj <ZmnSCPxj@protonmail.com> Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> Message-ID: <Ucl9pe26g2ECz-SRmXPV3WLxVR8PBOf0dnMR_aD8NwTqBNmq6e3a9hKJtwkYPJz7v_QUCxT_Y5X0w1VkvbiQZ6H3QJVcOtpUhNYTQ29rwFA=@protonmail.com> In-Reply-To: <CAAQdECBqFKxAoZXCkWynN4wj5g8C9vzdhuEWk9b-BYqDW=us6g@mail.gmail.com> References: <CAEPKjgdtgDbyLoj6FV+cjY1Djca_FBtd9Kt_eB4zWU+at=wfYQ@mail.gmail.com> <CAAQdECBqFKxAoZXCkWynN4wj5g8C9vzdhuEWk9b-BYqDW=us6g@mail.gmail.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Non-equal value CoinJoins. Opinions. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Sun, 29 Dec 2019 10:23:47 -0000 Good morning Yuval, > Additionally (though is a broader criticism of CoinJoin based privacy and= not specific to unequal amounts, and in particular refers to ZmnSCPxj's as= sertion of 0 linkability) I am very worried that perspectives that focus on= linkability information revealed by a single coinjoin transaction in isola= tion. This problem was alluded in the document, to but I don't see that it = was addressed. Naively the post/pre mix transaction graph would seem to pre= sent a computationally much harder problem when looking at the combinatoric= s through the same lens, but reality it can also be used to place many cons= traints on valid partitions/sub-transaction assignments for a single transa= ction with equal amounts. The trivial example is post mix linking of output= s, but there are many other ways to draw inferences or eliminate possible i= nterpretations of a single transaction based on its wider context, which in= turn may be used to attack other transactions. Indeed, this is a problem still of equal-valued CoinJoin. In theory the ZeroLink protocol fixes this by strongly constraining user be= havior, but ZeroLink is not "purely" implemented in e.g. Wasabi: Wasabi sti= ll allows spending pre- and post-mix coins in the same tx (ZeroLink disallo= ws this) and any mix change should be considered as still linked to the inp= uts (though could be unlinked from the equal-valued output), i.e. returned = to pre-mix wallet. > Finally, the proof as well as its applicability seems suspect to me, sinc= e seems to involve trusting the server: > "Since the distinct list [...] [is] kept on the server and not shared wit= h the players" > "The server knows the linkages of the commitments but does not participat= e as a verifier " > "If there is a problem [...] each component is assigned to another player= at random for verification" > these 3 statements together seems to suggest the server is trusted to not= use sybils in order the compromise privacy by participating in the verific= ation process? Equal-valued CoinJoins fix this by using a Chaumian bank, which constrains = value transfers to specific fixed amounts. Since an equal-valued CoinJoin uses a single fixed amount anyway, it is not= an additional restriction. CashFusion cannot use the same technique without dropping into something ve= ry much like an equal-valued CoinJoin. Regards, ZmnSCPxj