Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

From: Erik Aronesty <erik@q32•com>
To: Justin Newton <justin@netki•com>,
	 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 22:26:52 -0400	[thread overview]
Message-ID: <CAJowKgLj=_dK0tcORJk=a-0zwswSF5Cnkgdj--s4Uze-x1m=bA@mail.gmail.com> (raw)
In-Reply-To: <CABqynxKmqrUhFsGFp0N6yGpHcbE5NgxdKCPWvTAXTkXhHs6z_w@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 5742 bytes --]

Sometimes I think there's concerted resistance to making Bitcoin usable for
the average person.   Clearly the primary purpose of BIP0075 is to enshrine
a DNSSEC protocol for giving wallet addresses memorable names.

On Thu, Jun 23, 2016 at 6:44 PM, Justin Newton via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Hi there,
>    For users who don’t wish a service provider to be able to see their
> information, even ephemerally, and they would like to exchange information
> via BIP75, they can use a software wallet, such as a breadwallet or others,
> and that data will only exist on their phone, and the phone of their
> counterparty (assuming the counterparty also chose to exchange info, and
> was running on a software wallet).
>
> In this way, we allow users to exchange data as they choose, without
> having the risk that a service provider be asked for that data.
>
> If a user chooses to use a hosted platform, and also to store their
> identity data there, I do agree it could be subject to a subpoena, the same
> as when they host their email, and other services.
>
> Finally, they could choose not to use BIP75 at all, and no one would know
> whether they did or didn’t (other than their counterparts) as we don’t
> leave any residue on the blockchain, or anywhere else in the public eye.
>
> We believe that this solution, due in part to its narrow data aperture, is
> the best solution available to the problem we are solving.  We are eager to
> engage in any discussions about how to improve the proposed solution, with
> an eye to fungibility, privacy, and usability.
>
> That said, there is a real need for people to know who they are
> transacting with for usability reasons, for fraud reduction, and also of
> regulatory reasons for some players.  To NOT solve it with a carefully
> crafted standard means that it is more likely to be solved with back room,
> quick and dirty solutions that are not available for community review and
> feedback.
>
> Thanks!
>
> Justin
>
>
>
>
>
>
> On Thu, Jun 23, 2016 at 2:31 PM, Police Terror via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> In England under RIPA 2000 legislation, it's irrelevant whether you have
>> the data or not. If the authorities compel you to hand over that
>> information, and it is within your means to obtain it then you are
>> obliged to do so under threat of criminal offense.
>>
>> So any mechanism whereby data could be collected from Bitcoin users,
>> whether it's stored ephemerally or not, if the police have reasonable
>> suspicion to think it exists then they can compel all parties to work to
>> get them the data they require.
>>
>> If the mechanism flat out does not exist, that is miles better than
>> could exist. Deniability is not a defense when served with a police
>> notice for disclosing data.
>>
>> You have to think not only about the end result, but also about how
>> these mechanisms can be used for intimidating users or leveraging
>> technologies.
>>
>> Justin Newton via bitcoin-dev:
>> > On Thu, Jun 23, 2016 at 1:46 PM, s7r via bitcoin-dev <
>> > bitcoin-dev@lists•linuxfoundation.org> wrote:
>> >
>> >>
>> >>
>> >>
>> >> Any kind of built-in AML/KYC tools in Bitcoin is bad, and might draw
>> >> expectations from _all_ users from authorities. Companies or
>> individuals
>> >> who want and/or need AML/KYC can find ways and do it at their side
>> >> isolated from the entire network, and the solutions shouldn't come from
>> >> upstream. AML/KYC/<insert other regulation here> differ from country to
>> >> country and will be hard to implement in a global consensus network
>> even
>> >> if it would be worth it.
>> >>
>> >>
>> > This was precisely our thinking as well.
>> >
>> > This is actually exactly why BIP 75 was designed the way that it was.
>> Any
>> > (voluntary) identity exchange is done at the application level, on an
>> > encrypted https (or other) connection between the sender and receiver.
>> > Identity data is not passed through or stored on the blockchain, and
>> there
>> > is actually no mark left on the blockchain that identity was even
>> exchanged
>> > on that transaction.
>> >
>> > The only people who know identity info was exchanged, or what the
>> identity
>> > was is the counterparties in the transaction, and depending on
>> > implementation, their service provider.  (At a high level, many software
>> > based wallet providers wouldn’t have any visibility into identity info,
>> > where many hosted services would, for example)
>> >
>> > We did this to protect user privacy as well as fungibility.
>> >
>> > We are allowing the people who want or need to exchange identtity info
>> > (either self signed or 3rd party validated) the option to exchange it,
>> in a
>> > standards based way, directly between peers, without touching the
>> > blockchain or network itself.
>> >
>> > Is this more clear?
>> >
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists•linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
>
> Justin W. Newton
> Founder/CEO
> Netki, Inc.
>
> justin@netki•com
> +1.818.261.4248
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #1.2: Type: text/html, Size: 8764 bytes --]

[-- Attachment #2: PastedGraphic-1.tiff --]
[-- Type: image/tiff, Size: 10972 bytes --]