From: Erik Aronesty <erik@q32•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
Date: Thu, 23 Jun 2016 09:03:36 -0400 [thread overview]
Message-ID: <CAJowKgJ8YQ9V891phx1qzJvFD3iWyPVU5iZ1w2LryALWAK5aHQ@mail.gmail.com> (raw)
In-Reply-To: <20160623105632.GB19241@fedora-21-dvm>
[-- Attachment #1: Type: text/plain, Size: 4534 bytes --]
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 <pete@petertodd•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,
> > 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?
>
> In some (most?) countries, it is illegal to offer telecoms services 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
> 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 Tor
> 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
>
[-- Attachment #2: Type: text/html, Size: 5561 bytes --]
next prev parent reply other threads:[~2016-06-23 13:03 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
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 [this message]
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=CAJowKgJ8YQ9V891phx1qzJvFD3iWyPVU5iZ1w2LryALWAK5aHQ@mail.gmail.com \
--to=erik@q32$(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