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 --]
next prev parent reply other threads:[~2016-06-24 2:26 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 17:33 [bitcoin-dev] Even more proposed BIP extensions to BIP 0070 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
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 [this message]
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='CAJowKgLj=_dK0tcORJk=a-0zwswSF5Cnkgdj--s4Uze-x1m=bA@mail.gmail.com' \
--to=erik@q32.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=justin@netki.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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