[Brainstorming] Namecoin SPV

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

[Brainstorming] Namecoin SPV

Post by phelix »

https://en.bitcoin.it/wiki/Scalability# ... rification

What about a semi SPV client that would download all full blocks but throw away everything but name info? This would be similar to the pre 0.6 Bitcoin era when the bloom filter was not yet implemented and SPV clients were relatively slow (the bloom filter helps in that you only have to download the parts of the blocks that are relevant to you).

It could only accept domain name transactions as valid once they are buried beneath 10 blocks or so. At least with DNS it is rarely a problem if your data takes some time to propagate - it should still be faster than ICANN propagation.

Later on we could implement a bloom filter like in Bitcoin to be able to filter for name_firstupdate/name_update operations.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: [Brainstorming] Namecoin SPV

Post by domob »

I think this is a good plan, and should be secure enough for a lot of applications. However, I believe that with having to track every name operation, your client will surely need more resources than a Bitcoin SPV one - although one can't help that, of course. (But we could at least implement support for also filtering the name operations, so that for instance only d/ names or id/ names are included and everything else is ignored, too.)
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

moa
Posts: 255
Joined: Mon May 23, 2011 6:13 am

Re: [Brainstorming] Namecoin SPV

Post by moa »

Wouldn't it only need the last 36,000 blocks since all name operations before then have expired/updated since then anyway?

Unless there is reason for knowing the prior name operations and not just the 'current' set of names?

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: [Brainstorming] Namecoin SPV

Post by phelix »

moa wrote:Wouldn't it only need the last 36,000 blocks since all name operations before then have expired/updated since then anyway?

Unless there is reason for knowing the prior name operations and not just the 'current' set of names?
+1 to 36,000. It would not need to store them but only download the headers and name_ops and store a name/value table.

Old name_ops might be of interest for some purposes but probably not for all and not for DNS.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: [Brainstorming] Namecoin SPV

Post by indolering »

It's been about a years since this discussion, any thoughts about how to handle this with Libcoin?
DNS is much more than a key->value datastore.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: [Brainstorming] Namecoin SPV

Post by biolizard89 »

indolering wrote:It's been about a years since this discussion, any thoughts about how to handle this with Libcoin?
I'm not sure, might want to talk to Michael Gronager about that. I know he was doing coding related to the bloom filter recently.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

dolphin
Posts: 16
Joined: Wed Jul 02, 2014 6:52 pm
os: windows

Re: [Brainstorming] Namecoin SPV

Post by dolphin »

Wouldn't it be better to implement a true UTXO? There was a number of discussions on BitCoin forum that resulted in a semi-workable proposal. The reason why it is semi-workable is the fact that all BitCoin transactions/blocks are to be retained, which makes UTXO data structures big and heavy.

Given NameCoin transaction expiration is 12000 blocks (I believe, that's the current value), it does appear possible to create working UTXO, which would allow lightweight name validation. I took the liberty to compile a draft of what NameCoin UTXO may look like and thought it would be a good idea to share it here. I'd appreciate any thoughts and feedback.

The key of the proposal is to maintain a merkle tree of all names/transactions and include it's root in every block, which should add just 32 bytes of data.

Upon generation of a block, the merkle root of last 12000 block would need to be calculated as shown in attached diagrams and included in the block. The block validation algorithm would need to include an extra step of UTXO merkle root validation against prior transactions.

Lightweight clients would use the merkle root to validate the validity of name/block as follows:

a. Request the block from server that maintains name/block index or from another client
b. Validate that the block itself and also validate that it is is part of valid chain by iterating over the next X blocks
c. Compute the merkle tree of names/transactions in the block and compute the UTXO root using merkle branches, returned from other clients or intermediate server that simplifies lookups
d. Match the computed merkle root against the merkle root in the last published block.

The key in this proposal is to eliminate the need for "trust" between requester and provider of block/name information, i.e. allow lightweight, trustless client.

Here is a link to one of the most informative relevant topics on BitCoin form that largely inspired this proposal https://bitcointalk.org/index.php?topic=88208.0
Attachments
Processing a block with name_update operation
Processing a block with name_update operation
utxo_update.png (213.97 KiB) Viewed 43479 times
The UTXO data structure and representation in the NameCoin chain
The UTXO data structure and representation in the NameCoin chain
utxo_start.png (223.12 KiB) Viewed 43479 times
UTXO behavior during name_update on an existing name
UTXO behavior during name_update on an existing name
utxo.png (197.62 KiB) Viewed 43479 times
Last edited by dolphin on Mon Oct 06, 2014 3:57 am, edited 2 times in total.
NameCoin and Security News
Chrome extension for Gmail encryption - protect your identity and E-mails using NameCoin

dolphin
Posts: 16
Joined: Wed Jul 02, 2014 6:52 pm
os: windows

Re: [Brainstorming] Namecoin SPV

Post by dolphin »

The forum did not let me add more than 3 images. Here is one more to illustrate the lookup by lightweight client
Attachments
Lookup and validation by lightweight client
Lookup and validation by lightweight client
uxo_lookup.png (184.99 KiB) Viewed 43473 times
NameCoin and Security News
Chrome extension for Gmail encryption - protect your identity and E-mails using NameCoin

tosh0
Posts: 43
Joined: Sat Mar 22, 2014 6:48 pm

Re: [Brainstorming] Namecoin SPV

Post by tosh0 »

i think there's another way, to allow for trust-less light weight client bootstart. it's kinda strange but simpler and should allow to only need the last 200 blocks and be perfectly valid. (it can be combined with the previous proposal)

Just copy the utorrent model, every 200 blocks create a snapshot of the database of the names and unspent outputs, compress it with a deterministic algorithm and share the hash on a block to the network.

New clients only need to download the last 200 blocks to know that this snapshot is indeed the valid one, (since all blocks come from different miners but if they are in the same fork they should contain the last snapshot hash, until another 200 blocks pass ) and then request the file and update it with the latest changes from the last 200 blocks. The number of blocks stored from now on on this clients can be configurable. And a node with the full blockchain will never request this snapshot files for download but should have cached the last few snapshots built from the blockchain to attend to request from lite clients.
NMC: more stable than BTC!

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: [Brainstorming] Namecoin SPV

Post by biolizard89 »

@dolphin This is basically what maaku was working on, right? If so, yeah, I think something along those lines is the best way long term.

@tosh0 I don't follow how you're planning on verifying the authenticity of the snapshot. Downloading an entire name database to be able to resolve anything would be much less usable compared to what dolphin is talking about, which only requires block headers.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply