[Splash screen]

Introduction: Arlyn Culwick, Blocknet, inter-chain protocols, collaborate on a wide

number of other blockchain projects; researcher and cobbler of solutions,
conceptual analysis.
Format:
Explain how blockchains work
Explain how some people are using them
Try find out how you want to use them
Try to work out blockchain implementations to solve your problems
I'm always available to be contacted for help, info, connections to other blockchain
projects, etc. so please be in touch (on arlynculwick@blocknet.co)

To use blockchains, you need to be able to understand them and come up with ways
to use them.
I'm going to try to give you four things:
- The beginnings of the conceptual tools to use blockchains
- An understanding of what blockchains can be used for (which is highly specific on a
technical level)
- Resources - info - to read so that you can broaden your understanding
- Connections - to me and to other companies - who can help

(More detail on this later)

Now, to introduce how they work, a handy metaphor: [next slide]

A metaphor to help understand how blockchains function: lego

Blockchains have several components.
If you understand how they work, then you can start to think about ways to combine
them for your purposes.
(Theyre not as easy to combine as lego pieces are. However, unlike lego, you can
make your own pieces, or adapt existing ones.)

The core innovation: a solution to the Byzantine Generals problem

Enables, for the first time in history, digital scarcity.
- Despite the fact that information wants to be free

[Go through animation first]

In Bitcoin, digital signatures are used to prove ownership of coins (that is, the ability
to spend them)

A note on coins:
A coin is just a chain of digital signatures.
There are no coins! Just relationships of the form the current biography of
this datum may take another (highly specific) step forward under the following
conditions
Digital signatures: use an elliptic curve publicprivate key pair to establish a shared
secret over an insecure channel.
Elliptic curve cryptography Diffie-Hellman protocol - an industry standard version of "public key"
cryptography, which enables one to prove something without revealing the
information you use to prove it.
Public key cryptography:
"Public-key cryptography is based on the intractability of certain mathematical
problems.

"Early public-key systems are secure assuming that it is difficult to factor a large
integer composed of two or more large prime factors.
Then came elliptic curve cryptography. For elliptic-curve-based protocols, it is assumed
that it is impossibly difficult - the proper term is "computationally infeasible" - to find
the discrete logarithm of a random elliptic curve element with respect to a publicly
known base point.
"The size of the elliptic curve determines the difficulty of the problem."
From <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography>
Not absolutely unbreakable, just computationally infeasible.
Finite fields (for avoiding unreal numbers and anything else you can't communicate
determinately)
Insecure channel: anyone could tamper with the data you receive.
How can you be sure that it's what it claims to be? Answer: prove it
mathematically to yourself.
How can you be sure no-one steals your information? Answer: don't reveal it
in the first place, just prove you have it (and, further, allow anyone to use your
"proof" to send you messages that can only be decrypted by your secret).
Simple (though flawed) explanation of the protocol:
https://bithin.wordpress.com/2012/02/22/simple-explanation-forelliptic-curve-cryptography-ecc/

[do animation first]

Hashes: three properties
Put in any amount of data, get a fixed number of characters back
Change even a single character of the input data, and the output is a
completely different set of characters
No-one can ever work out what the original data was if they're given a hash.
How hashes are used:
1) Spot a duplicate: if it's the same hash, this means that the same data was hashed.
2) Refer to something without revealing it (due to non-reversibility of hash functions)
3) Provably identify a datum: a specific hash can't be created from any other datum,
so by putting a hash of the datum on a blockchain (an immutable record), and making
the datum publicly available, anyone can prove that:
the datum existed at a particular time (proof of existence)
the datum was signed by the private key corresponding to a given public
identity (proof of ownership
which is made complete if you can also prove ownership of the
datum itself)
Lots of other uses

[read the text below while going through animation]

Consensus algorithm
- Otherwise known as a dynamic membership multi-party signature (or DMMS)
- This is how you ensure a truthful record is always created
- A few known kinds (such as proof-of-work and proof-or-stake)
1)
2)
3)
4)

Take a pile of data

