[Brainstorming] Namecoin SPV

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

Re: [Brainstorming] Namecoin SPV

Post by biolizard89 »

dolphin wrote:
biolizard89 wrote: The Namecoin client code is in the middle of a rewrite effort (the current release is based on Bitcoin 0.3.x, which isn't maintainable). My opinion (which may or may not be shared by other devs) is that something as complex as SPV+UTXO should be implemented based on the rewritten client rather than the current one. It's also possible that when that is finished, Bitcoin will have produced some working code. Would you be interested in helping to port Namecoin to the current Bitcoin Core codebase? We'd love to have some help with that. :)
Sure, absolutely. I didn't find any task list around. I guess I must have missed it somehow. Would you, please, direct me to where to look? I'd much appreciate that!
domob is currently leading that effort, he can probably give you some details on what tasks remain and how to help.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

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

Re: [Brainstorming] Namecoin SPV

Post by biolizard89 »

domob wrote:
biolizard89 wrote:The Namecoin client code is in the middle of a rewrite effort (the current release is based on Bitcoin 0.3.x, which isn't maintainable). My opinion (which may or may not be shared by other devs) is that something as complex as SPV+UTXO should be implemented based on the rewritten client rather than the current one. It's also possible that when that is finished, Bitcoin will have produced some working code. Would you be interested in helping to port Namecoin to the current Bitcoin Core codebase? We'd love to have some help with that. :)
Let me chime in here only briefly - and note that I have only skimmed the proposal for Namecoin UTXO posted above. While I agree with biolizard89 that the best course of action is to finish the rebase on Bitcoin Core and hope they have implemented their UTXO stuff then, I also believe that it could make sense to build a simpler model that just facilitates name lookups (could be used in addition and be easier to handle for clients that just need names - but that depends on the details).

For instance, blocks could include the full name-value database (i. e., basically the name_show result for each name) in the Merkle tree. (This should be done in a deterministic way so that this data is not transmitted together with the block but instead created by each node and verified as part of the block validation. Something like that is done for Huntercoin already (for a different purpose) and works well.) With this, an untrusted name resolver could prove its result by providing a branch in the Merkle tree to the light client. Since each name that is registered or expired can only appear once in the Merkle tree, the client could be sure that the result is indeed the correct value (and also up-to-date, including its expiration status). The only thing a resolver could do is pretend that a name doesn't exist when it in fact does. Not sure if that's a problem. I'm definitely open for discussion about including something like this even in the old codebase (especially if you want to do it) and then porting it also to the new one. IMHO this is a complementary thing to Bitcoin's UTXO support (whenever it comes).
I guess I'm not clear on how a separate Merkle tree for names is helpful. If a name transaction is in the UTXO Merkle tree, then that should yield all the information needed to access and verify the name data. Am I missing something?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

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

Re: [Brainstorming] Namecoin SPV

Post by domob »

biolizard89 wrote:
domob wrote:
biolizard89 wrote:The Namecoin client code is in the middle of a rewrite effort (the current release is based on Bitcoin 0.3.x, which isn't maintainable). My opinion (which may or may not be shared by other devs) is that something as complex as SPV+UTXO should be implemented based on the rewritten client rather than the current one. It's also possible that when that is finished, Bitcoin will have produced some working code. Would you be interested in helping to port Namecoin to the current Bitcoin Core codebase? We'd love to have some help with that. :)
Let me chime in here only briefly - and note that I have only skimmed the proposal for Namecoin UTXO posted above. While I agree with biolizard89 that the best course of action is to finish the rebase on Bitcoin Core and hope they have implemented their UTXO stuff then, I also believe that it could make sense to build a simpler model that just facilitates name lookups (could be used in addition and be easier to handle for clients that just need names - but that depends on the details).

For instance, blocks could include the full name-value database (i. e., basically the name_show result for each name) in the Merkle tree. (This should be done in a deterministic way so that this data is not transmitted together with the block but instead created by each node and verified as part of the block validation. Something like that is done for Huntercoin already (for a different purpose) and works well.) With this, an untrusted name resolver could prove its result by providing a branch in the Merkle tree to the light client. Since each name that is registered or expired can only appear once in the Merkle tree, the client could be sure that the result is indeed the correct value (and also up-to-date, including its expiration status). The only thing a resolver could do is pretend that a name doesn't exist when it in fact does. Not sure if that's a problem. I'm definitely open for discussion about including something like this even in the old codebase (especially if you want to do it) and then porting it also to the new one. IMHO this is a complementary thing to Bitcoin's UTXO support (whenever it comes).
I guess I'm not clear on how a separate Merkle tree for names is helpful. If a name transaction is in the UTXO Merkle tree, then that should yield all the information needed to access and verify the name data. Am I missing something?
No, that's perfectly fine (as long as you include the tx height into the UTXO set, so that the peer is not able to send you an expired name which is still "unspent" in the output sense). I just thought that it may be simpler to implement name-value lookup in this way than a full UTXO client. And unlike Bitcoin, name-value lookup seems to be actually one of the "most interesting" use-cases for UTXO light clients.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

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

Re: [Brainstorming] Namecoin SPV

Post by tosh0 »

biolizard89 wrote: @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.

-It would be verified since nodes/miners will ignore blocks containing incorrect snapshot hash.
-This snapshot file doesn't have to be huge as it will contain a group of hashes that allow the lockup of even more files containing groups of names and tx identified by NMC name or address. (in a tree like manner)

In reality this huge "file" will work just like a distributed hash table that utorrent uses, the client should be able to just request the files or pieces pertinent to his transaction and it should be able to verify it in a tree like structure just like the one dolphin and the "ultimate blockchain compression" UTXO proposal uses, but it will use files instead of blocks, it will then use the blockchain consensus to verify this files were the truth at that point in time. So the difference with the dolphin schematic is that he uses the whole blockchain as a data structure and lookup blocks. and i suggest creating a new data structure that becomes updated with time. (and even could get rid of the blockchain altogether for most clients and let them use a miniblockchain of the last x blocks.) OMG inception...
NMC: more stable than BTC!

MaxWeiss
Posts: 1
Joined: Sun Jan 05, 2014 8:27 am
Location: id/maxweiss

Re: [Brainstorming] Namecoin SPV

Post by MaxWeiss »

Are there any other threads relating to this, or any updates? I like both proposals, although I think having a merkle root of current names added to the block header is preferable, since all current SPV methodologies can be easily implemented with that. I think the extra space in the block header and the extra validation is worth the trouble in order to be able to have SPV nodes for name validation. I'm a relatively new programmer, not at developer level by any means, but I'm reasonably proficient at Python and will see if I can write up anything that may be in any way useful for this effort.

Namecoin's immense usefulness is so under-utilized right now. I all kinds of apps having Namecoin SPV nodes built into them, and allowing users to use trustless verifiably accurate information. Bitmessage wouldn't need a full node -- it could just connect via SPV and nobody would ever have to see addresses. Bitcoin clients and websites could just use name id's, and the users could be completely confident in them. The entire WOT for PGP becomes unnecessary.
id/maxweiss

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

Re: [Brainstorming] Namecoin SPV

Post by indolering »

I've started a wiki article to try and capture our efforts on this front. I haven't had time to add information from this forum thread, but feel free to do so.
DNS is much more than a key->value datastore.

hla
Posts: 46
Joined: Mon Nov 10, 2014 12:01 am
os: linux
Contact:

Re: [Brainstorming] Namecoin SPV

Post by hla »

I've written a chart of possible deployment modes here: https://github.com/hlandau/ncdocs/blob/ ... amecoin.md
Some more introductory material: https://github.com/hlandau/ncdocs/blob/ ... s-intro.md

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

Re: [Brainstorming] Namecoin SPV

Post by phelix »

domob wrote:
biolizard89 wrote:
domob wrote:
biolizard89 wrote:The Namecoin client code is in the middle of a rewrite effort (the current release is based on Bitcoin 0.3.x, which isn't maintainable). My opinion (which may or may not be shared by other devs) is that something as complex as SPV+UTXO should be implemented based on the rewritten client rather than the current one. It's also possible that when that is finished, Bitcoin will have produced some working code. Would you be interested in helping to port Namecoin to the current Bitcoin Core codebase? We'd love to have some help with that. :)
Let me chime in here only briefly - and note that I have only skimmed the proposal for Namecoin UTXO posted above. While I agree with biolizard89 that the best course of action is to finish the rebase on Bitcoin Core and hope they have implemented their UTXO stuff then, I also believe that it could make sense to build a simpler model that just facilitates name lookups (could be used in addition and be easier to handle for clients that just need names - but that depends on the details).

For instance, blocks could include the full name-value database (i. e., basically the name_show result for each name) in the Merkle tree. (This should be done in a deterministic way so that this data is not transmitted together with the block but instead created by each node and verified as part of the block validation. Something like that is done for Huntercoin already (for a different purpose) and works well.) With this, an untrusted name resolver could prove its result by providing a branch in the Merkle tree to the light client. Since each name that is registered or expired can only appear once in the Merkle tree, the client could be sure that the result is indeed the correct value (and also up-to-date, including its expiration status). The only thing a resolver could do is pretend that a name doesn't exist when it in fact does. Not sure if that's a problem. I'm definitely open for discussion about including something like this even in the old codebase (especially if you want to do it) and then porting it also to the new one. IMHO this is a complementary thing to Bitcoin's UTXO support (whenever it comes).
I guess I'm not clear on how a separate Merkle tree for names is helpful. If a name transaction is in the UTXO Merkle tree, then that should yield all the information needed to access and verify the name data. Am I missing something?
No, that's perfectly fine (as long as you include the tx height into the UTXO set, so that the peer is not able to send you an expired name which is still "unspent" in the output sense). I just thought that it may be simpler to implement name-value lookup in this way than a full UTXO client. And unlike Bitcoin, name-value lookup seems to be actually one of the "most interesting" use-cases for UTXO light clients.
Will Namecore bring us any closer to that? I still like the idea of the name merkle tree...
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 »

phelix wrote:
domob wrote:No, that's perfectly fine (as long as you include the tx height into the UTXO set, so that the peer is not able to send you an expired name which is still "unspent" in the output sense). I just thought that it may be simpler to implement name-value lookup in this way than a full UTXO client. And unlike Bitcoin, name-value lookup seems to be actually one of the "most interesting" use-cases for UTXO light clients.
Will Namecore bring us any closer to that? I still like the idea of the name merkle tree...
Namecore at least builds and keeps the UTXO set. It also has RPC calls to deal with it. So far I don't see any more things at which it helps, but we could easily add a name merkle tree with its root in the coinbase or something. But I think this needs proper planning and discussion so that we do it right.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

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

Re: [Brainstorming] Namecoin SPV

Post by dolphin »

Reviving an old thread... I was away working on something fundamentally different for a while, but came back to NameCoin lately. Looking at forum posts, I have a feeling that a completely trustless SPV is not implemented yet. Is that so or am I missing important updates in the buzz?

Is it still worthwhile looking into implementation of proposals, I've made a while ago or similar better alternatives? I have some cycles to spare and could look into implementing and submitting a pull request but thought to check with the community first.

Thank you,
Dolphin
NameCoin and Security News
Chrome extension for Gmail encryption - protect your identity and E-mails using NameCoin

Post Reply