Justin Newton [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-14 to 2017-12-01
💬 Posted a total of 14 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 20:08:01

- reply

📅 Original date posted:2017-11-30
📝 Original message:https://www.walletnames.com
Based on a standard that can support blockchain based or traditional ICANN
DNS.
On Fri, Dec 1, 2017 at 6:20 AM, mandar mulherkar via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> I am new, so apologies if this has been asked before.
>
> Here are a few questions to start with -
>
> I was wondering in terms of mass adoption, instead of long wallet
> addresses, maybe there should be a DNS-like decentralized mapping service
> to provide a user at crypto address?
>
> This address translation can happen with confirmations from the network.
> So instead of providing a long string, or a QR code that needs an app, you
> simply type in a human readable address, and the wallet software converts
> it to a wallet address.
>
> Please let me know where I can research this more - if there already is
> literature about this somewhere.
>
> thanks!
>
>
> _______________________________________________
> 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@ <justin at netki.com>netki.com <justin at netki.com>
*+1.818.927.2646*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171201/8ec413e8/attachment.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/20171201/8ec413e8/attachment.tiff>

2023-06-07 19:52:30

- reply

📅 Original date posted:2016-08-08
📝 Original message:Daniel,
Thanks for proposing this. I think this could have some useful use
cases as you state. I was wondering what you would think to adding some
additional tones to optionally denote an amount (in satoshis?).
(FYI, actual link is here: https://github.com/Dako300/BIP )
Justin
On Mon, Aug 8, 2016 at 2:22 PM, Daniel Hoffman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is my BIP idea: a fast, robust, and standardized for representing
> Bitcoin addresses over audio. It takes the binary representation of the
> Bitcoin address (little endian), chops that up into 4 or 2 bit chunks
> (depending on type, 2 bit only for low quality audio like american
> telephone lines), and generates a tone based upon that value. This started
> because I wanted an easy way to donate to podcasts that I listen to, and
> having a Shazam-esque app (or a media player with this capability) that
> gives me an address automatically would be wonderful for both the consumer
> and producer. Comes with error correction built into the protocol
>
> You can see the full specification of the BIP on my GitHub page (
> https://github.com/Dako300/BIP-0153).
>
> _______________________________________________
> 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/20160808/4ea7b965/attachment.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/20160808/4ea7b965/attachment.tiff>

2023-06-07 19:51:25

- 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 19:51:24

- 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 19:51:21

- 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>

2023-06-07 17:42:09

- reply

📅 Original date posted:2015-07-18
📝 Original message:On Sat, Jul 18, 2015 at 6:29 AM, Thomas Voegtlin via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Le 14/07/2015 19:29, Justin Newton a écrit :
>
>
> Sorry to answer late, and thanks for the clarification. After talking
> with you, I believe that it will not be difficult to agree on a common
> standard, that gives maximum freedom to everyone.
100% agreed.
>
> I also believe that it is in Netki's interest to convey the message that
> they are actively promoting an open standard, and not pushing a private
> solution. For this reason, and assuming that the future standard
> satisfies you fully, will you mind if that standard carries a neutral
> name (such as "OpenAlias v2", or "BIP xx"), instead of being named after
> your company? I reckon that is purely a PR issue.
To be clear, the current name of the service is Wallet Name Service,
Netki has tended to be tagged to it as people are associating the
service with us. We also intend to offer more services than just
this, so its actually not really good for us to think of Netki as the
service name. I have no issues with a neutral name for the lookup
standard.
>
>
> > To break it down briefly, we have an open lookup standard based on
> > both the namecoin blockchain as well as traditional DNSSEC. (You can
> > choose your own adventure of using namecoin based names or traditional
> > ICANN names).
>
> I would rather not make Namecoin part of the standard, because .bit
> records cannot be verified easily by lightweight/spv wallets; they would
> need a copy of the Namecoin blockchain for that.
You are the second person to raise this. Clearly this is an item that
requires some discussion before anything is decided for sure. We had
gone this direction (and I assume Riccardo did as well) to provide a
censor resistant option as well as one that would be low cost for
individuals to be able register their own names. This also allows for
lookups that never leave the local network. The trade off there for
mobile wallets was one I feel we failed to properly consider.
<SNIPPING AREAS OF APPARENT AGREEMENT>
>
> > 3> We use a 2 tier lookup format. The first lookup returns a list of
> > currencies or payment types supported by the Wallet Name. The second
> > lookup goes to a record specific to that currency type to get the
> > address to go to. We believe this to be a more scalable solution in a
> > world where someone can have both multiple digital currency types, but
> > then also multiple types of colored coins, and wants a simple way to
> > share a single name for all of those different addresses. This allows
> > the wallet to do the work behind the scene of choosing the currency it
> > wants to send, and automatically getting back the right address to
> > send to, without the user having to do anything different.
> >
>
> This seems to be a major difference, and I believe it makes sense to do
> it the way you describe. Does that solution fully replace the tags used
> in OpenAlias, or does it make sense to combine these two systems?
I think combining formats to use both the two level lookups and tags
could have value. Tags could include information like versioning, as
well as whether what is being returned is an address, URL for further
lookup, or other piece of information.
<SNIPPING MORE AGREEMENT>
>
> > I'd love to talk here or offline about merging standards going
> > forward. As an FYI, Verisign has also delivered a standard to the
> > IETF using DNSSEC to pass payment information here:
> > https://tools.ietf.org/html/draft-wiley-paymentassoc-00 We have
> > started discussions with them about merging standards as well.
> >
>
> That is nice, but may be out of scope here. Isn't there a risk that
> involving the IETF would make the process a lot slower? Of course it
> would be great, but maybe we should try to reach consensus at our level
> first (the bitcoin level), before trying to merge with them.
I concur with this approach. I think it makes sense for us to stay in
contact and communication with the IETF side with the hope of ending
up with something that is, in the end the same, or at least
compatible. I also agree that we shouldn't wait on the IETF to move
ahead ourselves, more stay in communication with them so that we don't
end up accidentally going in opposite directions, and also so we can
learn best practices from each other along the way.
As you can see, this has been our approach up until now where we have
gone ahead and built and expanded our "standard" based on our
discussions and integrations with other industry participants.
Thanks for the feedback!
Justin
--
Justin W. Newton
Founder/CEO
NetKi, Inc.
justin at netki.com
+1.818.261.4248