Erik Aronesty [ARCHIVE] on Nostr: đź“… Original date posted:2016-06-23 đź“ť Original message:Sometimes I think there's ...
đź“… Original date posted:2016-06-23
đź“ť Original message: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 at 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 at 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 at 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 at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
>
> Justin W. Newton
> Founder/CEO
> Netki, Inc.
>
> justin at netki.com
> +1.818.261.4248
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/f11d74c6/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/f11d74c6/attachment-0001.tiff>;
đź“ť Original message: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 at 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 at 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 at 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 at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
>
> Justin W. Newton
> Founder/CEO
> Netki, Inc.
>
> justin at netki.com
> +1.818.261.4248
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/f11d74c6/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 10972 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/f11d74c6/attachment-0001.tiff>;