From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B1AA0C016F for ; Wed, 10 Jun 2020 13:49:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id A060688B83 for ; Wed, 10 Jun 2020 13:49:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGUBi0uWgh62 for ; Wed, 10 Jun 2020 13:49:09 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by hemlock.osuosl.org (Postfix) with ESMTPS id 9C56B88ADB for ; Wed, 10 Jun 2020 13:49:09 +0000 (UTC) Received: by mail-wm1-f51.google.com with SMTP id q25so1917587wmj.0 for ; Wed, 10 Jun 2020 06:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=aKZd3j0Iw227tu5MpUHRdZpf6SUMWrvDzw+EWchrMqM=; b=faGc73XuXOPliwLRsceSWnOFpZ0YJtH0UjcDhG5HaAcYz+VdK5RwjaUkT0AhAXR/6a vh8pvPwDgrf/lvKDCZteDYnWJKPaCGdgituCje748OFaQjZamB9JTbhus4hD6pfNGgP0 iWruA7ZOtaUCq4ctV6nZO/UhG6Wh/oNvZbmIAZffVWJIoyJVkoY/KNx8qQQ34qO6+xb5 maP7jzSdAgrgGvbMYawpe0VYa4hJhpGKg4rYytTLQMygDEejWupa64o2CN1MT3Zx3+yR AJkTDyDmlIKJY1Tc3PNpiSVVDtbluPst4EM8zDhK2d4lDCxEJyp9NlI+7VqFcdi3NSBY 1zOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=aKZd3j0Iw227tu5MpUHRdZpf6SUMWrvDzw+EWchrMqM=; b=nWfJM6/BP0il4V9MqQEuRvWLyJhfHT8a1vdp9ixa1Var0SUOyl//5l6B6/exJwmcKH kSQOkhOf88iR9VoJrBKqim0cpODePdbmc44N1OAYXnBEOp2WwH0SitsTkIUSLPI6RIJy aBYBpzMT2OEbln7DGWDIinzWz2hL8CbLE+UaGWHscE2L8bAYwfuHQYZhozzRczLq2btV 1lCkAME2A7xIUW/rEqLk3g3aX+rmfL3Mn4x9Sc8rl5l5A7fHLTnbKHXPCnaTIvV2IExv oeFWNfgzOoYyEqsaX2Jkxhhld8FC9PAsGAHVqbnlNF8K4x+6Z2CjSQ4XeNL89udVz7Lh L+hA== X-Gm-Message-State: AOAM530ibK08bJCfgDuo24GUHH7OqmpCu1KCnR3UdOxspIwGtYra0KVl AkxZivw13E3qDSTKFh1ukAzMAY4KGFyrzX7bE8CfCEna X-Google-Smtp-Source: ABdhPJxi9HCqBsko7puMfMcx87mrADQebeCKNr/FZHqQ686tilyHdrCLHW5VZvfTFjxomyupmdnqjpaHAUely6fgEN8= X-Received: by 2002:a1c:6583:: with SMTP id z125mr3420029wmb.102.1591796946894; Wed, 10 Jun 2020 06:49:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Wed, 10 Jun 2020 09:48:55 -0400 Message-ID: To: nopara73 , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000009303b505a7bb1b1e" Subject: Re: [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap 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, 10 Jun 2020 13:49:10 -0000 --0000000000009303b505a7bb1b1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A major point of defeating the common input heuristic and others is to make "super-clusters". A small number of users that "don't care" about possibly touching tainted coins can render many chain analysis techniques unworkable in practice for enforcement. You don't need 100% coverage to defeat the heuristic. On Wed, Jun 10, 2020 at 9:40 AM nopara73 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The problem with CoinJoins is that desire for privacy is explicitly > signalled by them, so adversaries can consider them "suspicious." PayJoin > and CoinSwap solve this problem, because they are unnoticeable. I think > this logic doesn't stand for scrutiny. > > From here on let's use the terminology of a typical adversary: there are = 3 > kinds of coin histories: "clean", "dirty" and "suspicious". > The aftermath of you using a "dirty" coin is knocks on your door. You > using a "suspicious" coin is uncomfortable questions and you using a > "clean" coin is seamless transfer. > > In scenario 1, you start out with a "clean" history. By using CoinJoins > you make your new coin's history "suspicious" so you have no incentive to > CoinJoin. By using CoinSwap/PayJoin your new coin can be either "clean" o= r > "dirty". What would a "clean" coin owner prefer more? Take the risk of > knocking on the door or answering uncomfortable questions? > > In scenario 2, you start out with a "dirty" history. By using CoinJoins > you make your new coin's history "suspicious" so you have an incentive to > CoinJoin. By using CoinSwap/PayJoin your new coin can either be "clean" o= r > "dirty". What would a "dirty" coin owner prefer more? And here's an > insight: you may get knocks on your door for a dirty coin that you have > nothing to do with. And you can prove this fact to the adversary, but by > doing so, you'll also expose that you started out with a "dirty" coin to > begin with and now the adversary becomes interested in you for a differen= t > reason. > > You can also examine things assuming full adoption of PJ/CS vs full > adoption of CJ, but you'll see that full adoption of any of these solves > the tainting issue. > > So my current conclusion is that PJ/CS does not only not solve the taint > problem, it just alters it and ultimately very similar problems arise for > the users. Maybe the goal of unobservable privacy is a fallacy in this > context as it is based on the assumption that desiring privacy is > suspicious, so you want to hide the fact that you desire privacy. And the > solution to the taint issue is either protocol change or social change > (decent adoption.) > > PS.: Please try to keep the conversation to the Taint Issue as this email > of mine isn't supposed to be discussing general pros and cons of various > privacy techniques. > > Any thoughts? > > -- > Best, > =C3=81d=C3=A1m > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000009303b505a7bb1b1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A major point of defeating the common input heuristic and = others is to make "super-clusters". A small number of users that = "don't care" about possibly touching tainted coins can render= many chain analysis techniques unworkable in practice for enforcement. You= don't need 100% coverage to defeat the heuristic.=C2=A0

