{"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-21\n📝 Original message:On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Mon, Jun 20, 2016 at 05:33:32PM +0000, Erik Aronesty via bitcoin-dev\n\u003e wrote:\n\u003e\n\u003e \u003e - missing an optional client supplied identification\n\u003e\n\u003e Note that \"client supplied identification\" is being pushed for AML/KYC\n\u003e compliance, e.g. Netki's AML/KYC compliance product:\n\u003e\n\u003e\n\u003e http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/\n\u003e\n\u003e This is an extremely undesirable feature to be baking into standards given\n\u003e it's\n\u003e negative impact on fungibility and privacy; we should not be adopting\n\u003e standards\n\u003e with AML/KYC support, for much the same reasons that the W3C should not be\n\u003e standardizing DRM.\n\u003e\n\nHi Peter,\n   Certainly AML/KYC compliance is one of the use cases that BIP 75 and our\ncertificates can support.  As a quick summary,\n\nThere are individuals and entities that would like to buy, sell, and use\nbitcoin, and other public blockchains, but that have compliance\nrequirements that they need to meet before they can do so.  Similarly,\ncompanies and entrepreneurs in the space suffer under the potential threat\nof fines, or in extreme cases, jail time, also for not meeting AML or\nsanctions list compliance.  We wanted to build tools that allowed\nentrepreneurs to breathe easy, while at the same time allow more people and\ncompanies to enter the ecosystem.  We also believe that the solution we are\nusing has the characteristics that you want in such a solution, for example:\n\n1\u003e Only the counterparties (and possibly their service providers in the\ncase of hosted services) in a transaction can see the identity data,\nprotecting user privacy.\n\n2\u003e The counterparties themselves (and possibly their service providers in\nthe case of hosted services) decide whether identity information is\nrequired for any given transaction.\n\n3\u003e No trace is left on the blockchain or anywhere else (other than with the\ncounterparties) that identity information was even exchanged, protecting\nfungibility\n\n4\u003e The solution is based on open source and open standards, allowing open\npermissionless innovation, versus parties building closed networks based on\nclosed standards.  The very fact that this solution went through the BIP\nprocess and was adapted based on feedback is an example of how this is\nbetter for users than the inevitable closed solution that would arise if\nthe open source, community vetted version didn’t already exist.\n\nI don’t know if you are opposed to organizations that have AML requirements\nfrom using the bitcoin blockchain, but if you aren’t, why wouldn’t you\nprefer an open source, open standards based solution to exclusionary,\nproprietary ones?\n\nBIP 70 and BIP 75 are standards for voluntary information exchange between\ncounterparties in a transaction.  This is exactly the kind of thing we want\nstandards for, in my experience.\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/20160621/e821a4e8/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/20160621/e821a4e8/attachment-0001.tiff\u003e"}