Implement a fictitious coin in GO.

1. 13th Dec 2017
Brian Yap
A Simplified Bitcoin
transaction implementation in
Go

2. 2
Agenda
Describe how Bitcoin works.
Create a fictitious coin – Scrooge Coin
Transaction in Scrooge Coin
Sample code snippet of transaction
How to verify transaction?
Sample code snippet of transaction verification
A look into Bitcoin transaction and verification

3. 3

4. 4
Scrooge coin
Let's create your own cryptocurrency called Scrooge* coins.
It is a simplified version of Bitcoin.
To starts with, Scrooge creates 1M value in Scrooge coins and
distribute to his friends.
In order to distribute to his friend Scrooge will need to creates
Transaction to transfer Scrooge coin to each of his friend.
Transaction is the way to transfer Scrooge value from one
person to another.
Transaction are like a double-entry book-keeping ledger. On
the one side, it has the 'inputs' representing the amount you
want to spend (amount that you own). On the other side, it has
the 'outputs' representing the different amount to be paid to
various people.
Transaction also contains proof of ownership for each 'inputs' in
the form of digital signature from the owner.
* NOTE: this is based on a fictitious coin created in cryptocurrency course runs in Princeton
University.

5. 5
How do you spend your scrooge coin?
Transaction #99
INPUTS
From: Tx #50, Index #0
(amount received from Scrooge)
Signature: h3d53aaa3....a93
Output #0:
Recipient: Alice's Public Key
Amount: 400 (spent)
OUTPUTS
Transaction #150
INPUTS
From: Tx #99, Index #0
(amount receive from Alice)
Signature: da5543123....fdd
Output #0:
Recipient: Albert's Public Key
Amount: 200 (unspent)
OUTPUTS
Output #1:
Recipient: Charlie's Public Key
Amount: 200 (unspent)
Alice would like to pay Albert and Charlie each 200.
This tx shows Scrooge gave Alice 400.
This tx shows Alice gave Albert and
Charlie each 200.

6. 6
Transaction Representation
TInput:
Previous Transaction Hash to
spend and its position in the
Previous Transaction.
Signature to prove Previous
Transaction is owned by you.
TOutput:
Amount to be given to the
recipient.
Public Key of the recipient.

7. 7
Create Transaction

8. 8
Transaction Class

9. 9
Transaction class

10. 10
How is transaction verified?
Unspent transaction output (UTXO) is an output that can be
spent as an input in a new transaction.
All UTXO are maintained in a UTXO pool.
Within the UTXO pool, it also provides ability to retrieve
TOutput associated with the UTXO.
Scrooge transaction rules:
1. All outputs claimed by a transaction must be in the current
UTXO pool.
2. Signature of each input of a transaction must be valid.
3. Unspent transaction output must not be claimed multiple times.
4. All of transaction output values are non-negative
5. The sum of transaction input values is greater than or equal to
the sum of its output values.

11. 11
How is transaction verified?

12. 12
Testing code....

13. 13
Bitcoin Transaction

14. 14
Bitcoin Transaction
Usage of scripts in transaction.
For instance Pay-to-Public-Key-Hash (P2PKH) pubkey script
ScriptPubKey
Used in Transaction Output as a means to 'lock' the amount. It
can only be 'unlock' with the right key.
Thinks of it as a puzzle with a missing piece.
ScriptSig
Used in Transaction Input as the key to unlock the Transaction
Output.
Thinks of it as the missing piece to solve a puzzle.
Transaction fee - it is implied being the different of sum of
inputs and the sum of outputs.

15. 15
Bitcoin Transaction
P2PKH Script validation

16. 16
Bitcoin Transaction
Bitcoin Address representation:
Base58Check(RIPEMD160(SHA256(Public Key)))
Base58Check
Remove identical looking characters (0OIl)
Suffix with four bytes of SHA256-based error checking code.
Prefix with one byte of application information, e.g. P2PKH
address starts with leading 1
https://blockchain.info/address/18fKRJCvLNsYgihqnhuh7nJ9CCz6SvmXq6
https://en.bitcoin.it/wiki/List_of_address_prefixes
Transaction (ScriptSig) is signed using Elliptic Curve Digital
Signature Algorithm (ECDSA). Signed transaction are encoded
using DER encoding.

17. 17
Bitcoin Transaction Rules
1. Check syntactic correctness
2. Make sure neither in or out lists are empty
3. Size in bytes <= MAX_BLOCK_SIZE
4. Each output value, as well as the total, must be in legal money range
5. Make sure none of the inputs have hash=0, n=-1 (coinbase transactions)
6. Check that nLockTime <= INT_MAX[1], size in bytes >= 100[2], and sig opcount <= 2[3]
7. Reject "nonstandard" transactions: scriptSig doing anything other than pushing numbers on the stack, or scriptPubkey
not matching the two usual forms[4]
8. Reject if we already have matching tx in the pool, or in a block in the main branch
9. For each input, if the referenced output exists in any other tx in the pool, reject this transaction.[5]
10. For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output
transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching
transaction is not in there already.
11. For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at
least COINBASE_MATURITY (100) confirmations; else reject this transaction
12. For each input, if the referenced output does not exist (e.g. never existed or has already been spent), reject this
transaction[6]
13. Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in
legal money range
14. Reject if the sum of input values < sum of output values
15. Reject if transaction fee (defined as sum of input values minus sum of output values) would be too low to get into an
empty block
16. Verify the scriptPubKey accepts for each input; reject if any are bad.
17. Add to transaction pool.
18. …... many more rules ….. Source: https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages