Blockchains

A little about myself...

http://www.juanmgutierrez.com

http://www.ordergroove.com

Provide insight into how the different parts of this technology function.

My Goal

What are we covering today?

Problem statement
- Trust
- Ledgers
Cryptocurrency components
- Decentralization
- Transactions
- Blocks and Chains
- Mining and Concensus

Trust

How do transactions operate today?

"Middle man" acts as central authority for executing and verifying transactions in a ledger.

...
Alice gives Bob $100
Bob gives John $50
...
...

Alice

Bob

John

etc

This is setup is pretty
useful though...

Prevents "double spending"
Ensures no one is overspending
Targets and sources of funds are
verified
Fraud and consumer protection

We trust these institutions to act in our

best interests...right?

Trust is partially manufactured,

the rest is emotional/gut.

Peer-to-Peer Transactions

"Ideally the only risk you should have when it comes to managing your digital identity is whether or not your personal systems have been compromised, instead of worrying about every corporation you've ever dealt with in the past. "

Forbes - March 3, 2017

Blockchain appears to solve this "trust gap" and removes the need for a middle man.

Step 1 - Decentralization

...
Alice gives Bob $100
Bob gives John $50
...
...

Alice

Bob

John

etc

...
Alice gives Bob $100
Bob gives John $50
...
...

Alice

Bob

John

etc

...
Alice gives Bob $100
Bob gives John $50
...
...

...
Alice gives Bob $100
Bob gives John $50
...
...

...
Alice gives Bob $100
Bob gives John $50
...
...

...
Alice gives Bob $100
Bob gives John $50
...
...

"Who"?

256-bit keys

Public Key - Sending/Receiving address

Private Key

You might ask: How do we know that public/private key pairs are unique?

256

115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936

256

Max 256-bit number =

- 1

(78 digits long)

Point of comparison:

The number of atoms in the universe

~10

which is 80 digits long...

0011111001111000101001000101110111011110010110011001010010010100010100110111110001111001000100111101011101110011010011110101011000110010010001011110100101000001111000110111010011000001110011111110010100010111010100100000011101011100001011001110100011000101

Binary

Hex

3e78a45dde599494537c7913d7734f563245e941e374c1cfe51752075c2ce8c5

Base58

5CryUZAmQZRpqyGkhjA3KmhKjGGHXiSwHjbB1CaFG2cU

Outbound transaction

Sign(Message, Private Key) = Signature

Inbound verification

Verify(Message, Signature, Public Key) = T / F

"In Math We Trust"

It's actually more like

"With Math We Verify"

Written signatures

Digital signatures

Always looks the same...

Unique ID - Tx Msg
1 - Alice gives Bob $10
2 - Alice gives John $5
3 - Alice gives Bob $10

a030dc...
0b992a...
b0c090...

Every transaction is unique

Verification complete.

But what about overspending...?

A transaction is actually linked to previous transactions.

Alice has $100
Bob has $100
...

Let's say the ledger contains the amount put into "the pot"

Now - funds can be validated

Alice has $100
Bob has $100
...
Alice gives Bob $50
Alice gives John $50
Alice gives You $20 - X

Alice has $50
Alice has $0

Invalid transactions are simply rejected by the nodes.

But - why does it have to be $$$?

Alice has 100
Bob has 100
...
Alice gives Bob 50
Alice gives John 50
Alice gives You 20 - X

Alice has 50
Alice has 0

So this chain of transactions, that's the block chain everyone's talking about...right?

Not quite...

...
Alice gives Bob $100
Bob gives John $50
...
...

Alice

Bob

John

etc

...
Alice gives Bob $100
Bob gives John $50
...
...

...
Alice gives Bob $100
Bob gives John $50
...
...

...
Alice gives Bob $100
Bob gives John $50
...
...

...
Alice gives Bob $100
Bob gives John $50
...
...

Alice sends Bob $200

Alice sends Charlie $200

????

:-(

Enter the blocks and their chain...

"unconfirmed transactions"

https://blockchain.info/unconfirmed-transactions

Let's briefly discuss what a hashing function is....

f(x) = y

f(x, y) = x + y

f(x, y) = 4

x	y
0	4
1	3
2	2

Cryptographic hash functions have special properties

Arbitrary length input
Results are of a fixed length
Results are unique
Same input -> Same output
Hard to reverse

https://pypi.python.org/pypi/djangorestframework-saasy/0.1

a7c5c078219d8ffb8ce3d46b68456983

"Digital Fingerprint"

SHA256

Block header

Block version
Previous block hash
Merkle root
- I'm still learning about this one
Time (now!)
"Bits" aka "difficulty"
Nonce aka "randomly guessed number"

When creating a new block, we have all the information we need to compute the "current block hash" value, except the nonce...

The nonce is the puzzle we need to solve...

So what does "difficulty"/target mean???

The hash needs to be less than the difficulty value.

Let's look at an example of this in action...

It's easy to verify that a new block suggestion satisfies the difficulty - anyone can run the SHA256 algorithm against the contents of the block to confirm!

It can happen that two distinct blocks are generated at around the same time...

JK - the network trusts the "longest" chain. That is - your version of reality is the one you see first. However, if another chain finds the next block, you immediately switch to that chain.

Your transactions are considered A-OK after a certain number of confirmations.

If your transaction was on the shorter chain - they go back into the mempool to be put into a new block.

"But...if my transaction can be orphaned, can't someone attack the network by simply broadcasting their own longer chain?!??!"