Peter Todd [ARCHIVE] on Nostr: š Original date posted:2016-06-21 š Original message:On Mon, Jun 20, 2016 at ...
š
Original date posted:2016-06-21
š Original message:On Mon, Jun 20, 2016 at 05:33:32PM +0000, Erik Aronesty via bitcoin-dev wrote:
> BIP 0070 has been a a moderate success, however, IMO:
>
> - protocol buffers are inappropriate since ease of use and extensibility is
> desired over the minor gains of efficiency in this protocol. Not too late
> to support JSON messages as the standard going forward
>
> - problematic reliance on merchant-supplied https (X509) as the sole form
> of mechant identification. alternate schemes (dnssec/netki), pgp and
> possibly keybase seem like good ideas. personally, i like keybase, since
> there is no reliance on the existing domain-name system (you can sell with
> a github id, for example)
>
> - 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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/5e89e377/attachment.sig>
š Original message:On Mon, Jun 20, 2016 at 05:33:32PM +0000, Erik Aronesty via bitcoin-dev wrote:
> BIP 0070 has been a a moderate success, however, IMO:
>
> - protocol buffers are inappropriate since ease of use and extensibility is
> desired over the minor gains of efficiency in this protocol. Not too late
> to support JSON messages as the standard going forward
>
> - problematic reliance on merchant-supplied https (X509) as the sole form
> of mechant identification. alternate schemes (dnssec/netki), pgp and
> possibly keybase seem like good ideas. personally, i like keybase, since
> there is no reliance on the existing domain-name system (you can sell with
> a github id, for example)
>
> - 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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/5e89e377/attachment.sig>