Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AE5CA884 for ; Thu, 23 Jun 2016 13:03:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.161.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB7D418D for ; Thu, 23 Jun 2016 13:03:38 +0000 (UTC) Received: by mail-yw0-f174.google.com with SMTP id l125so69851294ywb.2 for ; Thu, 23 Jun 2016 06:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hDU42FHmSu4v99sQz505QxUCURP0A0pMihenZk8oazA=; b=Y9nOhIhcJRsvMnozim10Fpk5FM9VB+nRyVeWZ6VmsAn35IlPpGTy0tjW41NGOBVuPS Mx1oFTnrX7eU2pviTrdBh6lqDv2iWqQVeeGQ53TT+sxghBr96qL2FbrTRtfVlHkFukgr 59LxBkkfFlFm89k6aBbxeK6ldsMQgFHJin4riNStWIJ9hPCMzpjR6ogBoB6BFSf4SaiB jeD1Vz3a4hHx0SJENOv4vD3Gz1YRkA+gfWUZVIDXdR1J+Qfxdo4+gbuRZD00aCrmtVJP MTuCQLvmbbFewe4rGpCt1vzo+b/g/79ETlHWOu/aAt02b5Rk1/cbwPUYFLF/HfXyt82i qpMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hDU42FHmSu4v99sQz505QxUCURP0A0pMihenZk8oazA=; b=eGRYcK38gb0YG3aqYhphDF1POlWIxv6HbFioPT2lItCFO6duCpaDTP0kl/6CW1Lt/R gzMfodxikR7d3VceCoSZUmFLzvy2/Uah+0Lfa1wD/6jC6Vc4YN+sNhhgblj+ftg4Bop6 iJRumIifcBVs8mT9eYde8LiFM0N6nfwJZvXduALzs4gMB4wFqohy4b1u4PZcwPAg/vCL iCx366pEuZpdWg/tTbobifNfHcMgNbHpveRqAVWn3NkG+ZjIjIbD5zaeC1zYN6xGJ23E 3iD+FoQ5605cNyen77Pb1ypTUWpJdMwu5XjG3yMmSkZkBlYupWZ/Bq07u/sweKh2RmD3 ktwg== X-Gm-Message-State: ALyK8tK9Toqh5YoVy2bLTy818PMQf4475l1UV/t4lPE6/SOUgeYNmNGTiIdpOiFN+mx7Uz4/27MCqqtL9z5N7A== X-Received: by 10.37.50.150 with SMTP id y144mr18126858yby.17.1466687017808; Thu, 23 Jun 2016 06:03:37 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.37.72.68 with HTTP; Thu, 23 Jun 2016 06:03:36 -0700 (PDT) In-Reply-To: <20160623105632.GB19241@fedora-21-dvm> References: <20160621221347.GC10196@fedora-21-dvm> <20160623105632.GB19241@fedora-21-dvm> From: Erik Aronesty Date: Thu, 23 Jun 2016 09:03:36 -0400 X-Google-Sender-Auth: Qn7F3bW1AKsxJmNwLww7QHS2U7k Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary=001a1146cb90b17c070535f1ae39 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 13:03:39 -0000 --001a1146cb90b17c070535f1ae39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable AML/KYC is a *side-effect *of a some very important features of BIP0075. Features that have nothing to do with public names for wallet seeds, and moniker *consistency *should be scrapped. BIP 75 formalises what someone could do today with a bunch of PGP emails back and forth. I create a public key, and I exchange it via QR code with you. From then on, You can initiate invoice requests with me, knowing my moniker is the same as it was the last time. I publish this key to a server (via DNSSEC) so anyone can obtain it. Sounds exactly like PGP. Identity in BIP 75 is merely "moniker consistency". Nothing says that identity has to be "real"... only publicly verifiably consistent and accessible. This consistency and the ability to have public names for both merchants and users are the important features of BIP 075. Other features linking monikers to real-world identity should be surgically removed from the standard. - Users need to be able to send Bitcoin to an address without MITM attacks during the address exchange. - Merchants need to be able to supply memorable names linked to internet services, like web servers and email addresses. - Merchants and users both need to be able to initiate transaction off-chain, with a workflow that allows things like rejection, subscription, etc. On Thu, Jun 23, 2016 at 6:56 AM, Peter Todd wrote: > On Tue, Jun 21, 2016 at 05:14:31PM -0700, Justin Newton wrote: > > On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev < > > 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 us= e > > 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, protectin= g > > fungibility > > > > 4> The solution is based on open source and open standards, allowing op= en > > permissionless innovation, versus parties building closed networks base= d > on > > closed standards. The very fact that this solution went through the BI= P > > 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 i= f > > the open source, community vetted version didn=E2=80=99t already exist. > > > > I don=E2=80=99t know if you are opposed to organizations that have AML > requirements > > from using the bitcoin blockchain, but if you aren=E2=80=99t, why would= n=E2=80=99t you > > prefer an open source, open standards based solution to exclusionary, > > proprietary ones? > > In some (most?) countries, it is illegal to offer telecoms services witho= ut > wiretap facilities. Does that mean Tor builds into its software "open > source" > "open standards" wiretapping functionality? No. And interestingly, people > trying to add support for that stuff is actually a thing that keeps > happening > in the Tor community... > > In any case, I'd strongly argue that we remove BIP75 from the bips > repository, > and boycott wallets that implement it. It's bad strategy for Bitcoin > developers > to willingly participate in AML/KYC, just the same way as it's bad for To= r > to > add wiretapping functionality, and W3C to support DRM tech. The minor > tactical > wins you'll get our of this aren't worth it. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > --001a1146cb90b17c070535f1ae39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
AML/KYC is a side-effect of a some very important f= eatures of BIP0075. =C2=A0=C2=A0

Features that have noth= ing to do with public names for wallet seeds, and=C2=A0moniker=C2=A0cons= istency=C2=A0should be scrapped.

BIP 75 formalis= es what someone could do today with a bunch of PGP emails back and forth.

I create a public key, and I exchange it via QR code = with you. =C2=A0 From then on, You can initiate invoice requests with me, k= nowing my moniker is the same as it was the last time. =C2=A0 I publish thi= s key to a server (via DNSSEC) so anyone can obtain it. =C2=A0 Sounds exact= ly like PGP.

Identity in BIP 75 is merely "mo= niker consistency".=C2=A0 Nothing says that identity has to be "r= eal"... only=C2=A0publicly verifiably=C2=A0consistent and accessible.= =C2=A0 This consistency and the ability to have public names for both merch= ants and users are the important features of BIP 075. =C2=A0=C2=A0

Other features linking monikers to real-world identity sho= uld be surgically removed from the standard.

- Use= rs need to be able to send Bitcoin to an address without MITM attacks durin= g the address exchange. =C2=A0=C2=A0

- Merchants n= eed to be able to supply memorable names linked to internet services, like = web servers and email addresses. =C2=A0

- Merchants and u= sers both need to be able to initiate transaction off-chain, with a workflo= w that allows things like rejection, subscription, etc.



On Thu, Jun 23, 2016 at 6:56 AM, Peter Todd <pete@petert= odd.org> wrote:
On Tue, Jun 21, 2016 at 05:14:31PM -0700, Justin Newton wrote:
> On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev <
> Hi Peter,
>=C2=A0 =C2=A0 Certainly AML/KYC compliance is one of the use cases that= BIP 75 and our
> certificates can support.=C2=A0 As a quick summary,
>
> There are individuals and entities that would like to buy, sell, and u= se
> bitcoin, and other public blockchains, but that have compliance
> requirements that they need to meet before they can do so.=C2=A0 Simil= arly,
> companies and entrepreneurs in the space suffer under the potential th= reat
> of fines, or in extreme cases, jail time, also for not meeting AML or<= br> > sanctions list compliance.=C2=A0 We wanted to build tools that allowed=
> entrepreneurs to breathe easy, while at the same time allow more peopl= e and
> companies to enter the ecosystem.=C2=A0 We also believe that the solut= ion we are
> using has the characteristics that you want in such a solution, for ex= ample:
>
> 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 provid= ers 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, protecti= ng
> fungibility
>
> 4> The solution is based on open source and open standards, allowin= g open
> permissionless innovation, versus parties building closed networks bas= ed on
> closed standards.=C2=A0 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=E2=80=99t already exist= .
>
> I don=E2=80=99t know if you are opposed to organizations that have AML= requirements
> from using the bitcoin blockchain, but if you aren=E2=80=99t, why woul= dn=E2=80=99t you
> prefer an open source, open standards based solution to exclusionary,<= br> > proprietary ones?

In some (most?) countries, it is illegal to offer telecoms serv= ices without
wiretap facilities. Does that mean Tor builds into its software "open = source"
"open standards" wiretapping functionality? No. And interestingly= , people
trying to add support for that stuff is actually a thing that keeps happeni= ng
in the Tor community...

In any case, I'd strongly argue that we remove BIP75 from the bips repo= sitory,
and boycott wallets that implement it. It's bad strategy for Bitcoin de= velopers
to willingly participate in AML/KYC, just the same way as it's bad for = Tor to
add wiretapping functionality, and W3C to support DRM tech. The minor tacti= cal
wins you'll get our of this aren't worth it.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org

--001a1146cb90b17c070535f1ae39--