Le 14/07/2015 19:29, Justin Newton a écrit : > 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 >
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. > 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. > As far as Electrum is concerned, I do not see DNSCrypt as something usable in the short term. I do not think it should be mandated, because there are other ways of achieving privacy, as you say. > 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. > I see value in the ability to store differerent types of strings in TXT records. In particular, I have the need to store an email address, and more than one Bitcoin address or xpubkey per alias. > 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? > 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. I agree on this; there is no point using OpenAlias without DNSSEC. Wallets can use fallback servers if the default DNS does not have DNSSEC. > > > 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. > 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. > > 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 "j...@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! > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
