-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
44 additions
and
53 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,67 +1,58 @@ | ||
[![Review Assignment Due Date](https://classroom.github.com/assets/deadline-readme-button-24ddc0f5d75046c5622901739e7c5dd533143b0c8e959d652212380cedb1ea36.svg)](https://classroom.github.com/a/bWLxfecg) | ||
# Summer of Bitcoin 2024: Mine your first block | ||
# **Code Challenge 2024 Solution** | ||
## **Author - pred695** | ||
|
||
## Overview | ||
In this challenge, you are tasked with the simulation of mining process of a block, which includes validating and including transactions from a given set of transactions. | ||
The repository contains a folder `mempool` which contains JSON files. | ||
These files represent individual transactions, some of which may be invalid. Your goal is to successfully mine a block by including only the valid transactions, following the specific requirements outlined below. | ||
### Design Approach - Steps I took to create a valid block | ||
|
||
## Objective | ||
Your primary objective is to write a script that processes a series of transactions, validates them, and then mines them into a block. The output of your script should be a file named `output.txt` that follows a specific format. | ||
### Code Structure: | ||
All the structs used in the implementation are stored in the `Structs` package in the file `struct.go` file. | ||
All the functions used throughout the implementation are stored in the `Utils` package under relevant files stated below. | ||
The `coinbase.go` file contains the generation of the coinbase transaction. | ||
The `merkle.go` file contains the code for the generation of Merkle root for the whole block and as well as the witness merkle. | ||
The `prioritize.go` file contains the code that implements the sorting algorithm which sorts transactions according to their `fee/weight` ratio. | ||
The `weight.go` file contains the code for calculating the weight of the transactions in the mempool. | ||
The `util.go` file contains the basic utility functions used throughout the implementation. | ||
The `Validation` package contains the address validation implementation for various locking scripts. | ||
The `Blockchain` package contains the code that runs the proof of work for the whole block in `pow.go` and the block mining code is there in `mine.go` file. This code generates the `output.txt` file. | ||
|
||
## Requirements | ||
### Input | ||
- You are provided with a folder named `mempool` containing several JSON files. Each file represents a transaction that includes all necessary information for validation. | ||
- Among these transactions, some are invalid. Your script should be able to discern valid transactions from invalid ones. | ||
### Steps taken for generating the mined block. | ||
|
||
### Output | ||
Your script must generate an output file named `output.txt` with the following structure: | ||
- First line: The block header. | ||
- Second line: The serialized coinbase transaction. | ||
- Following lines: The transaction IDs (txids) of the transactions mined in the block, in order. The first txid should be that of the coinbase transaction | ||
#### a) Serialization: | ||
There are two types of serialization used in my implementation. One is segwit serialization and the other is non segwit serialization. | ||
1) `func SerializeTransaction(tx *Structs.Transaction) ([]byte, error)`-> Returns the serialized transaction without including the witness data. | ||
2) `func SegWitSerialize(tx *Structs.Transaction) ([]byte, error)` -> Returns the serialized transaction including the witness data. | ||
3) `func SerializeBlockHeader(bh *Structs.BlockHeader) []byte ` -> Returns the serialized block header. | ||
|
||
### Difficulty Target | ||
The difficulty target is `0000ffff00000000000000000000000000000000000000000000000000000000`. This is the value that the block hash must be less than for the block to be successfully mined. | ||
### b) Generation of TxIDs: | ||
1) TxIDs are generated by the non segwit serialized data if the output is double hashed with sha256 algorithm. | ||
An example from code: `txid := to_sha(to_sha(serialized))` where `to_sha` function implements sha256 algorithm on a stream of bytes. and the `serialized` variable is the output of the non segwit serialization. | ||
This txid generated is in the big endian format. It is transformed into the little-endian format by using the `ReverseBytes` function defined in the `serialize.go` file in `Utils` package. | ||
|
||
The txids generated are used further for calculation of Merkle Root of the included transactions. | ||
2) WTxIDs are generated by the segwit serialized data if the output is double hashed with sha256 algorithm. | ||
An example from code: `wtxid := to_sha(to_sha(segserialized))` where segserialized is the segwit serialized data of the transactions. The WTxIDs for a non segwit transaction is same as that of the segwit transaction because of the absence of the witness data. | ||
The coinbase transaction in our case is a segwit transaction as the mempool contains many segwit transactions and I am also including many segwit transaction in my block. | ||
|
||
### c) Construction of Merkle Root and Witness Commitment: | ||
1) The function `func NewMerkleTree(leaves []string) *Structs.MerkleNode` is used for creating the merklee tree. It returns the merkle root of all the transactions which is of the type `MerkleNode` defined in the `Structs` package. The `leaves` are the TxIDs in string format. | ||
2) The function `func CreateWitnessMerkle() string` is used for creating the witness merkle of the block to be constructed. It returns the witness commitment which is included in the Coinbase Transaction. Code snippet of witness commitment generation | ||
`commitment_string := hex.EncodeToString(merkleRoot.Data) + "0000000000000000000000000000000000000000000000000000000000000000"`. | ||
|
||
## Execution | ||
- Create a file named `run.sh` that contains the command to execute your script. This file should ideally contain a single command like `python main.py` or `node index.js`. | ||
- Your script should autonomously perform all tasks when `run.sh` is executed, without requiring any manual intervention. | ||
### d) Construction of Blockheader: | ||
1) The blockheader is constructed in the `mine.go` function in the `Blockchain` package. It is of the type `BlockHeader` defined in `struct.go` file in the `Structs` package. | ||
2) This blockheader is put in the first line of `output.txt` in the serialized form. The serialization function of the Blockheader is `func SerializeBlockHeader(bh *Structs.BlockHeader) []byte`. | ||
|
||
## Evaluation Criteria | ||
Your submission will be evaluated based on the following criteria: | ||
### e) Proof of Work Algorithm: | ||
This is implemented in the `pow.go` file in the `Blockchain` package. | ||
|
||
- **Score**: Your code output will be scored bases on the fee collected and the amount of available block space utilised. **You must score at least 60 points to pass the challenge.** | ||
- **Correctness**: The `output.txt` file must be correctly formatted in the manner described above. | ||
- **Code Quality**: Your code should be well-organized, commented, and follow best practices. | ||
- **Efficiency**: Your solution should process transactions and mine the block efficiently. | ||
### f) Construction of Coinbase Transaction: | ||
The coinbase transaction is constructed in the `coinbase.go` in the `Utils` package. | ||
|
||
## Document your work | ||
### g) Fractional Knapsack Algorithm: | ||
The algorithm to gain the maximum fee by including the transactions which had relatively higher `fee/weight` ratio is implemented in the `prioritize.go` file in the `Utils` package. It sorts the transactions in the decreasing order of the fee to weight ratio and keep including them one by one until the Block weight reaches close to the maximum of `4000000`including the coinbase transaction which came out be 660 wu in my case. | ||
|
||
Apart from the code, you must also publish a `SOLUTION.md` file explaining your solution in the following format: | ||
- **Design Approach:** Describe the approach you took to design your block construction program, explain all the key concepts of creating a valid block. | ||
- **Implementation Details:** Provide pseudo code of your implementation, including sequence of logic, algorithms and variables used etc. | ||
- **Results and Performance:** Present the results of your solution, and analyze the efficiency of your solution. | ||
- **Conclusion:** Discuss any insights gained from solving the problem, and outline potential areas for future improvement or research. Include a list of references or resources consulted during the problem-solving process. | ||
### Flow: | ||
Serialize transactions -> Generate Transaction IDs -> Perform Address Validation -> Generate Witness Transaction IDs -> Pick up transactions according to the Fractional Knapsack Algorithm in a greedy manner -> Construct the witness commitment for the Coinbase Tx -> Create a Valid Coinbase transaction -> Construct the Merkle Root of the included transactions -> Run the proof of work algorithm -> Generate the output.txt file once the block is mined. | ||
|
||
## What NOT to Do | ||
|
||
In this challenge, it's crucial to understand and adhere to the following restrictions. These are put in place to ensure that you engage with the core concepts of bitcoin and apply your problem-solving skills to implement the solution from first principles. | ||
|
||
- **Do Not Use Bitcoin Libraries for Transaction Validation:** You must not use any Bitcoin-specific libraries or frameworks that automate transaction validation processes. The intent of this challenge is for you to understand and implement the validation logic manually. | ||
- **Permissible Libraries:** The use of standard cryptographic libraries, such as secp256k1 for elliptic curve cryptography, and standard hashing libraries (e.g., for SHA-256) is allowed and encouraged. These libraries are essential for implementing the cryptographic underpinnings of bitcoin without reinventing the wheel. | ||
- **Implement the Mining Algorithm Yourself:** You are required to implement the mining algorithm on your own. This includes creating a way to correctly form a block header, calculate the hash, and meet the challenge of finding a hash below a certain target. | ||
|
||
### Plagiarism Policy: | ||
Our plagiarism detection checker thoroughly identifies any instances of copying or cheating. Participants are required to publish their solutions in the designated repository, which is private and accessible only to the individual and the administrator. Solutions should not be shared publicly or with peers. In case of plagiarism, both parties involved will be directly disqualified to maintain fairness and integrity. | ||
|
||
### AI Usage Disclaimer: | ||
You may use AI tools like ChatGPT to gather information and explore alternative approaches, but avoid relying solely on AI for complete solutions. Verify and validate any insights obtained and maintain a balance between AI assistance and independent problem-solving. | ||
|
||
## Why These Restrictions? | ||
These restrictions are designed to deepen your understanding of bitcoin technicals. | ||
By completing this assignment, you will gain hands-on experience with the technology that make bitcoin secure and trustless. | ||
Remember, the goal of this challenge is not just to produce a working solution but to engage critically with the fundamental components of bitcoin. This is an opportunity to showcase your problem-solving skills and your ability to implement complex algorithms from scratch. | ||
|
||
## Additional Information | ||
- This challenge is designed to test your understanding of bitcoin fundamentals, including transaction validation and block mining processes. | ||
- While the challenge focuses on the simulation of these processes, you are encouraged to implement your solution in a way that demonstrates depth of understanding and creativity. |