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 18: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 17: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 17: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 17:49:51

- reply

📅 Original date posted:2016-03-11
📝 Original message:I think we would be open to either leaving them in, or doing a separate
BIP. What do others think? I’d prefer to keep them together if the
changes are non-controversial just to cut down on #of BIP’s, but thats not
a strong preference.
On Fri, Mar 11, 2016 at 3:54 AM, Andreas Schildbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think it's a bad idea to pollute the original idea of this BIP with
> other extensions. Other extensions should go to separate BIPs,
> especially since methods to clarify the fee have nothing to do with
> secure and authenticated bi-directional BIP70 communication.
>
>
> On 03/10/2016 10:43 PM, James MacWhyte via bitcoin-dev wrote:
> > Hi everyone,
> >
> > Our BIP (officially proposed on March 1) has tentatively been assigned
> > number 75. Also, the title has been changed to "Out of Band Address
> > Exchange using Payment Protocol Encryption" to be more accurate.
> >
> > We thought it would be good to take this opportunity to add some
> > optional fields to the BIP70 paymentDetails message. The new fields are:
> > subtractable fee (give permission to the sender to use some of the
> > requested amount towards the transaction fee), fee per kb (the minimum
> > fee required to be accepted as zeroconf), and replace by fee (whether or
> > not a transaction with the RBF flag will be accepted with zeroconf). I
> > know it doesn't make much sense for merchants to accept RBF with
> > zeroconf, so that last one might be used more to explicitly refuse RBF
> > transactions (and allow the automation of choosing a setting based on
> > who you are transacting with).
> >
> > I see BIP75 as a general modernization of BIP70, so I think it should be
> > fine to include these extensions in the new BIP, even though these
> > fields are not specific to the features we are proposing. Please take a
> > look at the relevant section and let me know if anyone has any concerns:
> >
> https://github.com/techguy613/bips/blob/master/bip-0075.mediawiki#Extending_BIP70_PaymentDetails
> >
> > The BIP70 extensions page in our fork has also been updated.
> >
> > Thanks!
> >
> > James
> >
> >
> > _______________________________________________
> > 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/20160311/4de2c325/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/20160311/4de2c325/attachment-0001.tiff>

2023-06-07 15:42:14

- reply

📅 Original date posted:2015-07-27
📝 Original message:Thomas,
I think this is interesting and has some good thoughts behind it. For
clarity, are you recommending that the "_oa2" portion of the domain name be
"hidden" as a way to make it easier to delegate just wallet names from a
zone?
On Thu, Jul 23, 2015 at 6:07 AM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Le 23/07/2015 11:48, Thomas Voegtlin via bitcoin-dev a écrit :
> >
> > One benefit of having an intermediate "_wallet" level is to allow zone
> > delegation. Is that the reason for that choice?
> >
>
> Thinking about it, I think that it would be better to separate those two
> operations: on one hand, the listing of TXT records under a name, and on
> the other hand, the possibility to use Zone Delegation.
>
> For example, let us use the "_oa2" name (Openalias version 2) when we
> need to introduce an intermediate level, and "_oa2_keys" for key listing.
>
> Here is an example:
>
> _oa2_keys.sample 3600 IN TXT "btc ltc email fullname"
> _btc.sample 3600 IN TXT "bitcoinaddress"
> _ltc.sample 3600 IN TXT "litecoinaddress"
> _btc.sample 3600 IN TXT "otherbitcoinaddress"
> _email.sample 3600 IN TXT "john.smith at googlemail.com"
> _fullname.sample 3600 IN TXT "John Smith"
>
> Zone Delegation: Let us assume example.com wants to delegate all its
> Bitcoin aliases to Netki. We introduce an intermediate level, with the
> "_oa2" name. In the alias, this string is translated as "@"
>
> john._oa2.example.com <-- will be looked up as john at example.com
> _btc.john._oa2.example.com <-- bitcoin address of john at example.com
>
> _______________________________________________
> 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/20150727/9f2e9f77/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/20150727/9f2e9f77/attachment-0001.tiff>

2023-06-07 15:42:13

- reply

