The document describes a project to develop a client-server application simulating a simplified Bitcoin system using socket programming in Python. It outlines the roles of client and server programs, user authentication, transaction creation, and balance updates, along with a structured example of user interaction and transaction processing. The document also includes specific testing instructions and expected outputs from the system's functionality.

1. ​ 
In python
​ We implement this project with UDP.
​ Note: At the client program, change the server to “localhost”. 
Then you can
run the server and
​ multiple clients at different terminals all at the same machine.
​ 3. 
Project Objective:
​ In this project, you will develop a client-server application that
implements a simplified Bitcoin using socket programming in Python
language.
​ 4. 
Implement a simplified Bitcoin
​ In this document, TX refers to a transaction and BTC refers to a Bitcoin.
​ In this project, we define 2 
programs: (1) 
client.py, (2) 
server.py
​ The server program stores two lists: (1) 
a list of users, (2) 
a list of
confirmed Transactions (TXs).
​ We assume we have 4 
users with usernames: (1) 
A, (2) 
B, (3) 
C, (4) 
D. 
For
simplicity, we assume
​ each user’s password is the same as its username. The server program
stores a list of these 4
​ users. For each user, the server stores username, password, and current
balance. We assume the
​ 2
​ initial balance for each user is 10 
BTC. 
When a user’s balance changes,
the server updates that in
​ its users list.
​ The server also stores a list of confirmed TXs. 
Each TX has 1 
payer and
1-2 
payee(s) 
and the
​ amount that the payer has paid, and each payee has received. Initially this
list is empty.
​ A client program is a user’s wallet. When the user runs the client program,
the client program
​ asks the user to enter a username and password and sends them to the
server for authentication.

2. ​ Then, the server looks up them in its list of users and if it finds a match, the
user is authenticated.
​ The server responds the client whether the user is authenticated or not. If
authenticated, the
​ sever will also send the user’s current balance and a list of TXs in which
the user has been a payer
​ or a payee. When the client program receives the response, it will display a
message on the
​ screen that the user is authenticated or not.
​
​ 1. 
If the user is not authenticated, the client program displays a menu of
two options:
​ a. 
Enter the username and password again,
​ b. 
Quit the program.
​ 2. 
If the user is authenticated, the client program will do the following.
​ a. 
Prompt a message indicating that the user is authenticated and the
user’s current
​ balance.
​ b. 
Store the user’s current balance.
​ c. 
Store the user’s confirmed TXs in its list.
​ d. 
Display the list on the screen. The list should show up as a table of rows
and
​ columns, not as a sequential list of statements. This table initially has no
rows.
​ The client stores the user’s username, current balance, and a list of the
user’s TXs, 
consisting of

3. ​ the TXs where the user has been a payer or a payee. Each TX in this list
has a status, either (1)
​ temporary, (2) 
confirmed, or (3) 
rejected. When a client initiates a TX, 
it
stores that with (1)
​ temporary status and sends it to the server. When the client receives a
response for a TX from
​ the server, it will change the TX’s status to either (2) 
confirmed or (3)

rejected according to the
​ server’s response.
​ The structure of a TX is as follows.
​ 1. 
TX id
​ 2. 
Payer (A or B or C or D)
​ 3. 
The amount transferred by Payer
​ 4. 
Payee1
​ 5. 
The amount received by Payee1
​ 6. 
Payee2 (optional)
​ 7. 
The amount received by Payee2 (optional)
​ We assume user A’s TXs start with 100, 
user B’s TXs start with 200, 
user
C’s TXs start with 300,
​ and user D’s TXs start with 400.
​ 3
​ Some examples of TXs are as follows.
​ 100: A transferred 1BTC. 
B received 1BTC.
​ 101: A transferred 2BTC. 
B received 1BTC. 
C received 1BTC.
​ 400: D transferred 3BTC. 
B received 2BTC. 
C received 1BTC.
​ When a user is authenticated, the client program displays a menu of 3

options to the user.
​ (1) 
Make a transaction.
​ (2) 
Fetch and display the list of transactions.
​ (3) 
Quit the program.
​ If the user selects “Make a transaction”, 
the client program finds the
highest TX id in the list of
​ TXs where the user is a Payer. Then increments that by 1 
to get the TX id
for the new TX. 
If there

4. ​ is none, this is the user’s first TX. 
Assign TX id 100 
if the user is A, 200 
if
the user is B, 300 
if the
​ user is C, 
and 400 
if the user is D.
​ The Payer will be the current user. The client program asks the following
questions.
​ 1. 
How much do you transfer?
​ 2. 
Who will be Payee1? (if the current user is A, 
give 3 
options: 1.B, 2.C,
3.D).
​ 3. 
How much Payee1 
will receive? (if this value is more than the amount
paid by Payer,
​ display the transferring amount and ask the user to enter a value less than
or equal to
​ that. If the entered value is equal to the total transferring amount, skip the
next question)
​ 4. 
Who will be Payee2? (if the current user is A and Payee1 
is B, 
give 2

options: 1.C, 2.D).
​ 5. 
Do not ask any other question. Display the amount that Payee2 
will
receive, which is the
​ transferring amount minus the amount Payee1 
will receive.
​ Now the client program stores this temporary TX in its list of TXs and
sends it to the server.
​
​ The server checks the Payer’s current balance.
​ 1. 
If the balance is insufficient, it will respond the client that it will respond
the client that the TX is rejected and sends the users current balance.

5. ​ 2. 
If the balance is sufficient, it will do the following 1. 
Stores the TX in its
list of TXs. 
Note that the server stores only the confirmed TXs.2.

