<unnamed>

Public Key

npub19gq8ya0cwzxc2l3lcefrmtg0e0judfdp75cyxdfq2wssfzpckrts74xcws

Profile Code

nprofile1qqsz5qrjwhu8prv90cluv53a458uhewx5ksl2vzrx5s98ggy3qutp4cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsz9gy9g

Publishing to

nostr.wine

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:51:25 UTC

- reply

📅 Original date posted:2016-06-23
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/cc872bf8/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/cc872bf8/attachment-0001.tiff>

2023-06-07 17:51:24 UTC

- reply

📅 Original date posted:2016-06-23
📝 Original message: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?
--
Justin W. Newton
Founder/CEO
Netki, Inc.
justin at netki.com
+1.818.261.4248
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160623/30ac6899/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/30ac6899/attachment-0001.tiff>

2023-06-07 17:51:21 UTC

- reply

📅 Original date posted:2016-06-21
📝 Original message:On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Jun 20, 2016 at 05:33:32PM +0000, Erik Aronesty via bitcoin-dev
> wrote:
>
> > - missing an optional client supplied identification
>
> Note that "client supplied identification" is being pushed for AML/KYC
> compliance, e.g. Netki's AML/KYC compliance product:
>
>
> http://www.coindesk.com/blockchain-identity-company-netki-launch-ssl-certificate-blockchain/
>
> This is an extremely undesirable feature to be baking into standards given
> it's
> negative impact on fungibility and privacy; we should not be adopting
> standards
> with AML/KYC support, for much the same reasons that the W3C should not be
> standardizing DRM.
>
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?
BIP 70 and BIP 75 are standards for voluntary information exchange between
counterparties in a transaction. This is exactly the kind of thing we want
standards for, in my experience.
--
Justin W. Newton
Founder/CEO
Netki, Inc.
justin at netki.com
+1.818.261.4248
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160621/e821a4e8/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/20160621/e821a4e8/attachment-0001.tiff>