📅 Original date posted:2020-06-10
📝 Original message: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 at 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" 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, 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" or
> "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 different
> 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,
> Ádám
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200610/5f548ea7/attachment.html>;
Greg Sanders [ARCHIVE] /
npub1jd…3gh0m
2023-06-07 18:25:22
in reply to nevent1q…ghzm
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-07 18:25:22Event JSON
{
"id": "b0142894d736c222c51f14a208d552fbbabef796fe74b0d27b33eba111c52ba4",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1686162322,
"kind": 1,
"tags": [
[
"e",
"cc7bb00770172928dfda3d5dd0ba048857174c5d9d67ec73d350c1527bb3906e",
"",
"root"
],
[
"e",
"1fd1e6bec7a62c40185c36d36b6d70b45779872f5c2a07fa0a46864e3679c85c",
"",
"reply"
],
[
"p",
"63bdd91cabec9ebd43ac9e0f214409f951ed12819092cd1bcba2480bf695c94c"
]
],
"content": "📅 Original date posted:2020-06-10\n📝 Original message:A major point of defeating the common input heuristic and others is to make\n\"super-clusters\". A small number of users that \"don't care\" about possibly\ntouching tainted coins can render many chain analysis techniques unworkable\nin practice for enforcement. You don't need 100% coverage to defeat the\nheuristic.\n\nOn Wed, Jun 10, 2020 at 9:40 AM nopara73 via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e The problem with CoinJoins is that desire for privacy is explicitly\n\u003e signalled by them, so adversaries can consider them \"suspicious.\" PayJoin\n\u003e and CoinSwap solve this problem, because they are unnoticeable. I think\n\u003e this logic doesn't stand for scrutiny.\n\u003e\n\u003e From here on let's use the terminology of a typical adversary: there are 3\n\u003e kinds of coin histories: \"clean\", \"dirty\" and \"suspicious\".\n\u003e The aftermath of you using a \"dirty\" coin is knocks on your door. You\n\u003e using a \"suspicious\" coin is uncomfortable questions and you using a\n\u003e \"clean\" coin is seamless transfer.\n\u003e\n\u003e In scenario 1, you start out with a \"clean\" history. By using CoinJoins\n\u003e you make your new coin's history \"suspicious\" so you have no incentive to\n\u003e CoinJoin. By using CoinSwap/PayJoin your new coin can be either \"clean\" or\n\u003e \"dirty\". What would a \"clean\" coin owner prefer more? Take the risk of\n\u003e knocking on the door or answering uncomfortable questions?\n\u003e\n\u003e In scenario 2, you start out with a \"dirty\" history. By using CoinJoins\n\u003e you make your new coin's history \"suspicious\" so you have an incentive to\n\u003e CoinJoin. By using CoinSwap/PayJoin your new coin can either be \"clean\" or\n\u003e \"dirty\". What would a \"dirty\" coin owner prefer more? And here's an\n\u003e insight: you may get knocks on your door for a dirty coin that you have\n\u003e nothing to do with. And you can prove this fact to the adversary, but by\n\u003e doing so, you'll also expose that you started out with a \"dirty\" coin to\n\u003e begin with and now the adversary becomes interested in you for a different\n\u003e reason.\n\u003e\n\u003e You can also examine things assuming full adoption of PJ/CS vs full\n\u003e adoption of CJ, but you'll see that full adoption of any of these solves\n\u003e the tainting issue.\n\u003e\n\u003e So my current conclusion is that PJ/CS does not only not solve the taint\n\u003e problem, it just alters it and ultimately very similar problems arise for\n\u003e the users. Maybe the goal of unobservable privacy is a fallacy in this\n\u003e context as it is based on the assumption that desiring privacy is\n\u003e suspicious, so you want to hide the fact that you desire privacy. And the\n\u003e solution to the taint issue is either protocol change or social change\n\u003e (decent adoption.)\n\u003e\n\u003e PS.: Please try to keep the conversation to the Taint Issue as this email\n\u003e of mine isn't supposed to be discussing general pros and cons of various\n\u003e privacy techniques.\n\u003e\n\u003e Any thoughts?\n\u003e\n\u003e --\n\u003e Best,\n\u003e Ádám\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200610/5f548ea7/attachment.html\u003e",
"sig": "ba3d3709f3a0582ee8680c147a4355e0a67041735d9e00bbd8447d592a8e894cbe66a11341f2bad4bc81893eef492cdc2dffc369aa4218ba7cbed89c34895068"
}