📅 Original date posted:2015-07-16
📝 Original message:[CONTINUED]
>
> Additionally, we just released another open source API server to help
>> with the "other half" of the lookup problem. Its in its infancy, and
>> we are certainly taking feedback on it at this time. It is called
>> Addressimo <https://github.com/netkicorp/addressimo> and will serve
>> unique HD Wallet addresses or Payment Requests for every lookup, thus
>> allowing a user to have a private, secure way to share a Wallet Name
>> that can be used to send them any digital currency.
>>
>
> Oh snap...https://github.com/openalias/openalias-api
>
These are actually vastly different pieces of software, at least from the
description, and a first read of the code. My understanding is the
software you linked to here basically takes the DNS work out of lookups for
people, as we released: https://github.com/netkicorp/wns-api-server Its
our Wallet Name Lookup server.
Addressimo, as I described above, provides a different purpose. Its a way
for service providers, mobile wallet providers or end users to have an
online server that can serve unique wallet addresses ala HD Wallets (BIP32)
or signed Payment Requests (BIP0070). This allows for an easy way to
increase security and privacy by serving a unique address for every
request, and/or sign the address (and other optional data) with an X509
private key to prove ownership of the address in a way independent of and
supplemental to the DNSSEC chain (also can be DANE for yet another layer of
security). It also supports offline signing of the Payment Requests so the
server doesn't have to have access to a private key, or need to be trusted.
>
>
> In any case, I'd much rather we had one effort going forward than
>> multiples, so let's talk!
>>
>
> I agree, and you guys are in an ideal position to change to supporting the
> OpenAlias standard (and enhancing it) without skipping a beat. We would
> definitely appreciate and take your input and efforts, and that would make
> OpenAlias v2 (oa2:) a standard built out in conjunction with Netki.
>
> Not only do you get Electrum support without lifting a finger, but it will
> go a long way to repairing your relationship with the open-source community
> at large, several proponents of which have taken great umbrage at what you
> were previously pushing as a closed-source, centralised system.
>
>
I'm a little confused by these closing statements. Our system has, from
the beginning been open in terms of the fact that anyone could both serve
names or do lookups without ever touching our servers, talking to us, or us
even knowing that they did it or that they even exist. Our system has
NEVER been one where folks were required to use us for any portion of the
service, and from our first beta product launch our open source tools did
all lookups against DNS records and the blockchain, never any proprietary
servers or interfaces on our side.
In terms of the format itself being open, we have already made several
extensions and modifications to it as a result of conversations with
industry participants in order to ensure that what we are building meets
the needs of the community at large. We will gladly continue to do so, it
is how we ensure we are building something everyone needs!
I'd love to know where you got information that we were in some way a
closed and centralized system so that we can have an opportunity to clarify
that misconception.
In terms of finding a common standard, as I said, I am thrilled to have the
conversations, but there are some places, highlighted above, that would
cause me to hesitate to "just implement" the Open Alias standard. I can
also see places where bringing the formats together to one standard could
have strong benefits, for example:
I think formatting the record as a key value pair with versioning has
merit, and would love to move it in to what we are doing (and likely will).
On the other side, I think the two level lookup provides a lot of value at
scale over trying to send back a bunch of text records when only a small
portion of the data is used.
I'd love to hear thoughts from others in the community on mandating DNSSEC
and thoughts on DNSCrypt. I have a strong opinion on both of those but
would love to engage in thoughtful dialogue around what path best suits the
need of the community.
Looking forward to the discussion!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150716/63581188/attachment.html>

2023-06-07 15:42:12

- reply

2023-06-07 15:42:11

- reply

