Using the mini-blockchain for decentralized DNS and encrypted internet layer

[bitfreak!]

I'm just creating this thread to briefly document some ideas I had about creating an efficient decentralized DNS system and encrypted internet layer on top of it. It's been known for some time that the mini-blockchain scheme is an ideal system for implementing a decentralized DNS database, because of the way balances are stored in the "account tree". Cryptonite, the first mini-blockchain implementation, has "withdrawal limits" which can be set by the owner of an address. Both the balance and the withdrawal limit of all non-empty addresses are stored in the account tree. To update the withdrawal limit, the address owner will create a special transaction which modifies the withdrawal limit value stored in the account tree. It is easy to see how the account tree can be adapted to store and update IP addresses instead of withdrawal limit values, and it would be much more scalable than a system like Namecoin.

Now I'm not very familiar with the way Namecoin works, and the rest of my post may be reinventing the wheel, but I have some interesting ideas for how to achieve perfectly secure communication between client and server without any centralized certificate authority, and how static files like images can be distributed among peers in a simple and efficient manner which allows for fast website load times and could even reward the nodes who distribute such files. So the first step, as mentioned earlier, is to map domain names to IP addresses using the account tree. If we actually use the public key hashes (aka addresses) as the domain names, then it's possible to use public key cryptography for encrypted communication between clients and servers. We could also add another field to each account in the account tree which maps the public key to a human readable domain to make it user friendly.

Steps for establishing secure communication channel with a server:

1) client uses account tree to lookup IP of a domain
2) client sends hello message containing own public key to server
3) server signs the clients public key and sends it back
4) client reconstructs full public key of server from signed message and:
  a) ensures the public key hash matches value in account tree
  b) ensures the response is signed by that public key
  c) ensures contents of response is their own public key

Now both the client and the server have each others public keys and they can communicate securely, and the client knows it's talking with the correct server because only that server can sign messages with the public key listed in the account tree. Now personally I think this approach is far superior to onion routing, because it allows direct connections to remote servers, you don't need to go through any type of peer circuit or exit nodes which can see what you are doing. And it's completely encrypted end to end, so even your own ISP cannot see what you are requesting from any given server. However they can see with what servers you are communicating, and that may pose a problem for websites wishing to avoid censorship. I think this problem can be best solved by decentralizing the static content among peers, so that the server only needs to hold scripts and databases (eg user database).

My first thoughts on this issue were to work on top of a system like storj, but we really need our web content to be delivered at the fastest speeds possible, and I don't think a system like storj can do that because you need to do tedious blockchain lookups to locate files on the network (correct me if I'm wrong). A much simpler, and faster solution, is this: the client wants a file, so it makes a request to the server, the server has a list of IP's for nodes which it believes are in possession of the files. The first time a new file becomes available, the server may allow peers to download the file directly until it is well enough seeded, but a more secure method would be to anonymously upload the file some where and redirect clients that place. For example some HTML code supplied by the server may look like this: <img src="p2presource:108f07b8382412612c048d07d13f814118445acd" />

The p2presource part indicates we have a distributed file stored by peers, and after ":" is the file hash obviously. To acquire the image in this case, the client would send a request to the server for that resource just as they normally would, and the server may directly serve the file to the client, or it may point to another peer it thinks has the file, or it may redirect to else where, for example an image located on the normal internet. If we wanted to make it even more robust we could allow the server to respond with torrent hashes and then locate the file using DHT and seamlessly download it in the background, however this would only be necessary until enough nodes had the file. Nodes willing to redistribute the file could inform the server of their intentions, and the server will redirect clients to those nodes when ever it receives a request for a file those nodes claimed to have.

Once again this approach should be quite fast, since the files can be downloaded directly from peers, but there isn't any incentive for anyone to redistribute files, but before I get to explaining how that might work, I want to briefly discuss the anonymity implications of the distributed file system I just described. Since the client and server will be communicating securely, it's not possible to eavesdrop and learn what files were requested by the client, but if the client is pointed to other nodes who have the file, when the client makes a request to those nodes it will be in clear text unless we establish some sort of encryption protocol. Now since the client doesn't care about what peers have the file, it doesn't need to validate the identity of peers like it does when it first connects to the main server, all it cares about is getting the correct file with the hash specified by the server, like so:

