<oembed><type>rich</type><version>1.0</version><author_name>npub1la96qlytstsrg6nzha6d3q329vkcccsun4wjjzqlxxdp3xm9mrhqkv90n4</author_name><author_url>https://nostr.ae/npub1la96qlytstsrg6nzha6d3q329vkcccsun4wjjzqlxxdp3xm9mrhqkv90n4</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2016-06-23&#xA;📝 Original message:In England under RIPA 2000 legislation, it&#39;s irrelevant whether you have&#xA;the data or not. If the authorities compel you to hand over that&#xA;information, and it is within your means to obtain it then you are&#xA;obliged to do so under threat of criminal offense.&#xA;&#xA;So any mechanism whereby data could be collected from Bitcoin users,&#xA;whether it&#39;s stored ephemerally or not, if the police have reasonable&#xA;suspicion to think it exists then they can compel all parties to work to&#xA;get them the data they require.&#xA;&#xA;If the mechanism flat out does not exist, that is miles better than&#xA;could exist. Deniability is not a defense when served with a police&#xA;notice for disclosing data.&#xA;&#xA;You have to think not only about the end result, but also about how&#xA;these mechanisms can be used for intimidating users or leveraging&#xA;technologies.&#xA;&#xA;Justin Newton via bitcoin-dev:&#xA;&gt; On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev &lt;&#xA;&gt; bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&gt; &#xA;&gt;&gt;&#xA;&gt;&gt;&#xA;&gt;&gt;&#xA;&gt;&gt; Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw&#xA;&gt;&gt; expectations from _all_ users from authorities. Companies or individuals&#xA;&gt;&gt; who want and/or need AML/KYC can find ways and do it at their side&#xA;&gt;&gt; isolated from the entire network, and the solutions shouldn&#39;t come from&#xA;&gt;&gt; upstream. AML/KYC/&lt;insert other regulation here&gt; differ from country to&#xA;&gt;&gt; country and will be hard to implement in a global consensus network even&#xA;&gt;&gt; if it would be worth it.&#xA;&gt;&gt;&#xA;&gt;&gt;&#xA;&gt; This was precisely our thinking as well.&#xA;&gt; &#xA;&gt; This is actually exactly why BIP 75 was designed the way that it was.  Any&#xA;&gt; (voluntary) identity exchange is done at the application level, on an&#xA;&gt; encrypted https (or other) connection between the sender and receiver.&#xA;&gt; Identity data is not passed through or stored on the blockchain, and there&#xA;&gt; is actually no mark left on the blockchain that identity was even exchanged&#xA;&gt; on that transaction.&#xA;&gt; &#xA;&gt; The only people who know identity info was exchanged, or what the identity&#xA;&gt; was is the counterparties in the transaction, and depending on&#xA;&gt; implementation, their service provider.  (At a high level, many software&#xA;&gt; based wallet providers wouldn’t have any visibility into identity info,&#xA;&gt; where many hosted services would, for example)&#xA;&gt; &#xA;&gt; We did this to protect user privacy as well as fungibility.&#xA;&gt; &#xA;&gt; We are allowing the people who want or need to exchange identtity info&#xA;&gt; (either self signed or 3rd party validated) the option to exchange it, in a&#xA;&gt; standards based way, directly between peers, without touching the&#xA;&gt; blockchain or network itself.&#xA;&gt; &#xA;&gt; Is this more clear?&#xA;&gt; &#xA;&gt; &#xA;&gt; &#xA;&gt; _______________________________________________&#xA;&gt; bitcoin-dev mailing list&#xA;&gt; bitcoin-dev at lists.linuxfoundation.org&#xA;&gt; https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev&#xA;&gt;</html></oembed>