Start with a pair of data and hash them. Do it again with a second pair.
Take this pair of hashes and hash them.
Do this until all the data is hierarchically arranged into hashes of hashes, with a
single hash at the root of this "Merkle tree" that represents all the data.
5) You then append a random number, called a nonce to this hash, and hash the
result. This of course changes the hash.
6) Keep changing the nonce until you get a very rare hash - that is, one with a lot of
zeros in front of it. (Because hashes are not predictable, this requires trying out
billions of hashes.)
7) When you find a hash so rare that it's rarer than the hashes anyone else has
found for the data (their rareness is measured according to rules), submit it to
everyone else.

10

8) Your submission can't be faked, because everyone will go and check that the hash
is really a hash of the data. Hence you effectively "prove" that you must have tried
a huge number of nonces in order to find the rare hash. In other words, you prove
that youve done work.
9) Since hard work is required to solve a block, its not easy (that is, computationally
infeasible) for anyone to try submit an alternative block, never mind an
alternative string of blocks to the one that the network as a whole has accepted.
Therefore proof-of-work creates an immutable, unfakeable record of events.
10) Your rare hash becomes the "official" hash of the data, and as such it gets added
to all the other hashes of all the other blocks of data that went before it. That is, it
becomes part of the blockchain.
11) As the proud discoverer of the rare hash, you get some brand new bitcoins, which
are agreed by all parties to be created upon the addition of the new block to the
blockchain.
So, to generalise a bit, the uses of a DMMS:
- Secure the value of a resource: make it impossible for anyone to fake the datum
(because by definition if it's in a block, it's "real"), making it uncopiable, and thus
scarce.
- Establish consensus about a given datum between an open-ended set of people.
- Collectively establish any set of facts (cf. Ethereum).

10

Bitcoin transactions are commonly explained as being about a signature and a public
key, where the public key stores the coins and the signature authorises them to be
spent.
This is only partly true.
The actual data structures of Bitcoin are transactions; addresses arent separate
entities from transactions; a transaction doesnt send to an address.
Thus, instead of having a picture of coins being sent from address to address, you
should think purely of a ledger of actions, where each action carries out rules
previously specified, and then includes rules about what the next action must be.
Bearing this in mind, Bitcoin transactions are composed of two scripts, a ScriptSig and
a ScriptPubkey (public and private keys involved, but are just part of a method of
proving ownership)
A script is a set of commands.
A ScriptSig contains a signature (of a simplified version of the transaction), and a
public key used both to verify the signature and to hash to the output address of the
previous transaction (i.e. the transaction its spending)
A ScriptPubKey is a set of rules about how to spend the coins in the transaction, and
from which address.

11

12

13

[End, unless theres time for case studies]

http://bitnation.co
http://swarm.fund
http://backfeed.cc
http://storj.io
http://maidsafe.net
https://github.com/MrChrisJ/World-Citizenship
http://identi.fi
http://www.pgpi.org/doc/pgpintro/

14

MayorsChain
Traditional govt is opaque, slow, and not user-friendly
The public has a right to transparency over public goods.

15

Storj
Traditional cloud storage is distributed and requires you to trust the provider
Problem: the provider can break the system by selling your data
Problem: an attacker can break into the system and steal/delete data
Solution: decentralise, massively duplicate, and strongly encrypt data,
crowdsourcing infrastructure.

16

Bitnation emergency refugee response

Bitnation e-Estonia notary service
Bitnation ID and land title:
People can't register their land or identities (because of corruption, failed
state, refugee status, statelessness, etc.)
Problem: have to trust the state.
Prove ownership on stronger grounds, using cryptography and immutable
records on a blockchain. No government can erase the record, no matter how
much someone bribes them.

17

Smart devices to measure natural resources: devices can fail or be tampered with.
How do you ensure that the data is truthful?
Strategy 1:
Everyone has a smart device, each of which measures the resource.
Consensus is established by eliminating the outliers (cf. Augur)
Drawbacks: you can't have, say 100 devices measuring the rate of flow
of water. It's expensive and cluttery.
You can't get consensus about, say rainfall measurements, because
they diverge vastly even over small locational differences.
Etc.
Strategy 2:
Everyone's node reports on the same device readout
In addition to checking the readout, it checks the software against a
repo on the blockchain, ensuring it is a faithful copy
Regular checks for faults and repairs are paid for by the device, which
automatically calls a technician and books repairs.
It makes money by supplying data
It can either reduce its rate or pay excess funds to maintaining
other infrastructure

18

18