From: Justin Newton <justin@netki•com>
To: Peter Todd <pete@petertodd•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
Date: Tue, 21 Jun 2016 17:14:31 -0700 [thread overview]
Message-ID: <CABqynxJCiXL0djx+xt9i=HJqC=0=5sZ9ecL7k1_a_XHiJ8qibw@mail.gmail.com> (raw)
In-Reply-To: <20160621221347.GC10196@fedora-21-dvm>
[-- Attachment #1.1: Type: text/plain, Size: 3057 bytes --]
On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@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@netki•com
+1.818.261.4248
[-- Attachment #1.2: Type: text/html, Size: 5057 bytes --]
[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]
next prev parent reply other threads:[~2016-06-22 0:14 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 17:33 Erik Aronesty
2016-06-21 9:43 ` Andreas Schildbach
2016-06-21 17:09 ` Erik Aronesty
2016-06-21 19:50 ` Andy Schroder
2016-06-21 20:44 ` Luke Dashjr
2016-06-21 21:42 ` Erik Aronesty
2016-06-22 0:36 ` Luke Dashjr
2016-06-21 22:10 ` Peter Todd
2016-06-21 22:19 ` Peter Todd
2016-06-21 20:56 ` James MacWhyte
2016-06-21 21:17 ` Matt David
2016-06-21 22:13 ` Peter Todd
2016-06-21 22:50 ` James MacWhyte
2016-06-21 23:02 ` Peter Todd
2016-06-22 0:14 ` Justin Newton [this message]
2016-06-23 10:56 ` Peter Todd
2016-06-23 11:30 ` Pieter Wuille
2016-06-23 11:39 ` Peter Todd
2016-06-23 12:01 ` Pieter Wuille
2016-06-23 12:10 ` Peter Todd
2016-06-23 12:16 ` Pieter Wuille
2016-06-23 12:43 ` Peter Todd
2016-06-23 13:03 ` Erik Aronesty
2016-06-23 16:58 ` Aaron Voisine
2016-06-23 20:46 ` s7r
2016-06-23 21:07 ` Justin Newton
2016-06-23 21:31 ` Police Terror
2016-06-23 22:44 ` Justin Newton
2016-06-24 2:26 ` Erik Aronesty
2016-06-24 5:27 ` James MacWhyte
2016-06-22 7:57 ` Thomas Voegtlin
2016-06-22 14:25 ` Erik Aronesty
2016-06-22 15:12 ` Andy Schroder
2016-06-22 15:30 ` Erik Aronesty
2016-06-22 16:20 ` Andy Schroder
2016-06-22 17:07 ` Erik Aronesty
2016-06-22 20:11 ` James MacWhyte
2016-06-22 20:37 ` Erik Aronesty
2016-06-23 11:50 ` Andreas Schildbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABqynxJCiXL0djx+xt9i=HJqC=0=5sZ9ecL7k1_a_XHiJ8qibw@mail.gmail.com' \
--to=justin@netki$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox