From: Justin Newton <justin@netki•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
Date: Sat, 18 Jul 2015 16:01:39 -0700 [thread overview]
Message-ID: <CABqynx+X9j3UviQGp-Vaf77gKM9TAJZxnWkfA3DgmSELxu1RhQ@mail.gmail.com> (raw)
In-Reply-To: <55AA54C3.7010806@electrum.org>
On Sat, Jul 18, 2015 at 6:29 AM, Thomas Voegtlin via bitcoin-dev
<bitcoin-dev@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@netki•com
+1.818.261.4248
next prev parent reply other threads:[~2015-07-18 23:01 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-14 17:29 Justin Newton
2015-07-18 13:29 ` Thomas Voegtlin
2015-07-18 23:01 ` Justin Newton [this message]
2015-07-20 8:56 ` Thomas Voegtlin
-- strict thread matches above, loose matches on Subject: below --
2015-07-27 22:46 Riccardo Spagni
2015-07-18 11:40 Riccardo Spagni
2015-07-18 11:46 ` Mike Hearn
2015-07-17 8:00 Riccardo Spagni
2015-07-18 11:21 ` Mike Hearn
2015-07-16 16:18 Riccardo Spagni
2015-07-14 19:07 Riccardo Spagni
2015-07-17 0:55 ` Justin Newton
2015-07-17 0:58 ` Justin Newton
2015-07-17 1:01 ` Justin Newton
2015-07-17 1:02 ` Justin Newton
2015-07-23 9:48 ` Thomas Voegtlin
2015-07-23 13:07 ` Thomas Voegtlin
2015-07-27 21:51 ` Justin Newton
2015-07-31 20:34 ` Thomas Voegtlin
2015-07-14 8:29 Riccardo Spagni
2015-07-13 22:31 Mike Hearn
2015-07-14 6:42 ` Thomas Voegtlin
2015-07-14 11:19 ` Milly Bitcoin
2015-07-14 13:13 ` Thomas Voegtlin
2015-07-14 11:45 ` Mike Hearn
2015-07-19 11:18 ` Thomas Voegtlin
2015-07-20 13:46 ` Mike Hearn
2015-07-20 14:32 ` Thomas Voegtlin
2015-07-20 14:42 ` Mike Hearn
2015-07-20 14:52 ` Thomas Voegtlin
2015-07-20 15:14 ` Mike Hearn
2015-07-20 15:34 ` Thomas Voegtlin
2015-07-20 16:09 ` Mike Hearn
[not found] <55A3B52C.9020003@electrum.org>
2015-07-13 13:06 ` Thomas Voegtlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABqynx+X9j3UviQGp-Vaf77gKM9TAJZxnWkfA3DgmSELxu1RhQ@mail.gmail.com \
--to=justin@netki$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox