Namecoin

[cjb]

Namecoin

[JeremyRand]

Hi! Namecoin developer here.

there’s no compact representation (like Bitcoin’s Simplified Payment Verification) for determining whether a claimed name is valid without consulting a full history.

@cjb Lightweight SPV Namecoin resolution was first introduced in July 2016 IIRC. (So a few months after you posted this.) At the moment, there are 2 lightweight SPV Namecoin clients available: ConsensusJ-Namecoin and Electrum-NMC. (Electrum-NMC tends to be more actively developed, because most of our funders like it more.)

incidentally, I was wrong about namecoin requiring regular payments. website states it requires regular renewals which are free for now.

@xloem This isn't accurate; the confusion might stem from the fact that there are two types of fees in Namecoin: name registration fees (which apply only to registrations, not renewals, and which are primarily intended to prevent miners from engaging in squatting) and transaction fees (which are similar to Bitcoin, and apply to all transactions, including name registrations and name renewals). Any chance you could provide a link to where on the Namecoin website you saw that, so that I can make sure the site doesn't have misleading info on it?

FWIW while I'm not likely to submit a patch for Namecoin support anytime soon, I'd be happy to answer questions if someone else wants to work on this.

[cjb]

Hi! I have a mild bias against altcoins, and have heard bad things about Namecoin in particular: that the anti-spam incentives aren’t good, leading to illegal files stored in the blockchain itself, and that there’s no compact representation (like Bitcoin’s Simplified Payment Verification) for determining whether a claimed name is valid without consulting a full history.

As I understand it, these two design flaws combine to mean that you have to store some very illegal files to use a namecoin resolver, which doesn’t sound good to me. (I may be mistaken, since the bad things I heard about Namecoin came from Bitcoin people..)

In any case, if someone submitted a PR that allows namecoin usernames as well as the OP_RETURN ones in the spec, I expect I'd accept it, it's easy to support multiple sources of usernames.

[xloem]

How would the client decide whether a bitcoin or namecoin username wins, given conflicts? I suppose it would need to prompt the user?

So you know, my perceptions of namecoin are the opposite of what you have said:
Namecoin has anti-spam contingencies which bitcoin lacks -- it requires pre-registration of names, and it requires regular payment to maintain them. Additionally it has all the safeguards of bitcoin because it is a direct fork. Bitcoin core does not have Simplified Payment Verification support yet, and the clients which offer it do not, as far as I know, offer a programmable API. On the reverse, because namecoin names expire after a set time period, only a portion of namecoin block history is required to validate a name, and anything in old namecoin blocks does not need to be stored for a client to function fully. (like bitcoin, the default client does store everything, including all the obscure encoded storage transactions present in both blockchains)

[cjb]

We could do that, or just namespace all the usernames, or namespace all the usernames except the bitcoin ones. (git clone gittorrent://namecoin:foo.com/bar/baz)

I'll have to read more about the current state of namecoin, thanks!

[jeffanthony]

I agree with everything xloem said but we need not worry about Bitcoin and Namecoin key conflicts - it's cryptographically impossible. Furthermore they both operate on SHA-256 algorithm so a user could create one address which works on both blockchains (aka sidechain).

[xloem]

@jeffanthony the concept for both blockchains is to store information in transactions, not to use the wallet addresses, so equal names could be stored in both chains

incidentally, I was wrong about namecoin requiring regular payments. website states it requires regular renewals which are free for now.

[notpushkin]

I believe the Namecoin integration should be based on the id/ namespace then. In this namespace, each entry contains some meta information about a person. So, if id/cjb contains this value:

{
  "name": "Chris Ball",
  "email": "[email protected]",
  "gittorrent": "81e24205d4bac8496d3e13282c90ead5045f09ea"
}

it could work for GitTorrent.

As for the address, there are really many ways to represent it:

1. gittorrent://nmc/cjb/lilypad-email-shirt
2. gittorrent://nmc/id/cjb/lilypad-email-shirt — this one allows not only id/ namespace, but some others as well
3. gittorrent://cjb.bit/lilypad-email-shirt — same, but for d/ (domain) namespace

[xloem]

I likely wasn't counting transaction fees since usually the user can set them.

In other relevance, there is a hacked together bitcoinsv git remote at https://github.com/xloem/git-remote-bsv.git .