clarify parts of readme and include intention to use VDF

This commit is contained in:
Kevin 2020-06-30 17:05:11 -05:00
parent 3f13cd84ea
commit e174b4a636
1 changed files with 10 additions and 8 deletions

View File

@ -4,11 +4,13 @@
<p align="center">Anonymous, Decentralized, Distributed Network</p>
June 2020
# Introduction
We believe that the ability to communicate freely with others is crucial for maintaining societal and personal liberty. The internet has provided humanity with the ability to spread information globally, but there are many persons and organizations who try to stifle the flow of information, sometimes with success.
Internet censorship comes in many forms, state censorship, corporate consolidation of media, threats of violence, network exploitation (e.g. denial of service attacks) and other threats.
Internet censorship comes in many forms, state censorship, threats of violence, network exploitation (e.g. denial of service attacks) and others.
We hold that in order to protect individual privacy, users must have the ability to communicate anonymously and with decentralization.
@ -64,6 +66,8 @@ Metadata defines what kind of data is in a block, signature data, encryption set
Optionally, a random token can be inserted into the metadata for use in Proof of Work.
The proof of work function should be a Verifiable Delay Function (VDF). We have chosen MiMC for it's simplicity.
### Block Encryption
For encryption, Onionr uses ephemeral Curve25519 keys for key exchange and XSalsa20-Poly1305 as a symmetric cipher or optionally using only XSalsa20-Poly1305 with a pre-shared key.
@ -84,9 +88,7 @@ Blocks are stored indefinitely until the allocated space is filled, at which poi
## Block Timestamping
Onionr can provide evidence of when a block was inserted by requesting other users to sign a hash of the current time with the block data hash: sha3_256(time + sha3_256(block data)).
This can be done either by the creator of the block prior to generation, or by any node after insertion.
Onionr blocks are by default not accepted if their timestamp is set too far in the past, or is in the future.
In addition, randomness beacons such as the one operated by [NIST](https://beacon.nist.gov/home), [Chile](https://beacon.clcert.cl/), or the hash of the latest blocks in a cryptocurrency network could be used to affirm that a block was at least not *created* before a given time.