tgoldenberg/nodecoin

Implementation of Bitcoin / cryptocurrency using NodeJS

NodeCoin

Implementation of Bitcoin / cryptocurrency using NodeJS

Resources

• A blockchain in 200 loc - Medium piece

• Naivecoin: tutorial to build blockchain - actually pretty good

• Pycoin - Bitcoin implementation in Python

• First Commit by Satoshi Nakamoto

• Research into Elliptic Curve Cryptography

• Basic TCP/IP Networking in Node JS

• Mastering Bitcoin - great book on Bitcoin protocols

Getting Started

The following dependencies must be installed before running:

• MongoDB - you can follow the installation instructions here. You will want a db called "nodecoin" that you can access.

• NPM - Node Package Manager - make sure you are on the latest version of NodeJS

Then install the JavaScript dependencies:

npm install

Simply run the start-up script:

npm start

This will add your computer to the pool of computers running NodeCoin. You should see a connection message, after which the program will sync with other computers.

Creating an Address

Once the program is running, in a separate terminal tab, type:

curl -XGET localhost:3000/wallets | python -m json.tool

This will provide all currently available wallet addresses and their balance. If you have not made a transaction, yours will not show up here.

For a specific wallet balance and unspent transaction outputs (UTXO), type:

curl -XGET localhost:3000/wallets/1Nd85AnFYDtaQAG6vF9FVWXFWksG5HuA3M | python -m json.tool

Here you can replace "1Nd85AnFYDtaQAG6vF9FVWXFWksG5HuA3M" with "WALLET_ADDRESS"

You can also generate a new wallet:

curl -XPOST localhost:3000/wallets/new | python -m json.tool

This will provide you with a new:

• privateKey
• publicKey
• publicKeyHash (sha-256 encrypted version of public key)
• privateKeyWif ("WIF" (wallet-import-format) version of private key)
• address (base58-encoded version of publicKeyHash)

You can use the private and public keys to send and recieve NodeCoin.

To send money (the example send 10 satoshis):

curl -XPOST localhost:3000/send -d publicKey=044283eb5f9aa7421f646f266fbf5f7a72b7229a7b90a088d1fe45292844557b1d80ed9ac96d5b3ff8286e7794e05c28f70ae671c7fecd634dd278eb0373e6a3ba -d amount=10 -d privateKey=0fcb37c77f68a69b76cd5b160ac9c85877b4e8a09d8bcde2c778715c27f9a347 -d toAddress=0482a39675cdc06766af5192a551b703c5090fc67f6e403dfdb42b60d34f5e3539ad44de9197e7ac09d1db5a60f79552ce5c7984a3fc4643fb1911f3857d6dd34c | python -m json.tool

Development

To work on the project, the following is recommended:

In one terminal screen, run the compiler:

npm run dev

In another terminal screen, you can run the updated build via:

npm start

The compiler will listen for changes and will update the code immediately. You may have to restart the npm start service for changes to take effect.

Redux

We use redux for local variable storage (get/set behavior)

MongoDB

We use a local MongoDB to store blocks. We can also keep track of UTXO (unspent transaction outputs).

Transactions that are not yet added to the block can be added to the mempool.

Orphan transactions can be added to the orphan transaction pool.

Further, we can create balances for users (by wallet address)

Seed transactions

# check friend balance
curl -XGET localhost:3000/wallets/1PDLNfJq5GAEn5StESZuBpaBe6B3134vmD

# send 10 NTC to friend
curl -XPOST localhost:3000/send -d publicKey=044283eb5f9aa7421f646f266fbf5f7a72b7229a7b90a088d1fe45292844557b1d80ed9ac96d5b3ff8286e7794e05c28f70ae671c7fecd634dd278eb0373e6a3ba -d amount=10 -d privateKey=0fcb37c77f68a69b76cd5b160ac9c85877b4e8a09d8bcde2c778715c27f9a347 -d toAddress=04804a9ed2855fcea0f5b6e23e587a6c6f7159f15c84b9c82474231cfdac04827fac72a36bd0b463fc61c4d66a954aa7d5f95bde970804f81c8d6f712390516fbb | python -m json.tool

# friend send 2 NTC back
curl -XPOST localhost:3000/send -d publicKey=04804a9ed2855fcea0f5b6e23e587a6c6f7159f15c84b9c82474231cfdac04827fac72a36bd0b463fc61c4d66a954aa7d5f95bde970804f81c8d6f712390516fbb -d amount=2 -d privateKey=6128428978e30fc034c95b7b091b373b875bdd73a0acf83c09d37bff72361349 -d toAddress=044283eb5f9aa7421f646f266fbf5f7a72b7229a7b90a088d1fe45292844557b1d80ed9ac96d5b3ff8286e7794e05c28f70ae671c7fecd634dd278eb0373e6a3ba | python -m json.tool

nodecoin's Issues

Program shuts down when IP address changes

If using a public WiFi, the IP address changes.

In the current implementation, the TCP/IP connection depends on the IP address found on start.

If that IP address changes, we have to restart the program from scratch.

On start run, node should connect with all other active nodes

To do this, we will need a "channel" that all nodes subscribe to.

Once subscribed, the node should have access to a list of IP addresses that are active in the channel.

When receiving a new block, node verifies and then sends it out as a verified block

When a new transaction is broadcast to the network (i.e. a new address), the listening node should pick it up and verify it against its own blockchain.

If the verification is successful, it should broadcast the verified transaction to the network.

Each node on the network will then receive the transaction, verify locally and add it to their local blockchain.

What is SEED_BLOCKS use for?

As titled, could you describe a little bit about this env variable? I see when SEED_BLOCKS equals to True, it will try to create a few blocks in the chain. Is it only used for the testing purpose?

Centralized Pusher App Service?

Seems like NodeCoin use Pusher app to perform subscription to find peers? Is it the service that you implement the peer to peer connection?

After connecting to network, user should send request for block headers

On initialization, the program should first look locally to see if block headers are stored.

If they are, they should be set and the last block header should be sent to the channel.

Once the last saved header is sent out, the program should await a response with block headers starting from the last one saved.

Once the program receives the block headers (a max of 50), it should set its "last block header" and reject incoming messages that are not set to it.

As the client accepts the block headers, it should validate their integrity. If any are not validated then the previous state of the chain should be accepted.

When the client receives a chunk of headers less than 50, it can send a verification request that the headers are up-to-date. The network can send a verification that this is true.