Namecoin Forum

I would like to explore the idea of adding Namecoin specific functions to an existing SPV client for Namecoin (the Namecoin Wallet for Android: https://play.google.com/store/apps/deta ... oin.wallet - forked by Hash Engineering). This particular SPV client does not store the blockchain, but rather downloads the headers only. It is able to get relevant transactions other peers for coin transactions.

Since the naming service functions are also in transactions (with a different transaction version to mark them off), I am wondering if it is possible to add the name_new, name_firstupdate and name_update transaction functionality to the Namecoin Wallet (which is forked from the Bitcoin Wallet for android).

Theoretically, we could design a UI for creating a domain name. The app would send out the first transaction (new_name), then wait the 12 blocks before sending out the name_firstupdate transaction. The app would know when these transactions are confirmed in the blockchain, in the same way it knows about simple coin transactions (send or receive).

The desktop client generates a Name Index database from parsing the blockchain, block by block, which it first queries to see if a name already exists. Can this functionality be left out? That file is 97 MB currently.

What foreseeable problems would there be with doing an SPV namecoin client? Does it really need to see the entire blockchain to create and update names?

Is there any other functionality that would also be good to add to the Namecoin Wallet for android?

The desktop client generates a Name Index database from parsing the blockchain, block by block, which it first queries to see if a name already exists. Can this functionality be left out? That file is 97 MB currently.

Yes, if this is the hurdle to overcome, leave it out. Promt the user to inform them if they try to register a name thats already in existance, they will pe paying the fee and will not get it back. Perhaps include a link to a block explorer to where one could perform this lookup. Also, it might be wise to include a check of the device's battery state of charge, and notify the user of such because it needs to be on 12 blocks (~2 hours) later to issue the firstupdate. The number of blocks to wait should be a setting a user could change, because I believe 12 blocks is not required, it can be issued in the next block. There is a risk to doing this, but I can't remember the details. It's low and not one that would concern me, I'd rather be the owner of the name as quick as possible.

What foreseeable problems would there be with doing an SPV namecoin client? Does it really need to see the entire blockchain to create and update names?

I'm not entirely sure, but I don't see why you'd need access to the blockchain history to update a name, so long as the app knows what details of the name to keep constant or update with new info. It would need to store the last update it performed so it can renew with the same info.

Is there any other functionality that would also be good to add to the Namecoin Wallet for android?

Automatic name renewal, and a name drop-catcher would be slick.

relevant: https://forum.namecoin.info/viewtopic.php?f=5&t=1067

IIRC the biggest issue with name SPV is that you can not easily be sure that you got the most recent value version of the name. Could be it's possible to improve this with the bloom filter (?)

Bloom filter wouldn't be a good idea - they can have false positives, so you might identify a name as not being the latest version even though it is.

phelix wrote:relevant: https://forum.namecoin.info/viewtopic.php?f=5&t=1067

IIRC the biggest issue with name SPV is that you can not easily be sure that you got the most recent value version of the name. Could be it's possible to improve this with the bloom filter (?)

If the Merkle tree is constructed for every block (needs a softfork) and contains all current names, then if you get a reply with a branch you can verify that the value you got is indeed the latest name. The only thing for which a server can lie to you is if it tells you the name does not exist (or is expired) while it actually exists. Or do I miss anything here?

domob wrote:If the Merkle tree is constructed for every block (needs a softfork) and contains all current names, then if you get a reply with a branch you can verify that the value you got is indeed the latest name. The only thing for which a server can lie to you is if it tells you the name does not exist (or is expired) while it actually exists. Or do I miss anything here?

Supposedly there is a way to do it that offers authenticated denial. I am not sure how efficient it is. I need to research this further.