Create simulation running with multiple threads. Each thread is a different participant in the blockchain. This simulation will have 1 miner and multiple users all connected. Each user will join the simulation and will send a join message to all nodes, as well as being given the current state of the blockchain. Each will send between 1-5 messages (some individual and some group) before finishing.

This will help to work out any bugs and will allow for a connection interface between participants to be developed.

When using the random 4 addresses functionality, a node should be able to select what nodes it wants to connect to, given a certain role. For example, a miner might want to connect to other miners exclusively when it starts up.

Go through and improve the performance and efficiency of the Blockchain. This may include a number of performance upgrades:

• Reduce the number of .clone() uses
• Restructure code so fewer intermediate variables are used
• Use other rust tricks to improve the performance
• Implement HPC tricks to improve memory usage

Currently not able to determine the health of a connection. This functionality should be added so the node knows if its connections are working, and whether to send a message to the lookup table to get more addresses for other nodes.

Currently there is no way for a user to generate events. Such a way should be created where it adds a ProcessMessage with the created Event into the job queue to send. This should be done in an extensible way such that applications can be built on top of this. It should use a producer model.

A container struct specifically for sending messages should be created. This should be sufficiently general that it will take any struct which implements serialise/deserialise. This struct should then be turned into JSON and have the number of bytes appended to the front of the message. This should be of the form 10|{...}, for example. This allows a socket to correctly read the correct number of bytes in.

This method allows easy conversion back into the correct types that are needed. A further step could be to create a further wrapper enum for any Structs that are to be sent over the interface. That might make it easier to convert them back into the correct structs using match statements.

Cannot acquire read access so is getting caught and not moving forwards in code. This means the message queue is filling up with data.

If a message cannot be sent, there needs to be some way to send them when there are available nodes to pass messages onto

Currently there are a number of tests, but this number needs to be increased. There is a lot of behaviour which isn't well documented and tested so this should be improved.

Generalise the blockchain so it doesn't just store events, but also stores anything which implements the blockchain transaction trait.

When a new user is created, the user should create an event with its address and public key in it so it is saved to the blockchain so all users can see it.

Testing should be performed on a network to ensure it can send and receive messages, and that a miner can create blocks and distribute them, as well as all participants transmitting their blockchain state.

Currently the point of the repo is for a blockchain based chat application. However, the project is now centred around the blockchain more than the chat aspect. The repo should be re-calibrated to reflect this. The current main.rs should be moved into an examples folder and the blockchain folder should be the root of src, with mod.rs becoming lib.rs. The name should also be changed to something more appropriate for the project

Currently events and blocks will bounce between nodes indefinitely. This should be changed so that there are controls around who messages are sent to and when they are relayed.

When a node connects to another, it can send messages, but cannot read them from the stream. This means that connection is only one way.

Every part of the blockchain should have a timestamp when it is created

Store data items in file so on startup the participant can pick up where they last left of. This requires a number of tasks:

• When starting up, check for file containing information of node (RSA keys, blockchain file, id)
• If no data, generate new credentials (better creation of id using RSA keys) and basic blockchain
• When blockchain is expanded, the binary file should be updated to reflect this

When an individual message is sent, it should have its contents encrypted by the users public key so that it can only be read by the intended user.

This should contain option to specify:

• RSA Private/Public Key(s)
• Logging level
• Role (Miner/User)
• Block size
• Multiple profiles using CLI

Currently User and Miner perform basically the same functionality. This should be changed so that they perform seperate jobs in the network and so they have less overlapping code. This makes the code more readable and simple

With the newly implemented passable function, implement a chat functionality which will create Events and will send them to the outbound thread which will pass them onto other nodes. This will use the basic Data enum to define what is stored on the blockchain

Currently nodes cannot discover each other easily. Need to find a way for nodes to communicate and alert each other of other nodes

Currently there are issues with the blockchain, such as IDs and nonces aren't generated in the most secure way. This should change so that the complexity increases to make the blockchain more secure as a whole. The method should be more efficient than the way BitCoin performs mining, maybe something more akin to Ethereum.

To generated nonces and an ID, the RSA key pair should be used so its more individual for each network participant

Currently each account in the blockchain has a u128 as its ID. These should be better addresses

Currently no logging apart from a few print statements, need to add full logging with debug statements

Improve tolerance of network faults to workout if a stream is closed and to add stream timeouts. This could be acheived through exponential backoff.

Rust examples of checking the stream can be seen here

Update the README to reflect recent changes, such as how the CLI works and how config.toml should be structured.

Write integration tests to ensure that networks can be formed and can connect

Currently no way to choose to be a miner or user, add code in main.rs to allow user to specify that in command line