Withdraws the transferring amount from the Payers balance.
​ 3. 
Increases the Payee(s) 
balance(s) 
with the amount(s) 
given in the TX.
​ 4. 
Responds the client that the TX is confirmed and sends the users
current balance.The client will receive the response and will do the
following.
​ 1. 
Updates its current balance.
​ 2. 
Changes the TX status from temporary to either rejected or confirmed.If
the user selects Fetch and display the list of transactions, the client will
send a request to theserver. Then the server sends the users current
balance and all TXs in which the user has been either a Payer or a Payee.
3. Then the client will update its list of users confirmed TXs with this
newlist. Then it will display its list of users TXs on the screen, consisting of
all confirmed TXs in which
​ 4. the user has been either a Payer or a Payee and all rejected TXs in
which the user has been aPayer.Note: If the printed list of TX records on
the screen looks like a sequential statement rather thana structured table
or list, you will miss 10 
points out of 100.Note: Whenever the server
receives or sends a message, it should prompt a message on thescreen
and report what it is doing. For example, Received an authentication
request from userA, User A is authenticated, Send the list of transactions
to user A, 
Confirmed a transactionfor user A. 
You will miss 10 
points out of
100 
if your server does not prompt the messages.
​ 5. 
Notes to test the programRun the following test steps and take a
snapshot of your terminals at each step. Make aReport.docx file and enter
the snapshot of each step to the report file.
​ 6. Zoom in and take asnapshot that is large enough, and the text in it in
visible to read.Note that you can run all the programs on the same
computer. Use localhost for the serversname in the client program.
​ 7. 
Test your program as following:First run server.py in one terminal and
then run client.py program in another terminal.Note that in all steps the
server prompts a message on what it has done in that step.Step 1. 
Enter
username A and password G. 
The server will reject that. The client

6. displays a menuof two items: try again and quit. The user selects try
again.Step 2. 
Enter username A and password A. 
The server will accept
that and sends user As balanceand TX list to the client. The client shows a
message that user A is authenticated, its balance is 10BTC, 
and an empty
table of user As TXs. 
The client stores this information for later use. The
clientdisplays a menu of 3 
items: TX, 
list, and quit. The user selects
TX.Step 3. 
Now the client asks the following questions and user A
answers.1. 
Q: How much do you transfer? Ans: 12. 
Q: Who will be
Payee1? (1.B, 2.C, 3.D) 
Ans: B3. 
Q: How much B will receive? Ans: 2. 
The
program will reject it and asks the user to entermaximum 1. 
Then the user
enters 1.Now the client program stores this temporary TX in its list of TXs
and sends it to the server. TX idis 100. 
The server checks the Payers
current balance. It is sufficient. It stores the TX in its list ofTXs, withdraws
1BTC from As balance, increases Bs balance by 1, 
and responds the client
thatthe TX is confirmed and sends As current balance, which is 9.The
client will receive the response, update its current balance, and change the
TX status fromtemporary to confirmed. The menu will show up to the user,
and the user selects list.5 Step
​
​
​
​ 4. 
The client program sends a request to the server to fetch a list of TXs in
which A isinvolved. 
The server responds. A table of those TXs will show up
on the screen, which is currentlyone TX. 
Also, As balance, which is 9, 
will
show up on the screen.Step 5. 
Run the client in a new terminal and login
user B. 
User B wants to create a TX. 
TX id is200. 
B will transfer 5BTC.

7. 
Payee1 
is C, 
who will receive 2BTC. 
Payee2 
is D, 
who will receive
3BTC.The client asks the following questions and user B answers.1. 
Q:
How much do you transfer? Ans: 52. 
Q: Who will be Payee1? (1.A, 2.C,
3.D) 
Ans: C3. 
Q: How much C will receive? Ans: 2.4. 
Q: Who will be
Payee2? (1.A, 2.D) 
Ans: D5. 
D will receive 3BTC. 
The rest of this step is
similar to step 3.Step 6. 
The client program sends a request to the server
to fetch a list of TXs in which B is involved.The server responds. A table of
those TXs will show up on the screen, which is currently 2 
TXs.Also, Bs
balance, which is 11-5=6, 
will show up on the screen.Run the client in a
new terminal and login user C. 
Run the next test steps.The test steps are
summarized in the following table. The term bal refers to the users
balanceafter the TX is completed.Step# User Request TX# Payer Payee1

Payee2 
AsbalBsBalCsbalDsbalStep3 
A TX 100 
A, 1 
B, 1 
None 9 11 10
10Step4 
A List 100Step5 
B TX 200 
B, 5 
C, 2 
D, 3 9 6 12 13Step6 
B List
100, 200Step7 
A TX 101 
A, 6 
C, 4 
D, 2 3 6 16 15Step8 
A List 100,
101Step9 
C TX 300 
C, 10 
A, 2 
B, 8 5 14 6 15Step10 
C List 200, 101,
300Step11 
A RejectedTX102 
A, 8 
B, 3 
D, 5Step12 
A List 100, 101,
300,102Step13 
B List 100, 200, 300Step14 
D Login 200, 101Step 11: User
A selects to create a TX in the menu. TX id is 102. 
A wants to transfer
8BTC. 
It wantsto pay 3BTC to B and 5BTC to D. 
The server rejects the TX
as As current balance is 5BTC, 
which isless than the required 8BTC.6Step
12: User A selects the list of TXs in the menu. 4 
TXs 100, 101, 300, 102

will be listed and Ascurrent balance 5 
will show up for A. 
TX id 102s status
is rejected, and others are confirmed.Step 13: User B selects the list of
TXs in the menu. 2 
TXs 100, 200, 300 
will be listed and Bscurrent balance
14 
will show up for B.Step 14: Run the client in a new terminal and login
user D. 
The server will send the list of TXs toD. 2 
TXs 200, 101 
will be
listed and Ds current balance 15 
will show up for D. 
Note that the server
stores only confirmed TXs.
​
​