{"type":"rich","version":"1.0","author_name":"npub19gq8ya0cwzxc2l3lcefrmtg0e0judfdp75cyxdfq2wssfzpckrts74xcws","author_url":"https://nostr.ae/npub19gq8ya0cwzxc2l3lcefrmtg0e0judfdp75cyxdfq2wssfzpckrts74xcws","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-06-23\n📝 Original message:Hi there,\n   For users who don’t wish a service provider to be able to see their\ninformation, even ephemerally, and they would like to exchange information\nvia BIP75, they can use a software wallet, such as a breadwallet or others,\nand that data will only exist on their phone, and the phone of their\ncounterparty (assuming the counterparty also chose to exchange info, and\nwas running on a software wallet).\n\nIn this way, we allow users to exchange data as they choose, without having\nthe risk that a service provider be asked for that data.\n\nIf a user chooses to use a hosted platform, and also to store their\nidentity data there, I do agree it could be subject to a subpoena, the same\nas when they host their email, and other services.\n\nFinally, they could choose not to use BIP75 at all, and no one would know\nwhether they did or didn’t (other than their counterparts) as we don’t\nleave any residue on the blockchain, or anywhere else in the public eye.\n\nWe believe that this solution, due in part to its narrow data aperture, is\nthe best solution available to the problem we are solving.  We are eager to\nengage in any discussions about how to improve the proposed solution, with\nan eye to fungibility, privacy, and usability.\n\nThat said, there is a real need for people to know who they are transacting\nwith for usability reasons, for fraud reduction, and also of regulatory\nreasons for some players.  To NOT solve it with a carefully crafted\nstandard means that it is more likely to be solved with back room, quick\nand dirty solutions that are not available for community review and\nfeedback.\n\nThanks!\n\nJustin\n\n\n\n\n\n\nOn Thu, Jun 23, 2016 at 2:31 PM, Police Terror via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e In England under RIPA 2000 legislation, it's irrelevant whether you have\n\u003e the data or not. If the authorities compel you to hand over that\n\u003e information, and it is within your means to obtain it then you are\n\u003e obliged to do so under threat of criminal offense.\n\u003e\n\u003e So any mechanism whereby data could be collected from Bitcoin users,\n\u003e whether it's stored ephemerally or not, if the police have reasonable\n\u003e suspicion to think it exists then they can compel all parties to work to\n\u003e get them the data they require.\n\u003e\n\u003e If the mechanism flat out does not exist, that is miles better than\n\u003e could exist. Deniability is not a defense when served with a police\n\u003e notice for disclosing data.\n\u003e\n\u003e You have to think not only about the end result, but also about how\n\u003e these mechanisms can be used for intimidating users or leveraging\n\u003e technologies.\n\u003e\n\u003e Justin Newton via bitcoin-dev:\n\u003e \u003e On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev \u003c\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw\n\u003e \u003e\u003e expectations from _all_ users from authorities. Companies or individuals\n\u003e \u003e\u003e who want and/or need AML/KYC can find ways and do it at their side\n\u003e \u003e\u003e isolated from the entire network, and the solutions shouldn't come from\n\u003e \u003e\u003e upstream. AML/KYC/\u003cinsert other regulation here\u003e differ from country to\n\u003e \u003e\u003e country and will be hard to implement in a global consensus network even\n\u003e \u003e\u003e if it would be worth it.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e This was precisely our thinking as well.\n\u003e \u003e\n\u003e \u003e This is actually exactly why BIP 75 was designed the way that it was.\n\u003e Any\n\u003e \u003e (voluntary) identity exchange is done at the application level, on an\n\u003e \u003e encrypted https (or other) connection between the sender and receiver.\n\u003e \u003e Identity data is not passed through or stored on the blockchain, and\n\u003e there\n\u003e \u003e is actually no mark left on the blockchain that identity was even\n\u003e exchanged\n\u003e \u003e on that transaction.\n\u003e \u003e\n\u003e \u003e The only people who know identity info was exchanged, or what the\n\u003e identity\n\u003e \u003e was is the counterparties in the transaction, and depending on\n\u003e \u003e implementation, their service provider.  (At a high level, many software\n\u003e \u003e based wallet providers wouldn’t have any visibility into identity info,\n\u003e \u003e where many hosted services would, for example)\n\u003e \u003e\n\u003e \u003e We did this to protect user privacy as well as fungibility.\n\u003e \u003e\n\u003e \u003e We are allowing the people who want or need to exchange identtity info\n\u003e \u003e (either self signed or 3rd party validated) the option to exchange it,\n\u003e in a\n\u003e \u003e standards based way, directly between peers, without touching the\n\u003e \u003e blockchain or network itself.\n\u003e \u003e\n\u003e \u003e Is this more clear?\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\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\n\n\n-- \n\nJustin W. Newton\nFounder/CEO\nNetki, Inc.\n\njustin at netki.com\n+1.818.261.4248\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/cc872bf8/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: PastedGraphic-1.tiff\nType: image/tiff\nSize: 10972 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/cc872bf8/attachment-0001.tiff\u003e"}