rich1.0npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0njumphttps://nostr.ae📅 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>