There is no solid plans on blockchain connection yet and I think it would be bad idea to build on a coin that is created by an unknown identity. If we ever choose to create our cryptocurrency probably we will distribute it to the current users/node runners/supporters/site developers.

As a proof a message signed with ZeroNet client's homepage public address:

Address: 1HeLLo4uzjaLetFx6NH3PMwFP3qbRbTf3D
Message: The ZeroNet project is not affiliated with https://bitcointalk.org/index.php?topic=2207595.0
Signature: HPaXGTakW3e7oRWXTUiFZ37ZFwu0T7B3dfJCJcTVggmhbX9ZwPRh2Vq4XjIhhPlgvNNAQra1VZI5vV6 gESo+lSA=

You can verify it using eg.: https://tools.bitcoin.com/verify-message/

I just want to make it clear that it's not connected with the project in any way.

Just to make it clear: The ZeroNet project and the developers of it is not connected with this coin in any way.

- Nofish (main dev of ZeroNet)

Freenet is slow and only support static content, but more anonymous. ZeroNet is made for fast, dynamic, multi-user sites, it provides less anonymity, but now comes with full Tor network support, so you can hide your IP easily if necessary.

https://zeronet.io works similarly:

- Namecoin .bit domains
- The sites ownership protected by same cryptography as Bitcoin (the site address is also a valid Bitcoin address, you can also use it as wallet)
- Full Tor support to hide your IP (.onion peers)
- BIP32 (HD wallet) based user identity
- Multi-user sites, working examples: Reddit-like forum, Blog with comments, Email-like end-to-end encrypted messaging (ECIES+AES)

My old core2duo cpu able to decrypt ECC + AES at 100messages/sec (first solution) and AES over 10000messages/sec (second solution), so I don't think its going to be a problem. Every site in zeronet is totally independent, so if the updating/verification become problematic anyone able to clone the site and creating a new network of messages.


To solve this we could add fixed prefix to the encrypted text, eg.: os.urandom(16)+"ZNE1"+message
The random needed because according to stackexchange it should be avoided to start the messages with same text. (we going to use AES CBC mode)

Hello, I developing an encrypted messaging for ZeroNet (http:/zeronet.io) and would like to have some guidelines.

My first idea:

• In ZeroNet every user has his/her own files signed by ECC this ensures the messages authenticity.
• When Bob visits the site first time a new (BIP32 based) public key will be generated, written to his file, signed and published to the network.
• If Alice want to message to Bob then reads the Bob's public key, then creates a new message using `ecc_encrypt_using_bob_pubkey("ZNE1" + generated_aes256key + generated_aes256iv + aesencrypted_text)`, puts it to her file, sign and publish to network.
• If a new file is published to the network then Bob checks the added messages in it and try to them using his ECC privatekey.

 To make privacy better the sender does not specify the messages recipient.
 So the messages are signed with one ECC private key and encrypted with an another.

My other idea:

• If Alice wants to send a message to Bob, then she puts `ecc_encrypt_using_bob_pubkey("ZNE1" + generated_aes256key + generated_aes256iv)` encrypted shared secret to her file.
• Then from now Alice will use this shared secret to encrypt messages to Bob
• If a new file is published Bob checks encrypted shared secrets and see if he able to decrypt any of it.
• If he successfully decrypt a shared AES secret from Alice file then he checks Alice's encrypted messages and decrypt the messages she sent to him.

 This way the same AES256 key would be used for every message, so it reduces encrypted messages length by AES256key+iv / message.

 Thanks for any suggestions!

Whats going on with XMR? It's got frozen again. Please keep us informed, its important to keep up the trust.

Attól függ mit értesz használaton, tippjeim:
 - Van legalább 0.1 BTC-je: 5000
 - Használta már vásárlásra: 3000
 - Rendszeresen, havonta többször használja: 1000