1) client sends hello message containing own public key to peer
2) peer responds with its own public key, encrypted with client pubkey
3) client verifies response by decrypting message with its private key
4) client sends hash of needed file to peer (encrypted with peer pubkey)
5) peer decrypts hash and sends back requested file (encrypted with clients pubkey)
6) client decrypts file and verifies that the unencrypted file hash is correct

What we basically have now is a system where only the server and/or redistribution peers know what files the client has requested. As mentioned earlier though, there is still no incentive for nodes to share files, what we need is some type of reward system for redistributing files. This should be quite easy since the system I've described is already built on top of the mini-blockchain scheme, a cryptocurrency scheme which is particularly good at handling micro-transactions, which is very helpful in solving this problem. Now I must admit I haven't really thought about the fine details of how this could work, which is why I left it for the end, but basically I imagine a reward system working via some sort of micro-transaction approach where the file is downloaded in small pieces. Or alternatively, another good approach may be to have the server some how pay nodes who redistribute their files.

The interesting thing about this overall system is that domains can have a coin balance associated with them, since the domains are addresses, or they map to addresses. So if servers pay nodes who redistribute their files, then it's much like paying for normal server bandwidth, and if the balance of the server address reaches 0 it will be removed from the account tree, meaning it will be removed from the DNS database. However I don't think we need a protocol for forcing servers to pay nodes who redistribute their files, because if a server stops paying fairly people will simply stop sharing their files and look else where for a better profit. The main issue with this approach however is that nodes must be able to prove they are sharing the files, and we can't use recent innovations related to proof-of-storage because holding the files on disk is simply not enough, they must be shared.

Anyway I wanted to keep this post brief, so I'll leave it there and await some thoughts and feedback on what I have presented so far. Hopefully I have presented some original ideas, and hopefully some of you guys will have some interesting expansions and modifications of these ideas, especially in relation to the reward system for redistribution nodes, because I haven't really done much thinking on that topic. I wont be able to work on implementing any of these ideas since I am already focused on Cryptonite right now, I'm mainly just posting this because a few people on the Cryptonite IRC were interested in it and I thought it was worth sharing. But I do think this system could work very well and I highly encourage any interested parties to give it a shot, I will help however I can. A fast and secure decentralized internet layer would be extremely popular and it's something we really need in my opinion.

[1715437007]

1715437007

[1715437007]

1715437007

[1715437007]

1715437007

[1715437007]

1715437007

[1715437007]

1715437007

[1715437007]

1715437007

[spud21]

The thing I don't like about namecoin is you have to configure your browser to accept it's URLs. You cannot just click a namecoin URL with a standard unconfigured browser and expect it to work. Would your scheme allow someone to just click a URL link and get a result from a standard unconfigured browser?

[bitfreak!]

The thing I don't like about namecoin is you have to configure your browser to accept it's URLs. You cannot just click a namecoin URL with a standard unconfigured browser and expect it to work. Would your scheme allow someone to just click a URL link and get a result from a standard unconfigured browser?

Actually it's probably worse than Namecoin in that respect because the custom encryption protocol and the p2presource links may require a custom browser to handle them, assuming you want access to peer distributed resources.

[digitalindustry]

I'm just creating this thread to briefly document some ideas I had about creating an efficient decentralized DNS system and encrypted internet layer on top of it. It's been known for some time that the mini-blockchain scheme is an ideal system for implementing a decentralized DNS database, because of the way balances are stored in the "account tree". Cryptonite, the first mini-blockchain implementation, has "withdrawal limits" which can be set by the owner of an address. Both the balance and the withdrawal limit of all non-empty addresses are stored in the account tree. To update the withdrawal limit, the address owner will create a special transaction which modifies the withdrawal limit value stored in the account tree. It is easy to see how the account tree can be adapted to store IP addresses instead of withdrawal limit values, and it would be much more scalable than a system like Namecoin.

Now I'm not very familiar with the way Namecoin works, and the rest of my post may be reinventing the wheel, but I have some interesting ideas for how to achieve perfectly secure communication between client and server without any centralized certificate authority, and how static files like images can be distributed among peers in a simple and efficient manner which allows for fast website load times and could even reward the nodes who distribute such files. So the first step, as mentioned earlier, is to map domain names to IP addresses using the account tree. If we actually use the public key hashes (aka addresses) as the domain names, then it's possible to use public key cryptography for encrypted communication between clients and servers. We could also add another field to each account in the account tree which maps the public key to a human readable domain to make it user friendly.

Steps for establishing secure communication channel with a server:

1) client uses account tree to lookup IP of a domain
2) client sends hello message containing own public key to server
3) server signs the clients public key and sends it back
4) client reconstructs full public key of server from signed message and:
  a) ensures the public key hash matches value in account tree
  b) ensures the response is signed by that public key
  c) ensures contents of response is their own public key

Now both the client and the server have each others public keys and they can communicate securely, and the client knows it's talking with the correct server because only that server can sign messages with the public key listed in the account tree. Now personally I think this approach is far superior to onion routing, because it allows direct connections to remote servers, you don't need to go through any type of peer circuit or exit nodes which can see what you are doing. And it's completely encrypted end to end, so even your own ISP cannot see what you are requesting from any given server. However they can see with what servers you are communicating, and that may pose a problem for websites wishing to avoid censorship. I think this problem can be best solved by decentralizing the static content among peers, so that the server only needs to hold scripts and databases (eg user database).

My first thoughts on this issue were to work on top of a system like storj, but we really need our web content to be delivered at the fastest speeds possible, and I don't think a system like storj can do that because you need to do tedious blockchain lookups to locate files on the network (correct me if I'm wrong). A much simpler, and faster solution, is this: the client wants a file, so it makes a request to the server, the server has a list of IP's for nodes which it believes are in possession of the files. The first time a new file becomes available, the server may allow peers to download the file directly until it is well enough seeded, but a more secure method would be to anonymously upload the file some where and redirect clients that place. For example some HTML code supplied by the server may look like this: <img src="p2presource:108f07b8382412612c048d07d13f814118445acd" />

The p2presource part indicates we have a distributed file stored by peers, and after ":" is the file hash obviously. To acquire the image in this case, the client would send a request to the server for that resource just as they normally would, and the server may directly serve the file to the client, or it may point to another peer it thinks has the file, or it may redirect to else where, for example an image located on the normal internet. If we wanted to make it even more robust we could allow the server to respond with torrent hashes and then locate the file using DHT and seamlessly download it in the background, however this would only be necessary until enough nodes had the file. Nodes willing to redistribute the file could inform the server of their intentions, and the server will redirect clients to those nodes when ever it receives a request for a file those nodes claimed to have.

Once again this approach should be quite fast, since the files can be downloaded directly from peers, but there isn't any incentive for anyone to redistribute files, but before I get to explaining how that might work, I want to briefly discuss the anonymity implications of the distributed file system I just described. Since the client and server will be communicating securely, it's not possible to eavesdrop and learn what files were requested by the client, but if the client is pointed to other nodes who have the file, when the client makes a request to those nodes it will be in clear text unless we establish some sort of encryption protocol. Now since the client doesn't care about what peers have the file, it doesn't need to validate the identity of peers like it does when it first connects to the main server, all it cares about is getting the correct file with the hash specified by the server, like so:

1) client sends hello message containing own public key to peer
2) peer responds with its own public key, encrypted with client pubkey
3) client verifies response by decrypting message with its private key
4) client sends hash of needed file to peer (encrypted with peer pubkey)
5) peer decrypts hash and sends back requested file (encrypted with clients pubkey)
6) client decrypts file and verifies that the unencrypted file hash is correct

What we basically have now is a system where only the server and/or redistribution peers know what files the client has requested. As mentioned earlier though, there is still no incentive for nodes to share files, what we need is some type of reward system for redistributing files. This should be quite easy since the system I've described is already built on top of the mini-blockchain scheme, a cryptocurrency scheme which is particularly good at handling micro-transactions, which is very helpful in solving this problem. Now I must admit I haven't really thought about the fine details of how this could work, which is why I left it for the end, but basically I imagine a reward system working via some sort of micro-transaction approach where the file is downloaded in small pieces. Or alternatively, another good approach may be to have the server some how pay nodes who redistribute their files.

The interesting thing about this overall system is that domains can have a coin balance associated with them, since the domains are addresses, or they map to addresses. So if servers pay nodes who redistribute their files, then it's much like paying for normal server bandwidth, and if the balance of the server address reaches 0 it will be removed from the account tree, meaning it will be removed from the DNS database. However I don't think we need a protocol for forcing servers to pay nodes who redistribute their files, because if a server stops paying fairly people will simply stop sharing their files and look else where for a better profit. The main issue with this approach however is that nodes must be able to prove they are sharing the files, and we can't use recent innovations related to proof-of-storage because holding the files on disk is simply not enough, they must be shared.

