{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-06-23\n📝 Original message:On Tue, Jun 21, 2016 at 05:14:31PM -0700, Justin Newton wrote:\n\u003e On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev \u003c\n\u003e Hi Peter,\n\u003e    Certainly AML/KYC compliance is one of the use cases that BIP 75 and our\n\u003e certificates can support.  As a quick summary,\n\u003e \n\u003e There are individuals and entities that would like to buy, sell, and use\n\u003e bitcoin, and other public blockchains, but that have compliance\n\u003e requirements that they need to meet before they can do so.  Similarly,\n\u003e companies and entrepreneurs in the space suffer under the potential threat\n\u003e of fines, or in extreme cases, jail time, also for not meeting AML or\n\u003e sanctions list compliance.  We wanted to build tools that allowed\n\u003e entrepreneurs to breathe easy, while at the same time allow more people and\n\u003e companies to enter the ecosystem.  We also believe that the solution we are\n\u003e using has the characteristics that you want in such a solution, for example:\n\u003e \n\u003e 1\u003e Only the counterparties (and possibly their service providers in the\n\u003e case of hosted services) in a transaction can see the identity data,\n\u003e protecting user privacy.\n\u003e \n\u003e 2\u003e The counterparties themselves (and possibly their service providers in\n\u003e the case of hosted services) decide whether identity information is\n\u003e required for any given transaction.\n\u003e \n\u003e 3\u003e No trace is left on the blockchain or anywhere else (other than with the\n\u003e counterparties) that identity information was even exchanged, protecting\n\u003e fungibility\n\u003e \n\u003e 4\u003e The solution is based on open source and open standards, allowing open\n\u003e permissionless innovation, versus parties building closed networks based on\n\u003e closed standards.  The very fact that this solution went through the BIP\n\u003e process and was adapted based on feedback is an example of how this is\n\u003e better for users than the inevitable closed solution that would arise if\n\u003e the open source, community vetted version didn’t already exist.\n\u003e \n\u003e I don’t know if you are opposed to organizations that have AML requirements\n\u003e from using the bitcoin blockchain, but if you aren’t, why wouldn’t you\n\u003e prefer an open source, open standards based solution to exclusionary,\n\u003e proprietary ones?\n\nIn some (most?) countries, it is illegal to offer telecoms services without\nwiretap facilities. Does that mean Tor builds into its software \"open source\"\n\"open standards\" wiretapping functionality? No. And interestingly, people\ntrying to add support for that stuff is actually a thing that keeps happening\nin the Tor community...\n\nIn any case, I'd strongly argue that we remove BIP75 from the bips repository,\nand boycott wallets that implement it. It's bad strategy for Bitcoin developers\nto willingly participate in AML/KYC, just the same way as it's bad for Tor to\nadd wiretapping functionality, and W3C to support DRM tech. The minor tactical\nwins you'll get our of this aren't worth it.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/594d6918/attachment.sig\u003e"}