{"type":"rich","version":"1.0","author_name":"npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","author_url":"https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-06-23\n📝 Original message:AML/KYC is a *side-effect *of a some very important features of BIP0075.\n\nFeatures that have nothing to do with public names for wallet seeds,\nand moniker *consistency *should be scrapped.\n\nBIP 75 formalises what someone could do today with a bunch of PGP emails\nback and forth.\n\nI create a public key, and I exchange it via QR code with you.   From then\non, You can initiate invoice requests with me, knowing my moniker is the\nsame as it was the last time.   I publish this key to a server (via DNSSEC)\nso anyone can obtain it.   Sounds exactly like PGP.\n\nIdentity in BIP 75 is merely \"moniker consistency\".  Nothing says that\nidentity has to be \"real\"... only publicly verifiably consistent and\naccessible.  This consistency and the ability to have public names for both\nmerchants and users are the important features of BIP 075.\n\nOther features linking monikers to real-world identity should be surgically\nremoved from the standard.\n\n- Users need to be able to send Bitcoin to an address without MITM attacks\nduring the address exchange.\n\n- Merchants need to be able to supply memorable names linked to internet\nservices, like web servers and email addresses.\n\n- Merchants and users both need to be able to initiate transaction\noff-chain, with a workflow that allows things like rejection, subscription,\netc.\n\n\n\nOn Thu, Jun 23, 2016 at 6:56 AM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e On Tue, Jun 21, 2016 at 05:14:31PM -0700, Justin Newton wrote:\n\u003e \u003e On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev \u003c\n\u003e \u003e Hi Peter,\n\u003e \u003e    Certainly AML/KYC compliance is one of the use cases that BIP 75 and\n\u003e our\n\u003e \u003e certificates can support.  As a quick summary,\n\u003e \u003e\n\u003e \u003e There are individuals and entities that would like to buy, sell, and use\n\u003e \u003e bitcoin, and other public blockchains, but that have compliance\n\u003e \u003e requirements that they need to meet before they can do so.  Similarly,\n\u003e \u003e companies and entrepreneurs in the space suffer under the potential\n\u003e threat\n\u003e \u003e of fines, or in extreme cases, jail time, also for not meeting AML or\n\u003e \u003e sanctions list compliance.  We wanted to build tools that allowed\n\u003e \u003e entrepreneurs to breathe easy, while at the same time allow more people\n\u003e and\n\u003e \u003e companies to enter the ecosystem.  We also believe that the solution we\n\u003e are\n\u003e \u003e using has the characteristics that you want in such a solution, for\n\u003e example:\n\u003e \u003e\n\u003e \u003e 1\u003e Only the counterparties (and possibly their service providers in the\n\u003e \u003e case of hosted services) in a transaction can see the identity data,\n\u003e \u003e protecting user privacy.\n\u003e \u003e\n\u003e \u003e 2\u003e The counterparties themselves (and possibly their service providers in\n\u003e \u003e the case of hosted services) decide whether identity information is\n\u003e \u003e required for any given transaction.\n\u003e \u003e\n\u003e \u003e 3\u003e No trace is left on the blockchain or anywhere else (other than with\n\u003e the\n\u003e \u003e counterparties) that identity information was even exchanged, protecting\n\u003e \u003e fungibility\n\u003e \u003e\n\u003e \u003e 4\u003e The solution is based on open source and open standards, allowing open\n\u003e \u003e permissionless innovation, versus parties building closed networks based\n\u003e on\n\u003e \u003e closed standards.  The very fact that this solution went through the BIP\n\u003e \u003e process and was adapted based on feedback is an example of how this is\n\u003e \u003e better for users than the inevitable closed solution that would arise if\n\u003e \u003e the open source, community vetted version didn’t already exist.\n\u003e \u003e\n\u003e \u003e I don’t know if you are opposed to organizations that have AML\n\u003e requirements\n\u003e \u003e from using the bitcoin blockchain, but if you aren’t, why wouldn’t you\n\u003e \u003e prefer an open source, open standards based solution to exclusionary,\n\u003e \u003e proprietary ones?\n\u003e\n\u003e In some (most?) countries, it is illegal to offer telecoms services without\n\u003e wiretap facilities. Does that mean Tor builds into its software \"open\n\u003e source\"\n\u003e \"open standards\" wiretapping functionality? No. And interestingly, people\n\u003e trying to add support for that stuff is actually a thing that keeps\n\u003e happening\n\u003e in the Tor community...\n\u003e\n\u003e In any case, I'd strongly argue that we remove BIP75 from the bips\n\u003e repository,\n\u003e and boycott wallets that implement it. It's bad strategy for Bitcoin\n\u003e developers\n\u003e to willingly participate in AML/KYC, just the same way as it's bad for Tor\n\u003e to\n\u003e add wiretapping functionality, and W3C to support DRM tech. The minor\n\u003e tactical\n\u003e wins you'll get our of this aren't worth it.\n\u003e\n\u003e --\n\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/07cec89c/attachment.html\u003e"}