Anyway I wanted to keep this post brief, so I'll leave it there and await some thoughts and feedback on what I have presented so far. Hopefully I have presented some original ideas, and hopefully some of you guys will have some interesting expansions and modifications of these ideas, especially in relation to the reward system for redistribution nodes, because I haven't really done much thinking on that topic. I wont be able to work on implementing any of these ideas since I am already focused on Cryptonite right now, I'm mainly just posting this because a few people on the Cryptonite IRC were interested in it and I thought it was worth sharing. But I do think this system could work very well and I highly encourage any interested parties to give it a shot, I will help however I can. A fast and secure decentralized internet layer would be extremely popular and it's something we really need in my opinion.

^^^

this guy missed the email about not innovating stagnating and creating a "payment system" meme.

[bitfreak!]

this guy missed the email about not innovating stagnating and creating a "payment system" meme.

Lol I'm not sure if that's a compliment or insult.

[digitalindustry]

this guy missed the email about not innovating stagnating and creating a "payment system" meme.

Lol I'm not sure if that's a compliment or insult.

compliment friend.

you are probably sealing some spot in human history.

[bitfreak!]

this guy missed the email about not innovating stagnating and creating a "payment system" meme.

Lol I'm not sure if that's a compliment or insult.

compliment friend.

you are probably sealing some spot in human history.

I just think a lot about problems such as this, the trick is to stop learning and start thinking.

Forget what you know: Jacob Barnett at TEDxTeen

[digitalindustry]

this guy missed the email about not innovating stagnating and creating a "payment system" meme.

Lol I'm not sure if that's a compliment or insult.

compliment friend.

you are probably sealing some spot in human history.

I just think a lot about problems such as this, the trick is to stop learning and start thinking.

Forget what you know: Jacob Barnett at TEDxTeen

want 50,000 Quark ( or know someone that does? )

prepared to raise this also.

https://bitcointalk.org/index.php?topic=726374.0

even any feedback would be helpful.

as for your idea (both the mini and the decentralized place holder) i think they are genius and winners, interested to see how testing goes -

[CoinHoarder]

Congrats on the cryptonite launch. I was pretty excited the other day when I saw it had launched.

I haven't read over your whole OP yet, but something caught my eye. If Storj (or maidsafe or ..) are as slow as you assume in you OP, what would be the point of them in the first place? I think you may be selling them a little short.

That said it seems like the redirection idea may work, but it may make it take longer than necessary to develop websites if you need to set this redirection up for every image/file, which adds an extra step.

[bitfreak!]

I haven't read over your whole OP yet, but something caught my eye. If Storj (or maidsafe or ..) are as slow as you assume in you OP, what would be the point of them in the first place? I think you may be selling them a little short.

No storj is fast for downloading large files, just like using torrents to download a file can be very fast with enough peers. But I'm assuming storj is less good at is serving files extremely quickly, because it takes time to actually locate the files on the network. Even if it's just a few seconds, that's too long.

That said it seems like the redirection idea may work, but it may make it take longer than necessary to develop websites if you need to set this redirection up for every image/file, which adds an extra step.

You could set it up on what ever files you want to be distributed across the network and not stored on the server. There's no reason you couldn't store all your files on the server and serve them directly to clients instead of redirecting them.

[CoinHoarder]

I haven't read over your whole OP yet, but something caught my eye. If Storj (or maidsafe or ..) are as slow as you assume in you OP, what would be the point of them in the first place? I think you may be selling them a little short.

No storj is fast for downloading large files, just like using torrents to download a file can be very fast with enough peers. But I'm assuming storj is less good at is serving files extremely quickly, because it takes time to actually locate the files on the network. Even if it's just a few seconds, that's too long.

That said it seems like the redirection idea may work, but it may make it take longer than necessary to develop websites if you need to set this redirection up for every image/file, which adds an extra step.

You could set it up on what ever files you want to be distributed across the network and not stored on the server. There's no reason you couldn't store all your files on the server and serve them directly to clients instead of redirecting them.

That makes sense, thanks for clearing that up. As to incentivizing node storage/sharing:

I think the proof that nodes are sharing files should be done by the nodes themselves. They have incentive to prove that other nodes are sharing the files, because if not then they are basically cheating the other nodes. I think it should be randomized which files are checked to prevent gaming of the system, and they should be checked periodically. Servers can split the costs of these checks evenly since it is necessary for the system to work properly. The servers using the most bandwidth (or most files stored) should pay for more of these costs and the servers with the least bandwidth (or least files stored) should pay for less.

