{"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-21\n📝 Original message:On Mon, Jun 20, 2016 at 05:33:32PM +0000, Erik Aronesty via bitcoin-dev wrote:\n\u003e BIP 0070 has been a a moderate success, however, IMO:\n\u003e \n\u003e - protocol buffers are inappropriate since ease of use and extensibility is\n\u003e desired over the minor gains of efficiency in this protocol.  Not too late\n\u003e to support JSON messages as the standard going forward\n\u003e \n\u003e - problematic reliance on merchant-supplied https (X509) as the sole form\n\u003e of mechant identification.   alternate schemes (dnssec/netki), pgp and\n\u003e possibly keybase seem like good ideas.   personally, i like keybase, since\n\u003e there is no reliance on the existing domain-name system (you can sell with\n\u003e a github id, for example)\n\u003e \n\u003e - missing an optional client supplied identification\n\nNote that \"client supplied identification\" is being pushed for AML/KYC\ncompliance, e.g. Netki's AML/KYC compliance product:\n\nhttp://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/\n\nThis is an extremely undesirable feature to be baking into standards given it's\nnegative impact on fungibility and privacy; we should not be adopting standards\nwith AML/KYC support, for much the same reasons that the W3C should not be\nstandardizing DRM.\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/20160621/5e89e377/attachment.sig\u003e"}