We generate our private and public keys in a KeyPair. We will use Elliptic-curve cryptography to Generate our KeyPairs. Let’s append a generateKeyPair() method to our Wallet class and call it in the constructor:

All you need to understand about this method is it uses Java.security.KeyPairGenerator to generate an Elliptic Curve KeyPair. This methods makes and sets our Public and Private keys. Nifty.

Now that we have the outlines of our wallet class let’s have a look at transactions.

NoobCoin > Cash ? :D

2. Transactions & Signatures

Each transaction will carry a certain amount of data:

The public key(address) of the sender of funds.

The public key(address) of the receiver of funds.

The value/amount of funds to be transferred.

Inputs, which are references to previous transactions that prove the sender has funds to send.

Outputs, which shows the amount relevant addresses received in the transaction. ( These outputs are referenced as inputs in new transactions )

A cryptographic signature, that proves the owner of the address is the one sending this transaction and that the data hasn’t been changed. ( for example: preventing a third party from changing the amount sent )

Let’s create this new Transaction class:

We should also create empty TransactionInput and TransactionOutput classes, don’t worry we can fill them in later.

Our transaction class will also contain relevant methods for generating/verifying the signature and verifying the transaction.

But wait…

What is the purpose of signatures and how do they work ?

Signatures perform two very important tasks on our blockchain: Firstly, they allow only the owner to spend their coins, secondly, they prevent others from tampering with their submitted transaction before a new block is mined (at the point of entry).

The private key is used to sign the data and the public key can be used to verify its integrity.

For example: Bob wants to send 2 NoobCoins to Sally, so their wallet software generates this transaction and submits it to miners to include in the next block. A miner attempts to change the recipient of the 2 coins to John. However, luckily, Bob had signed the transaction data with his private key, allowing anybody to verify if the transaction data has been changed using Bob’s public key (as no other persons public key will be able to verify the transaction).

We can see (from the previous code block,) that our signature will be a bunch of bytes, so let’s create a method to generate them. First thing we will need are a few helper functions in StringUtil class :

Don’t worry too much about understanding the contents of these methods. All you really need to know is : applyECDSASig takes in the senders private key and string input, signs it and returns an array of bytes. verifyECDSASig takes in the signature, public key and string data and returns true or false if the signature is valid. getStringFromKey returns encoded string from any key.

Now let’s utilize these signature methods in our Transaction class, by appending a generateSignature() and verifiySignature() methods:

In reality, you may want to sign more information, like the outputs/inputs used and/or time-stamp ( for now we are just signing the bare minimum )

Signatures will be verified by miners as a new transaction are added to a block.

We also can check signatures, when we check the blockchain’s validity

3.Testing the Wallets and Signatures:

Now we are almost halfway done Let’s test a few things are working. In the NoobChain class let’s add some new variables and replace the content of our main method :

be sure to remember to add boncey castle as a security provider.

We created two wallets, walletA and walletB then printed walletA’s private and public keys. Generated a Transaction and signed it using walletA’s private key. ̶F̶i̶n̶a̶l̶l̶y̶ ̶w̶e̶ ̶c̶r̶o̶s̶s̶e̶d̶ ̶o̶u̶r̶ ̶f̶i̶n̶g̶e̶r̶s̶ ̶a̶n̶d̶ ̶h̶o̶p̶e̶d̶ ̶e̶v̶e̶r̶y̶t̶h̶i̶n̶g̶ ̶w̶o̶r̶k̶e̶d̶ ̶o̶u̶t̶.̶

Your output should look something like this :

‘Is signature verified’ should be true. Hopefully.

Time to pat your self on the back. Now we just need to create/verify the outputs and inputs and then store the transaction in the Blockchain.

4. Inputs & Outputs 1: How crypto currency is owned…

For you to own 1 bitcoin, you have to receive 1 Bitcoin. The ledger doesn’t really add one bitcoin to you and minus one bitcoin from the sender, the sender referenced that he/she previously received one bitcoin, then a transaction output was created showing that 1 Bitcoin was sent to your address. (Transaction inputs are references to previous transaction outputs.).

Your wallets balance is the sum of all the unspent transaction outputs addressed to you.

From this point on we will follow bitcoins convention and call unspent transaction outputs: UTXO’s.

So let’s create a TransactionInput Class:

This class will be used to reference TransactionOutputs that have not yet been spent. The transactionOutputId will be used to find the relevant TransactionOutput, allowing miners to check your ownership.

And a TransactionOutputs Class:

Transaction outputs will show the final amount sent to each party from the transaction. These, when referenced as inputs in new transactions, act as proof that you have coins to send.

5. Inputs & Outputs 2: Processing the transaction…

Blocks in the chain may receive many transactions and the blockchain might be very, very long, it could take eons to process a new transaction because we have to find and check its inputs. To get around this we will keep an extra collection of all unspent transactions that can be used as inputs. In our NoobChain class add this collection of all UTXOs:

HashMaps allow us to use a key to find a value, but you will need to import java.util.HashMap;

Okay, time to get down to the nitty gritty…

Let’s put everything together to process the transaction with a processTransaction boolean method in our Transaction Class:

we also added a getInputsValue float method.

…With this method we perform some checks to ensure that the transaction is valid, then gather inputs and generating outputs. (See commented lines in the code for more insight).

Importantly, towards the end, we discard Inputs from our list of UTXO’s, meaning a transaction output can only be used once as an input… Hence the full value of the inputs must be used, so the sender sends ‘change’ back to themselves.