📅 Original date posted:2015-07-16
📝 Original message:I am breaking this into a couple of pieces as my first response has been in
a moderator queue for some time because it is too long.
TL;DR version - Wallet Name Service has always been a decentralized and
distributed service that it no way requires you to ever touch the Netki
infrastructure. We want to work with the community, as we have been from
the beginning, to come up with the best standard possible.
Longer answers inline below.
On Tue, Jul 14, 2015 at 12:07 PM, Riccardo Spagni <ric at spagni.net> wrote:
>
>
>> In terms of comparisons to OpenAlias, I think there are a lot of
>> similarities, but a few differences. First the similarities:
>>
>>
>> 1> We both use DNSSEC.
>>
>> 2> We both have the option of storing the address directly in the DNS
>> record.
>>
>>
>> Differences:
>>
>> 1> We do not use DNSCrypt. I understand why you chose to, but we were
>> concerned about broad interoperability and easy broad distribution of
>> hosting, so decided not to use it. We have other ways of achieving
>> privacy, using HD Wallets and Payment Requests.
>>
>
> And this is the part where you guys look really, really incompetent (and I
> don't mean that in a terribly demeaning way, it's just that you're in a
> space where you want to be a domain expert, not make a series of
> embarrassing and public faux pas).
>
>
> I appreciate the thought :) I think where we differ is on where we
believe the trade offs should be on perceived privacy versus censorship
resistance and centralization.
By having a limited number of proxies people need to go through to easily
implement, be it the 4 you recommend, or 53, you actually have a very
limited number of actors for an authority or hacker to go to in order to be
able to install/force logging, or censorship. This very centralization
forces us back to a model where we need to trust a very small number of
actors in order for the system to operate as designed. This, to me,
appears to be the opposite of the goals of the bitcoin ecosystem. To
ensure this point is clear, I strongly believe recommending people focus
all lookups through 4 centralized "proxies" is a bad idea and counter to
bitcoin's ideals.
The fact that hackers or state actors need to corrupt only a small number
of servers/services in order to gain global visibility into all queries, I
believe, breaks any perceived privacy gains from using DNSCrypt. A very
small number of hacks or subpoenas and everyone's records are fair game in
one place.
For the highly privacy conscious they can, today do their DNS lookups over
a non logging VPN connection without forcing everyone else through a
handful of centralized servers. Or they can use DNSCrypt optionally
themselves. All of our tools have always been open source and folks can
modify them for their own desired uses, or submit pull requests with their
own ideas.
We'd love to hear others thoughts on this. While I believe that for now
the centralization trade offs required to use DNSCrypt today (via a limited
number of proxies) outweigh any perceived privacy benefits it provides, we
are always open to what others in the community believe and have made
modifications to how things work before as a result of feedback from
industry participants.
>
>
>> 2> We have the option of storing a URL rather than just a wallet
>> address in the TXT record. This allows a second level lookup against
>> the URL to get back a unique HD Wallet address or Payment Request each
>> time, further protecting user privacy and security. Using Wallet
>> Names with Payment Requests allows for the user experience of typing
>> in an easy to remember name and getting back the "green lock" and who
>> the validated recipient is. This also provides an auto audit of the
>> end to end DNS SEC process, in the case the path were somehow
>> compromised, the signature on the payment request can provide an
>> additional check.
>>
>
> OpenAlias supports this as well, except it does it better by allowing the
> KV pairs to also contain a TLSA record before the request, which
> effectively makes it a DANE-secured interaction. Your interaction requires
> the trusting of multiple CAs, which is an inherent weakness.
>
I think DANE is a great idea. We were just discussing that with Andreas
S., and are currently looking at whether we want to add this as optional
versus mandatory, based on how widely available DANE is for folks using
services like Cloudflare, Akamai, etc for their DNS, which many providers
in the space today are.
Of course, the security conscious could setup DANE on the URL we use AS
IS. There is no need to create a special kv pair for this as is done in
OpenAlias. As you know, DNSSEC and HTTPS support this today out of the box.
The CA validation, in our case, is an ADDITIONAL signature based validation
to the DNSSEC chain, not a replacement for it.
[CONTINUED]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150716/c798d824/attachment.html>

2023-06-07 15:42:11

- reply

📅 Original date posted:2015-07-16
📝 Original message:[continued]
> 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.
>>
>
> We do the same thing, except in a single call. Here's an example of a
> record that has both XMR and BTC addresses:
> https://api.openalias.org/donate.getmonero.org?view=full (here are the
> DNS records for that:
> http://mxtoolbox.com/SuperTool.aspx?action=txt%3adonate.getmonero.org&run=toolpage
> )
>
We looked at doing this in a single lookup as you did. With one or two
currencies this can be potentially more efficient. As the number of
supported currencies and addresses under a single name grows, however, this
solution becomes potentially more problematic. Please follow the use cases
below:
Use case 1: Wallet Name = "bob.foo.bar" or OpenAlias = "bob.foo.bar"
The only currency supported is bitcoin, and there are no colored coin
formats supported.
OpenAlias case:
1 packet lookup to "bob.foo.bar"
1 packet response with bitcoin address
= 2 packets
Wallet Name case:
1 packet lookup to "_wallet.bob.foo.bar"
1 packet response with supported address types
1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address
= 4 packets
Wallet Name Case 1a:
The wallet doing the lookup knows it wants bitcoin, so it skips the
supported addresses lookup
1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address
= 2 packets
In this use case we might create more traffic, but it could also be reduced
by doing smart lookups.
Use case 2: Wallet Name = "bob.foo.bar" or OpenAlias = "bob.foo.bar"
Many currencies and colored coin addresses are supported under the same
name, lets say 100. When you count different currencies and colored coin
types, it could easily be hundreds, or over a thousand.
OpenAlias case:
1 packet lookup to "bob.foo.bar"
100 packet responses with various addresses
= 101 packets
Wallet Name case:
1 packet lookup to "_wallet.bob.foo.bar"
1 packet response with supported address types
1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address
= 4 packets
Wallet Name Case 2a:
The wallet doing the lookup knows it wants bitcoin, so it skips the
supported addresses lookup
1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address
= 2 packets
While you may end doing "less lookups" under Open Alias, as it scales, you
end up causing a significant amount of extra, unnecessary traffic.
In addition to the obvious impact of being orders of magnitude more
wasteful than necessary, it also creates privacy "leakage" by returning
someone 100 different addresses when they only asked for one.
Finally, because a single packet UDP transaction for a DNS lookup can
create possibly hundreds of packets in response, the service can
essentially become an amplifier for DDoS attacks. (If I spoof the source
address of my target with a query to a lookup that issues hundreds of
packets in response to one packet, and I can have a real impact :( )
>
>
>> 4> We mandate DNSSEC while you make it optional. We did this because
>> we believe giving the user the option of NOT using DNSSEC is like
>> letting them order a car with no brakes. We weren't sure how we would
>> explain to them why their money was gone when they really didn't
>> understand the risks they were taking up front. We had a lot of
>> discussion about it before coming to the decision we did, and I can
>> see why you went the other way, although I do believe we made the
>> right choice.
>>
>
> With OpenAlias a DNSSEC fail is a soft fail, and the user has to confirm
> the address. The reasons are threefold:
>
> 1. At the moment only 83.5% of the TLDs are signed [2]. The unsigned ones
> include some biggies like .sg, .za, and .to
>
I think this is a good point, and one we weighed. When we were making our
original decisions. Given the importance of ensuring that the lookups
return the correct value, and the known vulnerabilities in DNS without
DNSSEC, coupled with the fact that ICANN has mandated all zones and
registries move to DNSSEC, our belief was and is that it was worth the
trade off that there were cases where existing domains would not work.
It is important to note, that ICANN has "required" for some years that
registrars and registries support DNSSEC on the domains they register. I
personally believe we shouldn't delay use of DNSSEC until their registries
had come up to current required Internet standards. (Here are ICANN's
registrar requirements showing the DNSSEC requirement, btw:
https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#operation
)
That said, what do others in the industry think? We are basing our current
standard on our believed best practices, and defaulted to "first, lose no
money", given the irreversibility of bitcoin.
> 2. Even if the zone *is* signed, DNSSEC deployment is hard. Unmanaged
> DNSSEC deployment is out of scope for probably 99.9% of users, even the
> usually-technically-ok Bitcoin crowd. Managed DNSSEC is available, but is
> quite pricey. UltraDNS, Dyn, and GoDaddy (ikr?) are the three big
> providers, and of those three only GoDaddy has a consumer-affordable
> product.
>
I think "DNSSEC is hard" is a bit of a boogey man that's not really true.
We are working on developing registrar by registrar instructions of how to
do this, and we have typically found that if you are setting up DNS by
yourself, adding DNSSEC doesn't take a lot of additional time, maybe an
hour or so depending on your registrar.
This known concern, however, is why when we launched our product (based on
our standard record formats) that we wanted to launch it with a variety of
options for people.
In addition to these options there are also other hosting providers, and
certain registrars that will allow you to setup DNSSEC on their DNS
platforms.
1> One could choose the "0 click" installation process of just getting a
free Wallet Name underneath their provider's name space. This option has
been free to end users in all cases so far, and I expect it always will be
in the future (although that is up to the partner, so some may choose to
charge).
2> If they wanted some provider independence, but someone to manage things
for them, they can register a name through us and manage everything via our
web interface. This can cost them as little as $1.95/yr through us.
3> Finally, for the "do it yourselfer" who wants full control themselves,
they can simply follow the formats on our developer page and do the whole
thing themselves. If they do this by registering their own ".bit" this
will cost them less than $0.25. If they have an existing domain name, even
less.
>
> 3. ThomasV and I have done a stack of testing behind residential and
> commercial routers where DNSSEC simply fails (eg. the router runs a really
> outdated DNS server that doesn't provide RRSIGs in its response, or the ISP
> doesn't care about DNSSEC). Unsurprisingly, this can be fixed by...you
> guessed it...doing the lookup via DNSCrypt.
>
That's some interesting data, and runs counter to the research of the IETF
DNS working group. If you are willing to share your data, I can put you in
touch with the appropriate folks there to share your research. I'd also
love to see it!
>
> Until we are closer to the bulk of all TLDs being signed, and DNSSEC
> becomes at least a little more ubiquitous, we can't lock out huge portions
> of the Internet, because then we're not really providing a useful and
> usable solution. All we can is make it more difficult to pay an unverified
> domain.
>
> Of course, if your aim is to force people to use you as a domain
> registrar, then it makes total sense why you'd lock people out;)
>
I'd argue that we aren't locking "huge portions" of the Internet. You are
correct that about 15% of TLD's are not yet signed, even though they were
required to be by ICANN.
As I said above, I believe the requirement to not lose money and the fact
that other options are available for those running on TLD's that are out of
compliance, is worth the trade off that some existing names won't work
until their TLD's come into compliance with current Internet standards.
And, as we covered above, we don't force anyone to use our registrar, nor
any of our services in order for Wallet Names to work for them. We never
have. It's just not who we are.
>
> Additionally, we just released another open source API server to help
>> with the "other half" of the lookup problem. Its in its infancy, and
>> we are certainly taking feedback on it at this time. It is called
>> Addressimo <https://github.com/netkicorp/addressimo> and will serve
>> unique HD Wallet addresses or Payment Requests for every lookup, thus
>> allowing a user to have a private, secure way to share a Wallet Name
>> that can be used to send them any digital currency.
>>
>
> Oh snap...https://github.com/openalias/openalias-api
>
These are actually vastly different pieces of software, at least from the
description, and a first read of the code. My understanding is the
software you linked to here basically takes the DNS work out of lookups for
people, as we released: https://github.com/netkicorp/wns-api-server Its
our Wallet Name Lookup server.
Addressimo, as I described above, provides a different purpose. Its a way
for service providers, mobile wallet providers or end users to have an
online server that can serve unique wallet addresses ala HD Wallets (BIP32)
or signed Payment Requests (BIP0070). This allows for an easy way to
increase security and privacy by serving a unique address for every
request, and/or sign the address (and other optional data) with an X509
private key to prove ownership of the address in a way independent of and
supplemental to the DNSSEC chain (also can be DANE for yet another layer of
security). It also supports offline signing of the Payment Requests so the
server doesn't have to have access to a private key, or need to be trusted.
>
>
> In any case, I'd much rather we had one effort going forward than
>> multiples, so let's talk!
>>
>
> I agree, and you guys are in an ideal position to change to supporting the
> OpenAlias standard (and enhancing it) without skipping a beat. We would
> definitely appreciate and take your input and efforts, and that would make
> OpenAlias v2 (oa2:) a standard built out in conjunction with Netki.
>
> Not only do you get Electrum support without lifting a finger, but it will
> go a long way to repairing your relationship with the open-source community
> at large, several proponents of which have taken great umbrage at what you
> were previously pushing as a closed-source, centralised system.
>
>
I'm a little confused by these closing statements. Our system has, from
the beginning been open in terms of the fact that anyone could both serve
names or do lookups without ever touching our servers, talking to us, or us
even knowing that they did it or that they even exist. Our system has
NEVER been one where folks were required to use us for any portion of the
service, and from our first beta product launch our open source tools did
all lookups against DNS records and the blockchain, never any proprietary
servers or interfaces on our side.
In terms of the format itself being open, we have already made several
extensions and modifications to it as a result of conversations with
industry participants in order to ensure that what we are building meets
the needs of the community at large. We will gladly continue to do so, it
is how we ensure we are building something everyone needs!
I'd love to know where you got information that we were in some way a
closed and centralized system so that we can have an opportunity to clarify
that misconception.
In terms of finding a common standard, as I said, I am thrilled to have the
conversations, but there are some places, highlighted above, that would
cause me to hesitate to "just implement" the Open Alias standard. I can
also see places where bringing the formats together to one standard could
have strong benefits, for example:
I think formatting the record as a key value pair with versioning has
merit, and would love to move it in to what we are doing (and likely will).
On the other side, I think the two level lookup provides a lot of value at
scale over trying to send back a bunch of text records when only a small
portion of the data is used.
I'd love to hear thoughts from others in the community on mandating DNSSEC
and thoughts on DNSCrypt. I have a strong opinion on both of those but
would love to engage in thoughtful dialogue around what path best suits the
need of the community.
Looking forward to the discussion!
On Thu, Jul 16, 2015 at 5:55 PM, Justin Newton <justin at netki.com> wrote:
> I am breaking this into a couple of pieces as my first response has been
> in a moderator queue for some time because it is too long.
>
>
> TL;DR version - Wallet Name Service has always been a decentralized and
> distributed service that it no way requires you to ever touch the Netki
> infrastructure. We want to work with the community, as we have been from
> the beginning, to come up with the best standard possible.
>
> Longer answers inline below.
>
>
>
> On Tue, Jul 14, 2015 at 12:07 PM, Riccardo Spagni <ric at spagni.net> wrote:
>
>>
>>
>>> In terms of comparisons to OpenAlias, I think there are a lot of
>>> similarities, but a few differences. First the similarities:
>>>
>>>
>>> 1> We both use DNSSEC.
>>>
>>> 2> We both have the option of storing the address directly in the DNS
>>> record.
>>>
>>>
>>> Differences:
>>>
>>> 1> We do not use DNSCrypt. I understand why you chose to, but we were
>>> concerned about broad interoperability and easy broad distribution of
>>> hosting, so decided not to use it. We have other ways of achieving
>>> privacy, using HD Wallets and Payment Requests.
>>>
>>
>> And this is the part where you guys look really, really incompetent (and
>> I don't mean that in a terribly demeaning way, it's just that you're in a
>> space where you want to be a domain expert, not make a series of
>> embarrassing and public faux pas).
>>
>>
>> I appreciate the thought :) I think where we differ is on where we
> believe the trade offs should be on perceived privacy versus censorship
> resistance and centralization.
>
>
> By having a limited number of proxies people need to go through to easily
> implement, be it the 4 you recommend, or 53, you actually have a very
> limited number of actors for an authority or hacker to go to in order to be
> able to install/force logging, or censorship. This very centralization
> forces us back to a model where we need to trust a very small number of
> actors in order for the system to operate as designed. This, to me,
> appears to be the opposite of the goals of the bitcoin ecosystem. To
> ensure this point is clear, I strongly believe recommending people focus
> all lookups through 4 centralized "proxies" is a bad idea and counter to
> bitcoin's ideals.
>
>
> The fact that hackers or state actors need to corrupt only a small number
> of servers/services in order to gain global visibility into all queries, I
> believe, breaks any perceived privacy gains from using DNSCrypt. A very
> small number of hacks or subpoenas and everyone's records are fair game in
> one place.
>
>
> For the highly privacy conscious they can, today do their DNS lookups over
> a non logging VPN connection without forcing everyone else through a
> handful of centralized servers. Or they can use DNSCrypt optionally
> themselves. All of our tools have always been open source and folks can
> modify them for their own desired uses, or submit pull requests with their
> own ideas.
>
> We'd love to hear others thoughts on this. While I believe that for now
> the centralization trade offs required to use DNSCrypt today (via a limited
> number of proxies) outweigh any perceived privacy benefits it provides, we
> are always open to what others in the community believe and have made
> modifications to how things work before as a result of feedback from
> industry participants.
>
>
>
>
>
>
>>
>>
>>> 2> We have the option of storing a URL rather than just a wallet
>>> address in the TXT record. This allows a second level lookup against
>>> the URL to get back a unique HD Wallet address or Payment Request each
>>> time, further protecting user privacy and security. Using Wallet
>>> Names with Payment Requests allows for the user experience of typing
>>> in an easy to remember name and getting back the "green lock" and who
>>> the validated recipient is. This also provides an auto audit of the
>>> end to end DNS SEC process, in the case the path were somehow
>>> compromised, the signature on the payment request can provide an
>>> additional check.
>>>
>>
>> OpenAlias supports this as well, except it does it better by allowing the
>> KV pairs to also contain a TLSA record before the request, which
>> effectively makes it a DANE-secured interaction. Your interaction requires
>> the trusting of multiple CAs, which is an inherent weakness.
>>
>
> I think DANE is a great idea. We were just discussing that with Andreas
> S., and are currently looking at whether we want to add this as optional
> versus mandatory, based on how widely available DANE is for folks using
> services like Cloudflare, Akamai, etc for their DNS, which many providers
> in the space today are.
>
> Of course, the security conscious could setup DANE on the URL we use AS
> IS. There is no need to create a special kv pair for this as is done in
> OpenAlias. As you know, DNSSEC and HTTPS support this today out of the box.
>
> The CA validation, in our case, is an ADDITIONAL signature based
> validation to the DNSSEC chain, not a replacement for it.
>
>
> [CONTINUED]
>
>
--
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/20150717/56745b7b/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/20150717/56745b7b/attachment.tiff>

2023-06-07 15: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