suen / dheba Goto Github PK

After HANDSHAKE_ACT message has been sent, the receiving peer should establish a connection with the connecting peer.

The connecting peer should not create another connection.

Create a config file of type key-value to put all hard coded configuration in it.

Implement Block exchange protocol.

After nodes have established their connection, they verify if the remote node has longest chain than them. If so, the node asks for the missing block by issuing a request to get the next block that comes after the best block it has. It continues until the length of the remote chain and its local chain length is same.

See the Bitcoin getblock as reference to determine the message format

For the minimum usable version, implement a dummy transaction to be used to create block.

An input in a transaction references an output from another transaction that hasn't already been spent. To speed up the validation of a transaction, it is better to have unspent transaction output indexed for quick lookup.

A transaction is composed of inputs and outputs. Expressed in form of scripts, the input and output acts as unlocking and locking values in the transaction.

With inspiration from Bitcoin transaction, devise a transaction structure.

Currently, there is no convention for the async communciation between Verticles.

Implement the convention as follows:

• A verticle can listen to at most two types of topics. Either a specific topic of which it is the only destination or a generic topic where many verticles could be listening.
• A specific topic is to be used when the message being passed concerns only a specific instance of a Verticle. Every verticle listen to its specific topic. Only the creator of the Verticle knows the specific address of the Verticle and may share with other Verticles.
• A generic topic is to be used when the sendor does not know about the recipient.
• A generic topic may be used to broadcast messages that is of common interest.

Some generic topics to be defined:

Write documentation explaining the event-driven internal architecture and the rationale for it.

• Mine a block locally using a dummy transaction
• Integrate the mined block into the blockchain.
• Mining to be done in a separate component.
• A node may have one or many miners.
• A miner starts mining a block on receiving the message to mine. The message contains the necessary block information (called raw block).
• If a miner receives a new raw block that has index greater than current block it is mining, it will abandon the current mining and start mining the new block.
• A miner should be informed of any block mined by another miners. On receiving the message, the miner stops the current block mining if the new block's index is equal or superior to the the index of block it is currently mining.
• The first implementation is to be done such that a block is found every 5 minute and be as little resource intensive as possible.

Currently, the application supposes that the remote peer is reachable and will behave as expected. If this is not case, there are cascading failures.

After the first handshake message, exchange the addresses of connected peer with the new node.

The bitcoin network exchanges the peer address via "getaddr" and "addr".

Define a message format for addr et getaddr and exchange these messages after the initial handshake.
These messages may be exchanged at any point during the exchange.

Currently, the TCP ports used to listen to P2P connection, HTTP connection and SSH connection are all hard coded which makes running multiple nodes on local machine impossible.

Make these ports customizable via System Properties or environment variable.

The order of priority goes on as follows :
System Properties > Environement Variable > Hard coded default values

if system properties is present, it takes precedence over others, and so on..

The variable names are as follows:

dheba.port.http
dheba.port.ssh
dheba.port.p2p

Sections to include

0. Introduction to project
1. Getting Started
2. Code base structure
3. Contributing

A transaction input is a digital signature proving the ownership of the public key referenced in the transaction output. A standard practice to keep the public and private key pairs in a file called wallet.

Create a wallet model and have every node generate one automatically in the beginning.