Implementing Cryptocurrency with Block Chains Phase 11 Solution




Youarerequired todevelopessential building blocksofcryptocurrencyusingblockchains.

1 Introduction

The project has three phases:

Developing software for proof of work

Developing software for digital signature

Developing software for other buiding blocks and integration

More information about the phases are given in the subsequent sections.

2 Phase I: Developing software for proof of work

In cryptocurrency systems, miners approve transactions by running the proof-of-work (PoW) algo- rithm. A transaction contains information of a payment from the payer to the payee and is in the following format:

*** Bitcoin transaction *** Serial number:

Payer: Payee: Amount:

Previous hash in the chain: Nonce:

Proof of Work:

Explanations of these fields are as follows

Serial Number: is a uniformly randomly generated 128-bit integer;

Payer: is the identity of the person making the payment;

Payee: is the identity of the person receiving the payment;

Amount: is the amount in Satoshi being transferred;

Previous hash in the chain: is the hash of the last transaction in the chain

Nonce: is a uniformly randomly generated 128-bit integer, which miners change to find the PoW

for transactions.

Proof of Work: is the hash of transactions whose first digits of certain length are all 0. This is written in hexadecimal format.

The following is an example of a block chain generated for three transactions:

*** Bitcoin transaction ***

Serial number: 212263538645046771822600700406703677780

Payer: Erkay Savas Payee: 2KQMHBX7LR Amount: 241 Satoshi

Previous hash in the chain: First transaction

Nonce: 295735282256603556348499786196010373709

Proof of Work: 00000042e244ebcdf74f456c35f674d18d014b1317c335beb717fb6af3012403

*** Bitcoin transaction ***

Serial number: 15406649440213522152658022974697492647

Payer: Erkay Savas Payee: JJCHLE0S8S Amount: 353 Satoshi

Previous hash in the chain: 00000042e244ebcdf74f456c35f674d18d014b1317c335beb717fb6af3012403

Nonce: 229011888470430239833581862495372060758

Proof of Work: 00000039f0eb03ca50d6d7399717962e47f1189b70fc5b4abfea1c6df4436100

*** Bitcoin transaction ***

Serial number: 134664886688001698414829205535324634147

Payer: Erkay Savas Payee: 8O41AGH4QM Amount: 711 Satoshi

Previous hash in the chain: 00000039f0eb03ca50d6d7399717962e47f1189b70fc5b4abfea1c6df4436100

Nonce: 174041738328075334247840790160731353141

Proof of Work: 000000b48355d57cf79a79801ec96cbd83716b144a0d2896a9078a14b39fa202

As can be observed from this example, all PoWs start with six 0s. This can be achived by miners generating different Nonce values until one hash satisfying this condition is found. PoW is the hash of the first seven lines of a transaction excluding the last line. In the example we use SHA3 with

256-bit output as the cryptographic hash function in python module hashlib.

In this phase of the project, you will generate random transactions following the format de- scribed above. You are required to use SHA3 with 256-bit output as the cryptographic hash function. For the sake of simplicity, you need to provide a PoW for a single transcation as in the example in the file “LongestChain.txt” attached to the assignment package. You need to generate at least ten transactions and write them to a file.

You are required to submit your python source code(s) that you used to generate transactions and their PoWs along with a file that contains at least ten transactions. The transactions in your file should be in the format as the example transactions in the file “LongestChain.txt”. Note that we will use the python code” in the attachment to validate your transactions. Before you submit your work, you are advised to use it to check if your transactions are good.

For more information about cryptocurrencies see the attached document “bitcoin.pptx”.

3 Phase II: Developing software for digital signature

In this phase of the project, you will develop software for signing a bitcoin transaction. For digital signature you will use a digital signature algorithm (DSA) which consists of four functions as follows:


Parameter generation: Two prime numbers p and q are generated with q|p 1, where q and p are 256-bit and 2048-bit integers, respectively. The generator g generates a subgroup of Z with q elements. Naturally, gq 1 mod p. Note that in your system q, p, and g are domain parameters shared by all users, who have different secret/public key pairs. Refer to the slide number 13 in chapter 10 for an efficient method for parameter generation.

Key generation: A user picks a random secret key 0 < α < q and computes the public key β = gα mod p.

Signature generation: Let m be an arbitrary length message. The signature is computed as follows:

h = SHA3 256(m)

h = h mod q

r = (gk mod p) mod q, where 0 < k < q is random integer.

s = α · r + k · h mod q

The signature for m is the tuple (r, s).

Signature verification: Let m be a message and the tuple (r, s) is a signature for m. The verificiation proceeds as follows:

h = SHA3 256(m)

h = h mod q

v = h1 mod q

z1 = s · v mod q

z2 = (q r) · v mod q

u = gz1 · βz2 mod p

Accept the signature only if r = u mod q

Reject it otherwise.

Note that the signature generation and verification of this DSA are different than those discussed in the lecture.

You will sign a randomly generated bitcoin transaction using DSA. The transaction not only contains information about the bitcoin transfer, but also domain parameters and the public key of the payer. See “SingleTranscation.txt” file for details. The user will hash the first nine lines and sign the resulting hash value. The last two lines are the signature tuple.

You will be expected to provide the following delivarables:

1. A python function and its output file “DSA params.txt” which contains q, p, and g. The format of the file must be the same as the example file “DSA params.txt” in the attachment.

2. A python function and its output files “DSA skey.txt” and “DSA pkey.txt” which contain (q, p, g, α), and (q, p, g, β), respectively. The formats of the files must be the same as the example files “DSA skey.txt” and “DSA pkey.txt” in the attachment.

3. A python function and its output file “SingleTransaction.txt”. See the example file “Single- Transcation.txt” file for details.

4. A python function that reads “SingleTransaction.txt” file and check if the signature is valid for this transaction.

We will use the attached python program “DSA” to test the corretness of the content of the files “DSA params.txt”, “DSA skey.txt”, “DSA pkey.txt’, and “SingleTransaction.txt”. For this, you need to provide code for DSA functions and generating random transaction in python files “” and “”. In addition, the function names and API should match those provided in “DSA”. For example, for DSA parameter generation your function name and its API should be

q, p, g = DSA.DL_Param_Generator(small_bound, large_bound),

where small bound = 2256 and large bound=22048 .


4 Developing software for other buiding blocks and integration

Details will be provided in the third phase of the project

5 Appendix I: Timeline & Deliverables & Weight & Policies etc.

Pro ject Phases


Due Date


Project announcement


First Phase

Source codes,

Block chain file, Readme file



Second Phase and

DSA params.txt, DSA skey.txt

DSA pkey.txt , SingleTransaction.txt



Third Phase




5.1 Policies

You may work in groups of two (at most three)

You may be asked to demonstrate a project phase to a TA or the instructor.

In every phase, we will provide you with a validation software in python language that can be used to check your implementation for correctness. We will also use it to check your implementation. If your implementation in a project phase fails to pass the validation, you will get no credit for that phase.