[bitfreak!]

I think the proof that nodes are sharing files should be done by the nodes themselves. They have incentive to prove that other nodes are sharing the files, because if not then they are basically cheating the other nodes. I think it should be randomized which files are checked to prevent gaming of the system, and they should be checked periodically. Servers can split the costs of these checks evenly since it is necessary for the system to work properly. The servers using the most bandwidth (or most files stored) should pay for more of these costs and the servers with the least bandwidth (or least files stored) should pay for less.

I'm not exactly sure what you mean, but I don't think it would work very well. The micro-transaction approach I mentioned isn't great either because it makes the user pay for the content they download instead of making the server pay for the bandwidth... but then again that isn't actually such a bad thing, it will make hosting websites much cheaper, and it does actually make quite a bit of sense from an economical perspective. It may also be much simpler to implement than any other solution.

[cryptonit]

lot innovative ideas bitfreak!
im mining ur coin which is by name more like my coin!

DMD Diamond team will research possibilities about a POS able wallet based on miniblockchain

will study the material u provided and maybe get in touch with u if we have a idea how it could be done

[digitalindustry]

a couple of Questions Re the miniBC:

- Does it stay a fixed size (as in storage size) or is this parameter variable?

- what is the current total estimated size? (in MB)

- What would you say (honestly) are the biggest risks to security for the miniBC ( take into account all situations including no cost i.e Bank attacks or even "foreign governments" )

- Can you point me in the direction of where this is outlined ( i browsed the white paper but didn't see this info)

- is the MiniBC in your opinion "Mobile friendly" so with regards to connected "internet of things" devices in the future.  

[bitfreak!]

- Does it stay a fixed size (as in storage size) or is this parameter variable?

Nodes aren't forced to discard old blocks, they can store as much of the blockchain as they want, but they must have at least the last 10k blocks to be properly synced with the network (the block sizes obviously differ, even the maximum block size is dynamic). I'm not sure what the size of the last 10k blocks is, but the account tree is still less than 150 kB.

- What would you say (honestly) are the biggest risks to security for the miniBC ( take into account all situations including no cost i.e Bank attacks or even "foreign governments" )

http://cryptonite.info/wiki/index.php?title=Weaknesses_and_attack_vectors

- is the MiniBC in your opinion "Mobile friendly" so with regards to connected "internet of things" devices in the future.

I doubt running the full client would be "mobile friendly". Much less data is required to sync with the network, but that doesn't reduce the computational cost of things like verifying transactions.

[digitalindustry]

- Does it stay a fixed size (as in storage size) or is this parameter variable?

Nodes aren't forced to discard old blocks, they can store as much of the blockchain as they want, but they must have at least the last 10k blocks to be properly synced with the network (the block sizes obviously differ, even the maximum block size is dynamic). I'm not sure what the size of the last 10k blocks is, but the account tree is still less than 150 kB.

- What would you say (honestly) are the biggest risks to security for the miniBC ( take into account all situations including no cost i.e Bank attacks or even "foreign governments" )

http://cryptonite.info/wiki/index.php?title=Weaknesses_and_attack_vectors

- is the MiniBC in your opinion "Mobile friendly" so with regards to connected "internet of things" devices in the future.

I doubt running the full client would be "mobile friendly". Much less data is required to sync with the network, but that doesn't reduce the computational cost of things like verifying transactions.

thanks for the replies -

re mobile well, at current processing power of mobile devices - however the computational power cost equation for a transaction verification is a "stable parameter" if mobile CPU ability grows ( see recent developments) that could easily change.

Re with the last 10k could you take a ball park guess 4 MB ~ 40 Mb ?

[bitfreak!]

Re with the last 10k could you take a ball park guess 4 MB ~ 40 Mb ?

Some where between 5 and 20 MB I'm guessing.

[mrvegad]

Hi Bitfreak! I would be up for testing this if it gets to that point, when i have more time i will read over what you have posted.

Hopefully your mini blockchain will be used in more crypto developments.

[digitalindustry]

Re with the last 10k could you take a ball park guess 4 MB ~ 40 Mb ?

Some where between 5 and 20 MB I'm guessing.

that's both revolutionary and evolutionary.

[CoinHoarder]

Re with the last 10k could you take a ball park guess 4 MB ~ 40 Mb ?

Some where between 5 and 20 MB I'm guessing.

that's both revolutionary and evolutionary.

Yes, the mini block chain project is awesome.