Proposal: extend bip70 with OpenAlias

>* Hi Thomas,
>* If you would like to work on this, perhaps it's worth teaming up with them?
> 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).
> names on your behalf. However if you follow the format and host them
> yourself, everything will work just fine, and our open source lookup
> server and libraries will provide those results exactly the same as if
> the names were hosted with us.
> To that end, we have had conversations
> with several companies in the space who intend to host their own
> names, and we intend to work with them on the effort to ensure our
> documentation is sufficient to ensure they can successfully do so.
>
> 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.
>
> 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.
>
> 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.
>
> 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 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.
>
> 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.
>
>
> They actually have a really nice way in their standard to encode email
> addresses that more or less ensures that there won't be name space
> collision in the case that there is already a record "joe.user.com"
> and you want to create one for "joe@user•com" that we are looking at
> adding to what we are doing in the next update to our record formats.
>
> multiples, so let's talk!
>
> 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.
>
> 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.
>
> 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.
>
> 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:
>
> name, lets say 100.  When you count different currencies and colored coin
> types, it could easily be hundreds, or over a thousand.
>
> 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 :( )
>
> 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.
>
> 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.
>
> our standard record formats) that we wanted to launch it with a variety of
> options for people.
>
> 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!
>
> correct that about 15% of TLD's are not yet signed, even though they were
> required to be by ICANN.
>
> 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.
>
> 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.
>
> closed and centralized system so that we can have an opportunity to clarify
> that misconception.
>
>
>
>
>> 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
>
>
>> 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.
>
> 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
> )
>
>
>
>> 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
>
> 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.
>
>
> 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.
>
>
> 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;)
>
>
> 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
>
>
>
> 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 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@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]
>
>
> 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
> )
>
>
>
>> 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
>
> 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.
>
>
> 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.
>
>
> 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;)
>
>
> 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
>
>
>
> 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 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.
> 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.
> 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:
> 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.
> 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 :( )
> 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.
> 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.
> 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!
> 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.
> 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.
> 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.
> It is worth noting that DNS lookups can be done via Tor. In effect that
> gives you 1000+ proxies instead of 56 or 4. BitcoinJ already has code that
> can do this.
> I would agree that it makes sense for proxying of DNS requests to be an
> optional part of the protocol. Wallet developers can then compete on privacy
> vs robustness vs whatever other issues there may be.
>
> Agreed, although I guess the bootstrap time for that is a little on
> the high side, and maybe a little too chunky on mobile devices
> My current thinking with Electrum (that ThomasV and I have bounced
> around) is to make the default policy DNSCrypt -> fallback to
> OpenAlias API pool (which can return DNSSEC data for verification) ->
> fallback to default resolver.
> Hi there.  You are correct that we are a company providing a service,
> however, that service is also based on an open standard which we are
> proposing.  I'll be honest that we haven't done the greatest job in
> promoting the standard so far.  More coming soon on that front.  Any
> of the Open Source Wallet Name resolvers that we have created do
> lookups against the standard record formats, and not directly against
> our servers in any way.  Information on the record formats as well as
> links to the lookup API server and some early libraries can be found
> here:  https://www.netki.com/#/developers and here:
> https://github.com/netkicorp
>
> 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).
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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.
>

> 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.
>
>
> They actually have a really nice way in their standard to encode email
> addresses that more or less ensures that there won't be name space
> collision in the case that there is already a record "joe.user.com"
> and you want to create one for "joe@user•com" that we are looking at
> adding to what we are doing in the next update to our record formats.
>
>
> In any case, I'd much rather we had one effort going forward than
> multiples, so let's talk!
>
>
> 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.
>
> 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 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.
>
> > 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'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 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.
>
>> 3> We use a 2 tier lookup format. [...]
>>
>> We do the same thing, except in a single call. [...]
>
> 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. [...]
>
> One benefit of having an intermediate "_wallet" level is to allow zone
> delegation. Is that the reason for that choice?
>
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?
> 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@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@example•com
> _btc.john._oa2.example.com   <--  bitcoin address of john@example•com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> 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@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@example•com
> _btc.john._oa2.example.com   <--  bitcoin address of john@example•com
> 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?
>