rich1.0npub19gq8ya0cwzxc2l3lcefrmtg0e0judfdp75cyxdfq2wssfzpckrts74xcwshttps://nostr.ae/npub19gq8ya0cwzxc2l3lcefrmtg0e0judfdp75cyxdfq2wssfzpckrts74xcwsnjumphttps://nostr.ae📅 Original date posted:2016-06-21 📝 Original message:On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > On Mon, Jun 20, 2016 at 05:33:32PM +0000, Erik Aronesty via bitcoin-dev > wrote: > > > - missing an optional client supplied identification > > Note that "client supplied identification" is being pushed for AML/KYC > compliance, e.g. Netki's AML/KYC compliance product: > > > http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/ > > This is an extremely undesirable feature to be baking into standards given > it's > negative impact on fungibility and privacy; we should not be adopting > standards > with AML/KYC support, for much the same reasons that the W3C should not be > standardizing DRM. > Hi Peter, Certainly AML/KYC compliance is one of the use cases that BIP 75 and our certificates can support. As a quick summary, There are individuals and entities that would like to buy, sell, and use bitcoin, and other public blockchains, but that have compliance requirements that they need to meet before they can do so. Similarly, companies and entrepreneurs in the space suffer under the potential threat of fines, or in extreme cases, jail time, also for not meeting AML or sanctions list compliance. We wanted to build tools that allowed entrepreneurs to breathe easy, while at the same time allow more people and companies to enter the ecosystem. We also believe that the solution we are using has the characteristics that you want in such a solution, for example: 1> Only the counterparties (and possibly their service providers in the case of hosted services) in a transaction can see the identity data, protecting user privacy. 2> The counterparties themselves (and possibly their service providers in the case of hosted services) decide whether identity information is required for any given transaction. 3> No trace is left on the blockchain or anywhere else (other than with the counterparties) that identity information was even exchanged, protecting fungibility 4> The solution is based on open source and open standards, allowing open permissionless innovation, versus parties building closed networks based on closed standards. The very fact that this solution went through the BIP process and was adapted based on feedback is an example of how this is better for users than the inevitable closed solution that would arise if the open source, community vetted version didn’t already exist. I don’t know if you are opposed to organizations that have AML requirements from using the bitcoin blockchain, but if you aren’t, why wouldn’t you prefer an open source, open standards based solution to exclusionary, proprietary ones? BIP 70 and BIP 75 are standards for voluntary information exchange between counterparties in a transaction. This is exactly the kind of thing we want standards for, in my experience. -- Justin W. Newton Founder/CEO Netki, Inc. justin at netki.com +1.818.261.4248 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/e821a4e8/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-1.tiff Type: image/tiff Size: 10972 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/e821a4e8/attachment-0001.tiff>