On Wed, Jun 10,= 2020 at 9:40 AM nopara73 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> w= rote:
The problem with CoinJoins is that desire for privacy is explicitl= y signalled by them, so adversaries can consider them "suspicious.&quo= t; PayJoin and CoinSwap solve this problem, because they are unnoticeable. = I think this logic doesn't stand for scrutiny.

From = here on let's use the terminology of a typical adversary: there are 3 k= inds of coin histories: "clean", "dirty" and "susp= icious".
The aftermath of you using a "dirty" coin is kno= cks on your door. You using a "suspicious" coin is uncomfortable = questions and you using a "clean" coin is seamless transfer.

In scenario 1, you start out with a "clean" = history. By using CoinJoins you make your new coin's history "susp= icious" so you have no incentive to CoinJoin. By using CoinSwap/PayJoi= n your new coin can be either "clean" or "dirty". What = would a "clean" coin owner prefer more? Take the risk of knocking= on the door or answering uncomfortable questions?

In scenario 2, yo= u start out with a "dirty"=20 history.=20 By using CoinJoins you make your new coin's history "suspicious&qu= ot; so you have an incentive to CoinJoin. By using CoinSwap/PayJoin your new coin can either be "clean" or= "dirty".=20 What would a "dirty" coin owner prefer more? And here's an in= sight: you may get knocks on your door for a dirty coin that you have nothi= ng to do with. And you can prove this fact to the adversary, but by doing s= o, you'll also expose that you started out with a "dirty" coi= n to begin with and now the=20 adversary becomes interested in you for a different reason.

Y= ou can also examine things assuming full adoption of PJ/CS vs full adoption= of CJ, but you'll see that full adoption of any of these solves the ta= inting issue.

So my current conclusion is that PJ/CS does= not only not solve the taint problem, it just alters it and ultimately ver= y similar problems arise for the users. Maybe the goal of unobservable priv= acy is a fallacy in this context=C2=A0as it is based on the assumption that= desiring privacy is suspicious, so you want to hide the fact that you desi= re privacy. And the solution to the taint issue is either protocol change o= r social change (decent adoption.)

PS.: Please try to keep the conve= rsation to the Taint Issue as this email of mine isn't supposed to be d= iscussing general pros and cons of various privacy techniques.

Any thoughts?

--
Best,
=C3=81d=C3=A1m
<= /div>
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000009303b505a7bb1b1e--