2.0 Bitcoin Vs Bitcoin

How does Bitcoin work?
Here we will go over the various parts of the Bitcoin

system. As a complex system it can be confusing at
times.
We will split the discussion up into two pieces. Those
more related to the Bitcoin protocol, and those more
related to the bitcoin currency.
The Bitcoin Protocol

The Bitcoin protocol uses a proof of work algorithm to show that computers trying
to 'mine' bitcoin are really dedicating computing resources which can be translated
into electricity. Meaning it isn't free to work on the network, but it also isn't free to
attack it.
The record keepers and validators are spread across the world, providing
resistance to various forms of failure.
The people interact directly with each other through their nodes.
The nodes all agree with, because they are all running software that obeys the
same rules. False txs will not be forwarded.
The Bitcoin Protocol Continued 2

When all nodes have the same rules, and they only validate txs that obey their
own rules an emergent property of consensus appears.
The software is not very complex, which was done on purpose. Not only can many
devices run such a program, but it is not thought to be possible to encode anything
malicious.
What it does include: arithmetic, if/then, logic and data handling (throwing errors
and returning early), cryptographic functions such as hashes, signature and
multi-sig verification.

With non Turing complete languages since they don't having any loops or complex
interactions one can tell how long each process should take, which is useful for
error detection.
Bitcoin's scripting language is simply called 'Script' it was built for bitcoin but has
similarities to a languages called 'Fourth' which was a stack based language.
The 'stack' is the only memory interaction. Only one thing gets processed at a
time, the last thing put on the stack is the first processed.
The script holds data and feeds it one piece at a time into the stack. The stack
simply holds data, adding each piece to the top of the stack. When the stack
encounters a command it will execute that command.

To perform a tx the SK is needed for 2 things. The SK is used to create the PK,
which can be compared to the info stored in the blockchain. The SK is also
combined with the PubKey Script to create a signature. Once done this
information can be shared with malicious computers and bad actors without fear of
theft of funds or misuse.
Let's have a quick look at the most common type of script P2PKH, to redeem a
coins moved in a previous tx by signing with correct PK. In this example the tx was
created by someone who has some number of satoshis in one address. We will
go over other ways to spend coins later.
Example of Pay-to-PubKeyHash tx script validation,

using Bitcoin's scripting language Script.
<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY
OP_CHECKSIG
This is the code run by the script, the sig and pubKey are knowns as the scriptSig and are
provided by the spending party, the rest is known as the scriptPubKey and contains a hash
of the public key (from Bitcoin address in the blockchain) of the coins to be spent. The stack
is empty at this point, it will 'read' the script from left to right, store and acting on things
moved to the stack.
The script can only have two outcomes, complete or fail. If anything does not equal or is
found to be false the script will stop or raise a flag and it will not complete.
Example of Pay-to-PubKeyHash tx script validation,

using Bitcoin's scripting language Script. Cont
<sig> will be moved to the stack with <pubKey> then stacked on top of it.
<pubKey> will then be duplicated and hashed. This hash command performs
SHA256 and then RIPEMD160 on the resulting hash digest. This will return the
hash of the PK on top of the stack.
The PK hash is then put onto the stack before it and the hash below it are
compared.
The <sig> and <pubKey> are input into the Check Signature command and the
script is finished.

Bitcoin started with one major implementation known as Bitcoin, then in Nov '11 as
Bitcoin-qt, then after 2013 as Bitcoin Core.
Core software can be interfaced with command line (Bitcoind) or with a fancier
user interface (QT). Other implementations have arisen over time. E.g. Bitcoind
allowed new devices to use the software and it has been incorporated into Core.
Btcd, Bitcoin Knots, libbitcoin, BitcoinXT, Bitcoin Unlimited, and Bitcoin Classic are
all alt clients that some small percentage of the community run.
Changes to the protocol are released like regular software. With version numbers,
often a few changes at a time.

Bitcoin has historically counted in versions less than the number 1 because 1.0
and higher versions are thought to be ready for the public. These 'alpha' version
have been tested and approved for a wise audience.
Bitcoin remains in beta for the foreseeable future, counting versions 0.11.1 and
such.
Other implementations of Bitcoin clients may count their versions differently.
The code is available for review online. But while anyone can suggest changes
only a certain number of the developers have the 'commit' access to add it to the
core software repository, the source of the code that others can download it from.

This means that if the developers don't like or approve of some change they have
a final say unless an alternative implementation is used.
The devs can issue a network alert to let others know of a problem, but this
feature has rarely been used.
Users are mostly unknown to other users, the main record is an address on the
blockchain. It is advised to only use addresses once, which makes it harder for
addresses to be tracked to any one entity.
The software enforces values such as: total coins being (slightly less than) 21
million, timeframe, hashing algorithms like SHA256 and RIPEMD160, the average
block time which is 10 minutes in bitcoin, and any block size limit.

Other protocols known as alt-coins or alt-chains will often change one or more of these
variable. For instance Litecoin has a block generation target time of 2.5 minutes and doesn't
use SHA256.
There is no known basis for these values. Why starting the block reward with 50 and halving
every 210,000 blocks (roughly 4 years), why adjusting the difficulty every 2016 blocks (target
of 2 weeks with 10 minute blocks)? It turns out we may never know. SN claimed it was all an
educated guess.
The protocol does not need to be heavily encrypted like credit/bank networks, in fact it uses
the same network as the WWW. In the very beginning you could send bitcoins directly to an
IP address, and the addresses we often use today were a backup measure if someone
wasn't online at the time. Of course everyone using the system was also a full node back
them.
SN's remarks on picking values

My choice for the number of coins and distribution schedule was an educated guess.
It was a difficult choice, because once the network is going it's locked in and we're stuck with it.
I wanted to pick something that would make prices similar to existing currencies, but without knowing the
future, that's very hard.
I ended up picking something in the middle.
If Bitcoin remains a small niche, it'll be worth less per unit than existing currencies.
If you imagine it being used for some fraction of world commerce, then there's only going to be 21 million
coins for the whole world, so it would be worth much more per unit.
Values are 64-bit integers with 8 decimal places, so 1 coin is represented internally as 100000000.
There's plenty of granularity if typical prices become small.
For example, if 0.001 is worth 1 Euro, then it might be easier to change where the decimal point is
displayed, so if you had 1 Bitcoin it's now displayed as 1000, and 0.001 is displayed as 1
Transactions
Transactions transfer the ability to move some number of satoshis from the control
of one SK to the control of another SK.
Some information is required to unlock the satoshis and complete the script, this
locking script can be different for different txs and in general is known as an
encumbrance.
This information, also known as an unlocking script, is usually a SK, but when
using P2SH it can be any information. All information required to spend the coins
is hashed before sending, allowing txs to be sent over compromised networks. If a
tx is assembled on a secure device the tx can be sent from a malicious computer.
Txs 2
A tx can be created manually, however most modern wallets will handle it for you.
When a tx is made the entire balance of the sending wallet is emptied, often the
previous balance is not meant to be entirely spent and so a change address is required
on some DIY transactions. Any amount not accounted for between the sender and
receivers is taken by the miner as a fee.
Most txs require a fee or they will not get mined. Fees are based on size of tx data, not
number of satoshis. So txs with more inputs and outputs will incur higher fees
A tx consists of at least one input and one output. However in practice txs usually have
at least two outputs, one for the intended recipient and one for the 'change' address.
Txs 3
To be valid they must contain all the needed information for the Bitcoin protocol to
verify them as true. If a transaction is made without all conditions being met the
transaction will evaluate to false and will be invalid. Invalid txs do not propagate
across the network and are not accepted into blocks.
The simplest conditions that exist to spend coins are that the funds to be 'moved'
exist, and that they are under the control of a secret key that is present. As well as
including a acceptable address to send them to and some hash needed to unlock
the funds.
The acceptable address does not actually have to be one that has keys to unlock
it. So funds can be sent to addresses that they cannot be retrieved from.
Txs 4
The hash that unlocks the funds, is often the hash of the script that takes as input
a signature and SK, the one used in P2PKH txs. But in P2SH txs the script that is
hashed isn't guaranteed to work, an error in said script can cause funds to be
irretrievable.
Txs can be prepared ahead of time, just awaiting a PK to be completed. This is
how business can prepare a QR code that when scanned by the spender already
lists the payment details and just required finalization.
Once the tx is completed it is broadcast to the network through the nodes that are
connected to the wallet application. Most clients will connect to the node or nodes
that are run by the company that released the software Some more advanced
clients can be configured to which nodes they connect to.
Code that makes up a tx

The code that makes up the tx has a few parts.
1) The version byte. This first block is always 4 bytes long, it is used to encode which block protocol
version is being used to create the tx.
2) The next section of code is of variable size, between 1 and 9 bytes. It is a variable length integer and it
represents how many inputs the tx has.
3) This consists of the inputs, (2) tells the computers how many inputs to expect.
4) This is the output counter, just like the input counter (2).
5) These are the outputs, like the inputs there must be at least 1.
6) These last 4 bytes are called the locktime field.
Txs 5
This last part the nLockTime field is often set to 0, which means txs are mined
right away. If there is a value the tx cannot be mined until that condition is met.
The nLockTime variable is read as block height if it is less than 500,000,000 (and
not 0) and as a timestamp if it is a higher value.
A new OP code which fully integrated with Core near the end of 2015 is called
CLTV or check locktime verify. The goal of it is to mine a tx right away that cannot
be spent until some time in the future. With nLockTime, the tx cannot be mined
and added to the blockchain until it is past the locktime, the tx must be kept and
not broadcast until the specified time.
Txs 6
Txs must have at least one input and one output, but how many can they have? In
theory one could publish enough data in one tx to fill an entire block.
For this reason early in Bitcoin's existence its creator added a cap to the size of
the blocks.
This was done as an anti spam measure and intended for the limit to be raised if
we got close to it.
However if one could fill txs large enough to hit the limit, then if the limit were
raised, they might be able to make txs large enough to fill that block as well.
The problem remains unfixed.
Txs 7
Modern HD wallets (Hierarchical Deterministic not high-def) generate a new
address for every tx they receive, so when they make payments it can often 'come
from' a number of addresses.
Payments can be made to a number of addresses at once in one tx as well.
Txs move control of coins, a less technical and sometimes plain incorrect way to
say this is that they move coins.
Txs wait to be put into a block, during that time they are unconfirmed, after they
are included in a block they are thought to be more confirmed but not entirely.
Txs 8
For arbitrary reasons SN decided that after 6 blocks a tx should be considered
confirmed. Different versions of the blockchain can coexist for a short time.
Coins can be created every time a block is found, only a few times have miners
not taken the full block reward. The coins lost by not taking the block reward are
gone forever.
The block reward started as 50 bitcoins per block, in 2013 roughly 4 years after its
creation in 2009, the first halving occurred and the number of blocks mined per
block was cut in half.
The bitcoin reward is expected to drop from 25 to 12.5 on JUly 11th in the
Summer of 2016. It will be the second of 33 halvings.
Txs 9
The block reward is also called the 'coinbase reward' and it is encoded in the
'generation tx' which is listed first on the block that mines it.
Aside from the generation tx all other txs have a similar structure. When any of
these other txs are made they require the coins to already be under the control of
a SK, or technically incorrectly in a public address.
There are two main parts of the tx, the input and the output.
The input references which associated address will be emptied and provides the
unlocking script to do so.
The output tells how many satoshis to take from that address and gives a script
that needed to unlock the funds.
Addresses
Satoshis are technically never held or kept in any address or PK. Some people
may get pedantic about this point and on the subject of to and from or send
addresses. These terms may not be as technically correct as possible but they are
very intuitive and helpful in understanding.
To spend any satoshis from an address one must spend all satoshis from that
address. This is the reason for the change address. Wallets will often try to build a
tx out of smaller outputs from previous txs (UTXOs) that are in its control. Your
mileage may vary, test different wallets if you need to know.
Transaction inputs
A tx can have a number of inputs, all of which reference a UTXO which exists in
the blockchain in the form of a tx hash (1) and the sequence number (2) that tells
which address in said tx.
(3) & (4) tell the size of the unlocking script and provide it.
(5) is a currently disabled section called the Sequence Number which was
intended to enable tx spending before the LockTime.
The script that unlocks the coins has historically derived from the SK with P2PKH
txs but very slowly other tx types have increased in use to over 1% of txs.
While P2PKH is the most popular type of standard input there are 5 standard tx
types.
The 5 Standard Transaction Scripts

These are the current standard tx scripts, they are not set in stone and were
chosen based on what was believed safe at the time. Nodes will not relay non-std
txs but will accept the tx if it is included in a block.
P2PKH or pay to public key hash, or pay to pubkey hash
P2SH or pay to script hash
Multi-signature or multi-sig
Public-key
OP_RETURN
P2PKH or Pay to PubKey Hash

You'll often find these terms written with strange capitalization and heavy hyphen
usage which I have sanitized for easy of reading.
This is used in by far the majority of cases.
The PubKey script is: OP_DUP OP_HASH160 <PubKeyHash>
OP_EQUALVERIFY OP_CHECKSIG and a signature and PK are needed to
spend
P2PKH is the standard btc tx today. It requires only a secret key and funds. For
the script to validate a tx, the hash of the public key created from the secret key
must match the hash that is present on the output.
P2PKH Cont
One only needs a secret key to unlock these txs, the key is used to create the
public key from it and to combine with a message to generate a signature.
By giving the other party the signature along with the public key they can decode
the message.
Bitcoin assumes valid possession of secret keys, and that having the SK is
enough power to use it. By using the ECDSA it can be shown that a message was
signed by a certain SK which is the only way to create the associated PK.
Signing digital signatures
P2SH or Pay to Script Hash

From the BIP16 page:
The purpose of pay-to-script-hash is to move the responsibility for supplying the
conditions to redeem a transaction from the sender of the funds to the redeemer. If
you buy a cola at the corner market, why should you care what the store owner
does with the money you give him, and why should you be responsible for paying
for it?
The benefit is allowing a sender to fund any arbitrary transaction, no matter how
complicated, using a fixed-length 20-byte hash that is short enough to scan from a
QR code or easily copied and pasted.
P2SH Cont
The benefit of this type of tx are thus: less data to store in the UTXO set, ability for
added complexity to tx parameters, and that the person creating the tx doesn't
have to pay a high fee for the data. So the redeem script can be very complex.
Paying out to multiple parties for instance. This way if a business wants to do
complex things with the money, they don't have to pass that cost along to the
customer.
These allow for a second script to be used in the validation of bitcoin txs. This
script is known as the redeem script. When coins are moved under P2SH control a
tx is created the redeem script hash is included in the output.
The script for this is: OP_HASH160 <scriptHash> OP_EQUAL. As you can see
the provided data is simply hashed and compared
P2SH Cont 3
The redeem script originally had to be one of the other standard tx type but now
(after v0.9.2 of Core) the code can be anything. It could be a secret clue in a
cipher to be assembled and hashed, or more realistically it could be a 'm-of-n OR
x script'.
These type of programs are known as smart contracts and they can be dependent
on anything programmable, like stock sales, company mergers, or published death
certificates.
They could be made to allocate funds differently in different circumstances such
as a contract that paid out to one party or another depending on results of an
insurance claim.
P2SH Cont 4
Programs could be prepared to operate on contracts if their conditions were met,
or computers could be programed to hold contracts and monitor for the conditions
so they could broadcast specialized txs at specific times. Programs could even
handle escrow or arbitration.
There are very many possibilities with the blockchain and bitcoin, but a majority of
them require a great amount of work to become viable. Such as the uploading of
documents to a blockchain, and a standardization of doing so that all programs
can read. Because of this, most large scale crypto integration is still many years
away.
The ability to create addresses with P2SH not only saves space but is less
complex for the spenders wallet software.
P2PK or Pay to PubKey

With around 1,000,000 txs on the blockchain using this format is remains highly
popular in number despite being suggested as not as safe.
As you might have guessed they are very similar to P2PKH scripts except they
don't hash the PK. The result of the PK not being hashed is that it is available for
everyone to see. If a weakness was found in ECDSA these address might become
vulnerable to attacks by a quantum computer. The hashing makes normal bitcoin
addresses quantum resistant. However this is still years away and such a threat
would also threaten encryption worldwide such as banks and communications
networks.
P2PK Cont
These txs were used mainly during the early time in Btcs life when people sent
payments directly to IP addresses.
Sending to an IP address offered no MITM protection, making txs of this nature
vulnerable and it was removed from Core.
Txs still occur using these scripts often in the generation tx with outdated mining
software.
The code is simply <pubkey> OP_CHECKSIG, and only requires a signature
made with the SK the made the PK.
Multi-Sig, Multiple-Signature, or M-of-N

MultiSig is a way to create keys in pieces, where the pieces are not whole and
must be combine with other pieces.
Despite that fact it is also possible to create keys where you only need 1 of the
pieces and there are many pieces.
To spend from a multisig address the right number of pieces must be present.
When the key is created is when the thresholds are set.
The split keys all have their own SKs, and they have addresses that start with a 1
which cannot be funded.
Multi-sig Cont
Once the keys are created their addresses (or rather the PKs used to create them)
are put into a key pair generator and a P2SH addresses and redeem script are
given.
To spend coins locked under such keys the OP_CHECKMULTISIG code is used.
The scriptPubKey lists how many sigs are needed, and lists the public keys along
with how many there are. The spender adds the needed amount of sigs as their
ScriptSig, the sigs are read, then the scriptPublicKey, then the opcode evaluates
the stack.
The user provides multiple public keys, and specify the number of valid signatures
that must be present. The number of signatures can be less than the number of
public keys
Multi-Sig continued 3
It is possible to create a raw multisig tx, but this is not recommended. Virtually all
multisig addresses are actually made with P2SH.
Using P2SH is more common and leaves less data on the blockchain.
When using raw multisig the network only allows up to 3 max pieces while still
being a standard tx, however up to 20 can be created.
A P2SH tx has a max size for the redeem script, and each signature used in
validation takes up space.
So 7 or 15 keys is the most that can be make with P2SH, depending on if the keys
are compressed or not.
Multi-Sig continued 4
Multisig can be used in many ways. By people in their day to day lives as well as
their long term goals. By businesses who want to increase accountability and limit
fraud. Even people who want to hide bitcoins in an elaborate puzzle are free to do
so.
According to a April 2014 analysis 1 of 3 is the most popular, followed by 1 of 2.
MultiSig example uses from bitcoin.it

1-of-2: Husband and wife petty cash account the signature of either spouse is
sufficient to spend the funds.
2-of-2: Husband and wife savings account both signatures are required to
spend the funds, preventing one spouse from spending the money without the
approval of the other
2-of-2: One wallet is on your primary computer, the other on your smartphone
the funds cannot be spent without a signature from both devices. Thus, an
attacker must gain access to both devices in order to steal your funds (much more
difficult than one device)
MultiSig example uses from bitcoin.it Cont

2-of-3: Parents savings account for child the kid can spend the money with the
approval of either parent, and money cannot be taken away from the child unless
both parents agree
2-of-3: A board of three directors maintaining funds for their organization those
funds cannot be spent unless any two of those directors agrees. Bigger
multi-signature transactions are possible for bigger organizations, such as 3-of-5,
5-of-9, etc.
OP_RETURN or Data Output

Early in Bitcoin's life did people see the potential of the blockchain, a universal or
worldwide ledger where everyone could validate the existence of something.
Some people wanted to store everything possible on the blockchain which many
viewed as wasteful.
People were putting data in txs instead of addresses, those coins can never be
spent and take up space on the UTXO set.
In Core version 0.9 OP_RETURN was added and it gives 40 bytes of space. A
SHA256 hash digest is 32 bytes. Any coins spent to broadcast this tx are marked
to the system as forever un-spendable.
OP_RETURN Cont
A single tx can normally have many inputs and outputs, but it can only have one
OP_RETURN output. Most txs that use an OP_RETURN pay no coins to that
address and instead spend the coins as a fee and change address.
Any message is hashed so others can prove they had a document by showing the
hash of as it existed at the time of hashing, but since it is hashed it is harder or
impossible to find what was hashed by looking at the output data.
Some companies that want to use the bc to secure their records use this type of
transaction.
Non standard tx scripts

Any script that ends without raising flags or stoping is valid, but they are not all
standard. The official Bitcoin client, Core, will not create or relay and non std tx.
These txs must be custom made. Nowadays any of these actions can be done
with a P2SH script.
Invalid txs can occur when there aren't enough coins or the SK is wrong, they
cannot be mined and any block containing them wouldn't be accepted by the
network.
Most miners won't mine a non std tx, however some will. A miner themselves can
also include non std txs.
Non-standard txs
Anything that can be done with the opcodes can be done, including math,
comparisons, adding/deleting terms, and hashing.
Anyone-Can-Spend Outputs, where the scriptPubKey is empty. Any miner who
incorporates this tx can use a scriptSig of OP_TRUE and spend these txs in the same
block.
Transaction Puzzles. For example the code could be OP_HASH <value> OP_EQUAL
and then people would have to find some data that when double hashed resulted in the
same value as <value>. Unlike regular txs, these have no sigs and can be tampered
with in transit.
Stealth Outputs are txs that aren't indexed by block explorers.This can be done by
adding information followed by a command to delete it.
Generation Transaction
The Generation Tx, also known as the Coinbase Tx, or the Coinbase Reward is
where new btc come from. It is always the first (and sometimes only) tx in the
block.
Banks around the world do something called 'Fractional-reserve banking' to create
money from loans.
Bitcoin creates units of currency that get paid to the miner who found a valid proof
of work. There is no UTXO leading to these coins.
The amount of bitcoin rewarded over time diminishes every 210,000 blocks which
is roughly 4 years.
Generation Transaction Cont

A miner can claim up to whatever the current block reward is as well as any fees
(tx inputs tx outputs) if they find a block.The field is created separately by each
miner so they can pay to any address they choose. They are not required to take
all the coinbase reward and this has led to some btc being lost forever.
The coins created in a generation tx can't be spent for 100 blocks in case of a
blockchain reorginzation.
A generation tx is the same as a normal tx except:
The generation tx itself must have only 1 tx, an output of choosing by the miner.
However that tx can pay to multiple addresses. The value of this output cannot be
more than the current block subsidy plus fees.
Generation Transaction Cont 3

A normal tx input starts with identifying which tx it came from, and (since there can
be more than one output from a tx) which output from that tx it is. In a gen-tx the
field which has the reference to the previous tx is all 0s, and the pointer to the
UTXO is all 1s.
A normal tx will then display how may bytes the unlocking script is and provide it.
The coinbase tx gives the size of the coinbase data and the provides it.
What is in the Coinbase data?

Not to be confused with the Bitcoin company 'Coinbase'.
SN encoded the headline from the London Times in the coinbase data of the Genesis block.
After BIP34 came out the data must contain the block height.
The extra nonce occurs here. Modern ASICs run through the normal nonce almost immediately. The
ability to change this field, as well as slightly modify the timestamp gives miners more combinations to try
when mining. Changing this field requires recalculation of the Merkle root. This field is twice the size of the
normal nonce.
The remaining data if any is given is often used to tag miners or mining pools, or to show support for
options in the Bitcoin system.
Blocks
Blocks are containers of data, they are made by miners.
The blocks have 2 main parts, a block header and transactions.
The block header has 6 component parts, one of which is the block header hash
of the last block mined, the parent block.
The txs include a generation tx in which the miner gets to claim a reward for
finding the valid block. This is always the first tx included in any block and
sometimes the only tx. In a Merkle tree it is the far left 'leaf'.
Blocks 2
Txs from users are relayed by nodes to the miner, they are kept in a memory pool once they arrive. Once
they are added into a block they are saved to the blockchain and unless they have already been spent
also added to the UTXO set.
Blocks are usually referred to in 2 ways. Either by ' block height', which indicated how many blocks have
come before it since the genesis block. This number is imprecise early in the block's life as it is not
confirmed. The (double SHA256) hash of the block header is often used by programs, known obviously as
the block header hash.
The block is transmitted to all nodes, and each node computes the block hash themselves. In 2016 an
upgrade was established that would allow lower bandwidth usage between nodes and in some cases
faster block propagation times.
The block header hash of the parent block is needed to mine so miners cannot start trying to pre-mine the
next block. Also blocks can at times have more than one child.
Block Structure
1) Block size field. States how many bytes of data the block is not including its own data which is 4 bytes.
2) The Block Header. This field itself has 6 of its own parameters. This field is what is hashed in attempts
to find a number lower than the target difficulty. It takes up 80 bytes.
3) Transaction counter, 1 to 9 bytes depending on how many txs are in the block.
4) Transactions take up the rest of the block. There is no set number of txs that need to go into a block,
but miners will almost always include the generation transaction even if they don't include any other txs.
With the current block size limit there is a maximum number of txs that can be included in any block.
When introduced the block size limit was far above normal use, and there have been difficulties agreeing
on how to change it. Different numbers and sets of txs will change the resulting hash digest of the block
header.
Block Header Structure

1) A version field that is 4 bytes.
2) Hash of parent block header, 32 bytes. Each parent has the block header hash of their own parent, going back to the first
block. Any attempt to change a past tx would change the hash of every block since then and be quickly noticed and rejected
by the network.
3) Hash of Merkle root, 32 bytes. The txs are used to create a Merkle tree, which has a Merkle root, this is the hash of that.
When a new block is found a new Merkle root is quickly found.
4) 4 bytes for the timestamp. Denoted in Unix time, which is a measure of the seconds (except leap seconds) since January
1st 1970.
5) The difficulty target, 4 bytes. When the entire header is hashed if it is less than this number then the block is valid.
6) The (first) Nonce, 4 bytes. The nonce, or number used only once, is iterated or changed after every failed hashing
attempt. The result of this is that by changing this one value the overall hash will be different. With today's mining equipment
miners can go through all values expressible with 4 bytes, and so a second nonce also exists. Known as the extra nonce, it
is located in the generation tx, so changing it requires recomputing the Merkle root.
Merkle Trees and Merkle Roots

The txs data is hashed using something called a Merkle tree.
Invented and patented by Ralph C. Merkle in 1979, the Merkle tree, hash tree, or
binary hash tree is a way to hash many values into one digest. Compared to a list
it is less computationally expensive to verify that a value is part of the tree.
To make a Merkle tree out of a list of data first each piece of data will first be
double (SHA256) hashed. Then every 2 pieces will be added to each other and
double hashed leaving one digest in their place.
The process of double hashing every 2 pieces is repeated until there is only one
digest which is known as the Merkle root.
Merkle Trees and Merkle Roots

Since the Merkle root is always a digest it is always the same size.
In the case of an off number in the list, such as a list of 3 values, The first two
items will be hashed together and the 3rd item duplicated and hashed with itself.
Like all hashing, any tampering with values will lead to different root values. Which
can alert others to a change, or be used by miners to produce different hash
values.
Illustration of a Merkle Tree from 'Mastering Bitcoin'
Merkle Trees
& a database
Using Merkle trees to validate if a value (tx) is included in a block is more efficient
than using a database or hash list.
Figure 7-4 from Mastering Bitcoin shows how one can validate that tx K is in the
block with only K and 4 other pieces of information.
With hundred or thousands of txs in a block this data structure can provide
validation for SPV nodes in only a few hundred bytes. For instance 16 txs in a
block would require 4 hashes and would require 128 bytes, but 65,535 txs would
only require 16 hashes and 512 bytes.
The Blockchain
The blockchain is a file shared by thousands of computers worldwide.
The Bitcoin blockchain is the original blockchain, and the idea of blockchains
originated with the Bitcoin protocol created by Satoshi Nakamoto.
There are many altchains, altcoins, altclients, et cetera that use blockchains in
some way.
The blockchain is a list of digital data, with Bitcoin the data represents value.
Initially stored on just SN's computer, the blockchain is now stored on over 5,000
computers worldwide.
The Blockchain Cont

Full nodes download and verify the entire blockchain 500 blocks at a time, starting from the
beginning, until they get to the current block. A process that can take days but ensures the
validity of the data.
Participants in the network will always follow the longest proof of work, so if new blocks are
mined at exactly the same time the one with more proof of work will get chosen. It becomes
statically much less likely any 'tie' can continue over blocks, even one tie is very unlikely.
The more blocks that are found after any event the more secure that event is, after 6 blocks
the tx is said to be confirmed.
The software implementation that the nodes run on is about 90% Core bitcoin in C++, other
popular options are btcd, BitcoinJ, and Libblecoin.
The Blockchain Continued 3

The original protocol written by SN has been rewritten and changed in the process
of streamlining and improving the code.
Altchains began as forks of bitcoin's code with minor changes. For the most part
altchains have tokens and a blockchain for them. Some companies like the way
Bitcoin keeps files and they want to extract the blockchain technology and discard
or replace the token.
The entire blockchain can trace the history of every coin and tx to the generation
tx that created them, and the history of every block to the block before it all the
way back to the Genesis block.
The Blockchain Continued 4

When full nodes are first started they download the entire blockchain, 50 blocks at
a time, validating every tx along the way. That way they can know for sure that
every tx they have stored obeys the rules.
This often takes days, even with fast internet connections and torrenting (a P2P
filesharing network). Aside from downloading over 50GB of data, validation takes
computing time and usage.
Not all of these txs are necessary for everyone, some people may trust the rest of
the network and only want the unspent transaction outputs, or UTXOs. This would
result in a faster downloading and syncing of the blockchain. While the whole
blockchain is stored on local storage like a hard drive, the UTXOs can be kept in
RAM which provides faster access to the computer and allows for faster mining.
Other Blockchains
The Blockchain, the public blockchain, the World Wide Ledger (WWL), the Bitcoin
Blockchain; whatever you want to call it, it may have been the first but it isn't the
only and it might not stay the most important chain.
Based on the Bitcoin bc, Litecoin is often said to be the digital Silver to Bitcoin
being digital Gold. Litecoin was long second most decentralized popular crypto
after btc since roughly its creation until Ethereum usurped it.
Ethereum is not a fork of Bitcoin at all, it uses a token called 'ether' to facilitate
smart contracts using its turing complete scripting language. It has attracted the
eye of many businesses as of late and gain even more attention after the theft of
nearly 1/3rd of a ~150 million dollar investment
Other Blockchains Cont

Testnet is a place to test btc changes with more forgiveness than real btcs.
Ripple is a centralized payment network working with many central banks. It offers
a way to exchange value over borders.
Dogecoin was a Dec 13 fork of Litecoin, which at the time with its easy difficulty
was quick to get people into mining it, the lighthearted and generous community
helped foster a sense of togetherness as well. Technologically it has failed to
develop however.
Using the Bitcoin blockchain as an example, what would other blockchains be
like?
Figure from a
Jan 19th, 2016
report by the
UK Government's
Science Office
Blockchains, Blockchain Technology

A blockchain can be many things.
At the most basic level anything that would be considered a blockchain must have
'blocks' of data that are somehow linked together in a 'chain' or sorts.
Is there anything else a blockchain must have? Different people will give different
answers.
What is a BC without:
Miners? 'Miners' add data to the chain, and if the file is to grow then it would need
something to add data to the chain, even if they are not called miners. In the start
of btc all connections to the network (network nodes) were also miners. We will
here distinguish between miners who add txs into blocks and nodes who maintain
the ledger.
A token / coin? Without a token there is no block reward, fees, or txs as we have
learned about them. There are theoretical reasons why miners might want to
maintain a chain they where there are no coins, but no one has publicly shown a
working model
POW? The POW is how miners earn the ability to add data to the chain, it causes
the average time between blocks. Without a POW anyone with the ability to mine
could add data at any time without restriction. This would be a data chain or a
distributed database but not a blockchain. A system like this might attempt to
restrict access to who can mine, but without validation anyone breaks into their
network they can easily run amok.
A public that can access the chain? If participation is somehow limited past it's
current status of needing equipment, connections, and electricity in a way where
only vetted or approved nodes can connect the it would be a private blockchain.
Bitcoin's blockchain was based on the idea that you shouldn't have to trust others,
but private blockchain require trust in one way or another.
An incentive? Miners are incentivized to find a valid POW via a payment of tokens.
Most of these tokens come from the block subsidy, and a small number come from
fees. It is thought that in the future there will be more fees to compensate for the
dropping block reward. If there is no financial reward for mining and maintaing the
chain then miners would have to have some other reason for mining. If only fees
or block rewards existed they would be depended on more heavily than btc
currently is.
A digital signature at all? Without any sort of digital signature it would just be a
database.
Nodes? Nodes hold the tx database, without them users could send txs straight to
miners who could confirm them and broadcast a confirmation that then gets
deleted. This would require a backend structure different than the blockchain, or
perhaps as a second layer.
Users? If all users were nodes or miners and the public was not invited perhaps
the only 'users' would be large companies. Such a situation sounds like a fraud
resistant version backbone for bank interchange, like an improved SWIFT.
A consensus algorithm? Btc always accepts the longest proof of work chain, the
same rules apply to all nodes. Without a working consensus protocol chains may
split and remain split, they may both continue but more likely one will fail.
Secret Keys? SKs are all that are needed to move cryptos, users keep them safe
and don't share them and in return they can use them as they wish. If there were
no SKs at all then either there needs to be another system of authentication or
security is not an issue and it would be okay for anyone to use anything. SKs
being not directly availabel to the end user is different though. Users might be
using an HD wallet and not be able to access their master SK, there might be a
password, code, or other identified used to authorized access to the key. There is
however the option that SKs aren't available to users because they don't have
control of their units, such as in the case proposed bank or government coins.
ECDSA? Bitcoin uses digital signatures to verify SKs. There are other methods of
verifying digital signatures such as RSA, but elliptical curve cryptography offers
smaller keys and easier key generation.
Secp256k1? ECC uses a specific curve for each implementation, SN chose a
seldom used but efficient curve. As long as the curve is secure it shouldn't matter
what parameters or criteria is has; but no one can know what is secure only
probably secure.
Non-turing complete script? Other chains like Ethereum have more advances
scripts that can execute complex commands. This enables more utility but it also
offers an avenue for error and attack.
Nodes
In its most basic sense a node is a connection point.The latin root, nodus means
knot. For the many descriptions of the word a node may connect only two things, it
may connect to only one thing, or it could connect to a vast number of other
things. For Bitcoin, a node is any computer connected to the Bitcoin network.
There are four functions that nodes perform. Due to evolving nomenclature what is
nowadays referred to as a node is only required to perform one of these functions.
When Btc was started all nodes did all four functions, over time separate
implementations have been created to handle these functions.
Nodes 4 original functions

These functions are:
Network routing function
Keeping an up-to-date and complete copy of the blockchain
Mining
Being a btc wallet
There are a number of combinations and variations of these functions that make of
the members of the Bitcoin network.
Node functions
Network routing function: All nodes must transmit data they receive, verify it, and
relay it to the network if valid. This data can be transactions or blocks. They will
also maintain a connection to the network by finding new peer nodes when old
peers go away. Nodes with
Complete blockchain: Node that maintain an up-to-date version of the blockchain
are known as full nodes as they have the full blockchain. Node may also keep
track of the UTXO set separately for faster access by keeping it on the computer
memory (think RAM), which is erased every time the computer shuts down,
different than persistent storage (think hard drives).
Node functions cont

Mining: The mining function that was once performed on a regular computer CPU
is now down on microchips made just for mining btc. Miners need to connect to a
full node, which they can do without hosting the full node themselves.
Wallets: Aside from the protocol programs like Core, bitcoin wallets can be hosted
on programs on a PC, or downloaded as application for cell phones and tablets.
There are hardware wallets which can be used to send txs on untrusted
computers. Since btc are only held by a SK, that SK can be printed or engraved
for long term storage where one doesnt have to worry about hacking. These 'cold
storage' wallets are usually called 'paper wallets'.
Types of Nodes, from Mastering Bitcoin
Types of Nodes, from Mastering Bitcoin (2)
Extended
network
From
Mastering
Bitcoin
Memory Pool and Orphan Pool

Once a tx is broadcast to a node, that node will verify it and broadcast it to all its
peers. Known as 'flooding' this spreads the message in a logarithmic manner.
As txs ripple to new peers they are help in a temporary storage while waiting to be
put into a block. This temp tx pool is called the memory pool (mempool for short)
or transaction pool.
Wallets monitor the mempool to announce unconfirmed tx to users.
Different nodes have different policies and sizes of mempools, which can lead to
dropped txs or attack vectors.
Memory Pool and Orphan Pool Cont

If a tx is made and there is no parent tx, some nodes will store that tx in something
called the orphan pool.
When new txs come into the mempool the orphan pool is scanned to see if any of
the new txs are parents to any tx in the orphan pool. If an orphan tx finds its parent
it is moved to the mempool, which restarts the searching the orphan pool process
until all orphans pool txs are orphans.
These pools, like the UTXO set are kept in memory and are restarted every time
the node restarts, so different nodes have different content in their pools.
Full Nodes
These nodes start by downloading the Btc protocol which has the Genesis block
encoded in it. They then use a list of hard coded peers to find more peers,
download and verify blocks from them until they are current.
Full nodes with Btc are not compensated, yet they form the backbone of the
network.
Running a full node can be expensive as it requires large amounts of bandwidth
and is often run on a dedicated computer. It also consumes electricity and
produces heat and noise (from the fan).
Full Nodes Cont

Running a node helps the security of the network, some people do it altruistically
and others do it for their own security or peace of mind.
Nodes always follow the longest proof of work. Any tie for finding blocks by miners
will quickly be decided.
Full nodes store the entire blockchain, which is slowly approaching 100GB. In
theory since all txs are verified when they are made then most nodes would only
need to store the UTXO set, which is closer to 1GB.
When they receive any tx they can quickly verify the validity of said tx without
having to trust others.
Gathering the Blocks

One who wants to run a full node, and has the required equipment, internet
connection, and will must first download a Bitcoin Protocol software. This software
will include a few ways to get different IP addresses of peers, which the computer
will use to connect to. It is recommended to connect to more than 8 peers.
IP addresses of other peers can be given by a connected peer, and connected
peers can now share the IP address of the new peer.
Peers will attempt to contact peers that are unresponsive, but will move on to
other peers after failed attempts.
Gathering the Blocks 2

Nodes will exchange version messages which include blockheight, if one node has
less blocks than the other they will request those missing blocks. Since the
software includes the Genesis block the new node will verify every block in order.
The network sends groups of blocks as the new node verifies them.
If a node goes offline, it will need to verify the blocks it missed when it turns back
on. If it can't find any of the peers it recently connected to it will start over with its
process of peer discovery.
The blocks are provided to the node by the network, the node will verify them and
add new data to its local copy of the blockchain.
Nodes verify data before sharing it

Nodes has a list of criteria they use to verify both blocks and the txs in them.
This way it can trust the data without trusting the source.
Similar to how science article outline the procedure so that others can recreate the
experiment and see the results for themselves.
A number of logic checks to the protocol are used. Invalid data is rejected and not
passed on. Peers who repeatedly send invalid data can be removed as peers.
E.g. For blocks the network will check syntax and size, it will check to make sure
the hash of the block header is less than the target difficulty, check the validity of
the generation tx, make sure the timestamp is within acceptable limits, and check
the validity of all included txs.
Nodes verify data before relaying it

A timestamp is accepted as valid if it is greater than the median timestamp of
previous 11 blocks, and less than the network-adjusted time + 2 hours.
"Network-adjusted time" is the median of the timestamps returned by all nodes
connected to you.
Whenever a node connects to another node, it gets a UTC timestamp from it, and
stores its offset from node-local UTC. The network-adjusted time is then the
node-local UTC plus the median offset from all connected nodes. Network time is
never adjusted more than 70 minutes from local system time, however
In addition to checking the scriptSig, nodes will check some other data in the txs.
Rules for Verification of txs, from Master Bitcoin

The transactions syntax and data structure
must be correct.
The transaction size in bytes is greater than or

equal to 100.
Neither lists of inputs or outputs are empty.
The number of signature operations contained in

the transaction is less than the signature
operation limit.
The transaction size in bytes is less than

MAX_BLOCK_SIZE.
Each output value, as well as the total, must be
within the allowed range of values (less than
21m coins, more than 0).
The unlocking script (scriptSig) can only push

numbers on the stack, and the locking script
(scriptPubkey) must match isStandard forms
(this rejects "nonstandard" transactions).
None of the inputs have hash=0, N=1

(coinbase transactions should not be relayed).
A matching transaction in the pool, or in a block

in the main branch, must exist.
nLockTime is less than or equal to INT_MAX.
Rules for Verification of txs, from Master Bitcoin 2

For each input, if the referenced output exists in
any other transaction in the pool, the transaction
must be rejected.
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 pool, if a
matching transaction is not already in the pool.
For each input, if the referenced output
transaction is a coinbase output, it must have at
least COINBASE_MATURITY (100)
confirmations.
For each input, the referenced output must exist

and cannot already be spent.
Using the referenced output transactions to get
input values, check that each input value, as
well as the sum, are in the allowed range of
values (less than 21m coins, more than 0).
Reject if the sum of input values is less than
sum of output values.
Reject if transaction fee would be too low to get
into an empty block.
The unlocking scripts for each input must
validate against the corresponding output
locking scripts.
What's required to run a full node?

Satoshi envisioned nodes of the future being like giant data centers, but he also
thought miners and full nodes wouldn't diverge as they have.
Different entities in the btc space have different views of who should be able to run
a full node, some work so that even the poorest people can run one, and some
work to make nodes more robust and powerful; these aims are unfortunately often
at odds.
The future development and growth of cryptos depends on the views of those
working to sculpt it. For the time being the devs agree that running a node should
be feasible by many. But how?
So you want to run a full node

To help the network, to feel more secure about your own txs, or because you have a btc business and
need to monitor the blockchain. So what do you need to get started?
A computer or virtual machine running a recent version of Windows, OS X or Linux connected to the
internet. If you don't have your own server you may have configure your modem to allow 'port forwarding'.
100+ gigabytes of free disk space and 3+ gigabytes of memory (RAM).
A high speed Internet connection, allowing for upload speeds over 400 kilobits per second.
An unmetered or high upload limit Internet connection. Nodes upload 200+ gigabytes of data every month.
Download usage is around 20 gigabytes a month, plus around an additional 80 gigabytes the first time you
start your node.
6+ hours a day that your full node can be left running. You can do other things with most computers while
running a full node.
Simple Payment Verification or SPV Nodes

Also known as lightweight nodes these nodes make up the majority of the nodes
today, and are often associated with wallets.
SPV clients are not true SPV clients due to technical limitations.
They download block headers but not all txs, they therefore don't have a complete
copy of the blockchain and can't verify txs truly on their own.
A vast storage space savings, this allows SPV clients to run devices that couldn't
run a full node. E.g. cellphones, tablets, and low cost computers like CHIP and
Raspberry Pi.
Litenodes
To verify a tx the SPV wallet will ask its peers if the tx is included in a block, then
it will wait. If the network mines a number of valid blocks on top of the block in
question then the SPV miner is satisfied that the block and therefore also the tx is
valid and verified.
By downloading a tx and associated Merkle tree branches a SPV node can verify
that a tx was included in a block.
If one only downloads their own txs then others could guess what addresses they
control. Something called 'Bloom filters' was created to obfuscate that. But they
dont work idealy.
SPV
Downloading more txs and branches requires more data and space, but it makes it
harder for connected nodes to see which txs the SPV client is interested in. The
bloom filter can cause false positives however, saying a tx is in a block when it is
not.
If the peer nodes of the SPV client were bad actors they could say the tx was not
included in the block and give them nothing to check which could be problematic if
the SPV client was the receiver of a tx by their peer nodes who wanted to double
spend it. Client software will try and find a number of random peers but it remains
a potential area for misuse. While peers can deny knowing anything they cannot
give a false idea of a tx being in a block where it isn't.
Controlled Supply
Miners early in Bitcoin's existence could turn on their PCs and generate 50 coins
per block fairly easily. Over time the amount of bitcoin given in the block subsidy
decreases, and the price of equipment to get the remaining pieces goes up. As
with California's gold rush, early people could pick up nuggets of gold in riverbeds
or on the ground, over time people needed to use shovels and picks to dig, and
nowadays effective gold mining requires large investments in infrastructure, the
amount of gold left in the Earth is less, and it is harder to get to.
'Halvings' happen every 210,000 blocks, they decrease the block subsidy by half.
What began as 50 btc/block turned to 25 btc/block in Nov 2012. Block 420,000 will
be mined in the Summer and the rate will drop to 12.5 during the second halving.
This will happen 34 times until block 13,230,000 when the block subsidy is equal
to the atomic unit, one satoshi. At the current rate this should happen a few years
before 2140.
Finally, after 13.44 million blocks, in approximately 2140, almost
2,099,999,997,690,000 satoshis, or almost 21 million bitcoins, will be issued.
Thereafter, blocks will contain no new bitcoins, and miners will be rewarded solely
through the transaction fees - by Andreas Antonopoulos in 'Mastering Bitcoin'.
Mining and Miners

Nodes that assemble txs into blocks are called miners. Miners create potential or
candidate blocks and try to find one that is valid under the current state of the
system.
When a miner finds a block they propagate it to the rest of the network. Unless
another block is found at nearly the same time then that block will become part of
the blockchain, with other blocks built based on its information.
Every time a miner finds a valid block new coins are created, at a fixed rate that
diminishes over time.
Mining and Miners 2

Decentralized cryptocurrencies require mining as a security mechanism. Miners
who contribute computing power can gain more in btc by helping the network than
they can hope to get by working against it.
Their reward of block subsidy and fees which are paid in the native token give the
miner incentive to help secure the network so they can ensure the value of their
payment at the same time issuing and distributing said token.
Honest miners will always work on the longest proof of work, or chain of valid
blocks.
Mining and Miners 3

As soon as miners see someone else has found a valid block they begin working
on the next block. An honest miner has no incentive to work on blocks others have
found. A dishonest miner would have to still find the block they are working on,
and find another block on top of that before the rest of the network combine found
a new block for the mainchain.
Currently miners get most of their block reward from the block subsidy and less
than 1% from tx fees. Some people working on Bitcoin want many small fees to be
able to satisfy miners, while others want fewer but higher fees. This issue may one
day cause Bitcoin to split into two separate cryptos.
Consensus Mechanism
Emergent consensus happens at no particular time but over time a winner is clear.
Decentralized consensus means that there is no leader to choses things, every
node will make their own decisions independent of the decisions of others, based
on the rules and criteria they have.
Four independent actions work together to achieve this consensus:
Verification of tx data
Assembly of tx into blocks along with a proof of work
Adding blocks onto the blockchain after verifying them
Choosing the blockchain with the longest proof of work as the valid chain
Consensus
If nodes start obeying other rules than the rest of the network then they have
created two incompatible chains, this is known as forking the codebase. The word
fork can have multiple meanings in Cryptocurrency-land, just like the word
consensus and decentralizes. Make sure any conversations you have on the
subject you make clear which definition of the words you are referring to.
Forks have been done before without problem, and will need to be done again
many times in the future to address problems both known and unforeseen.
The code can 'fork' temporarily if two miners find valid blocks at nearly the same
time, but more blocks will soon be found on one chain which will become the
mainchain.
Mining and Miners 4

Mining started using regular computer CPUs, as Bitcoin grew and gained
popularity people began looking for ways to mine faster and they found that GPUs
could do better.
Thus beginning the first great hashrate increase. Another pre-existing device Field
Programmable Gate Arrays or FPGAs began being used. People started looking
into creating microchips whose sole function was to mine bitcoin and Application
Specific Integrated Circuits were created for mining.
This occurred concurrently with the great price rise of 2013 and catapulted the
network hash rate to levels previously unheard of.
Mining and Miners 5

ASICs can be put into arrays of many chips, and ways to run and cool them
engineered. Thus there are mining operations with hundred or thousands of
machines all running the SHA256 hashing algorithm and connected to a central
computer.
Miners have to have access to full nodes, who verify each tx before relaying it.
Not all miners are part of large mining operations, however almost all miners
participate in a mining pool, or group of miners who share their hash power for a
better chance of a reward.
Mining and Miners 6

The block subsidy is thousands of dollars, but there is a very low chance any
particular person will win it. Miners team up and pool their hashpower, thus
increasing their chances of finding any reward but lowering the value of that
reward.
Mining pool operators have discretion that solo miners have, the ability to set their
node policy on what txs they will verify or allow. If most miners use only a few
pools then those pool operators can attempt to censor which txs go through, if
they have over 50% of the network hashrate they will succeed. This is known as a
51% attack, and members of the community monitor and change their hashpower
to avoid the possibility of it.
Mining and Miners 7

Bad actors waste resources, without over 50% hashing power they are better off
acting honestly.
The ability for bot-nets and excess computing power to be exchanged for money
led to a drop in people donating their hash power to other programs, such as SETI
@ home and BIONIC which search for answers to scientific problems. With the
increase in hashrate some of these hash power has returned as normal computers
cannot compete with ASICs.
Nodes may view some low value low fee txs as spam and chose not to broadcast
them, that is a node/miner policy but other nodes can forward them if they have a
different policy.
Mining and Miners 8

Many nodes prioritize txs based on the age of the UTXO that is being spent. Older outputs
and those with more satoshis have higher priority over newer and smaller txs. Some nodes
will include 'high priority' txs without any fees.
The formula for priority: 'Priority = Sum (Value of input * Input Age) / Transaction Size' and
the threshold for being high priority being 57,600,000, a 1 btc tx of 250 bytes that is 1 day old
qualifies. Over time less miners allow or have room for free txs, regardless of priority.
Miners for other cryptocurrencies may use different POW algorithms or different chain
structures but to be considered a miner on a blockchain they must use a POW algorithm.
Nodes on the btc network always follow the chain with the most proof of work.
Mining Txs
When a tx is broadcast to the network each node will store it in their memory pool.
But just because a tx was broadcast doesn't necessarily mean it will be mined into
a block.
Mempools have limited sizes and txs can be forgotten by nodes turning off then
back on, or some policies will evict txs that have sat in the mempool for a long
time and have less fees than newers txs.
Some want the ability for larger blocks so that legitimate txs aren't excluded, some
want wallets to find ways to notice if a tx didn't go through and rebroadcast it with
a higher fee. This proposal, Replace By Fee, or RBF is controversial to many
because it may remove the limited security of 0-confirmation txs in some
circumstances.
Mining Txs 2
Miners will try to mine a block until they receive a valid block from their peers.
They can quickly validate a block and they will move on to the next block which
requires making a new block header.
They store any newly received blocks and calculate the required work to create
those blocks.
The blocks with the most proof of work are considered as the mainchain and other
received and valid blocks are held temporarily. If a child block is found of that temp
block, and there is more proof of work, then the node re-converges on the longest
chain.
Mining Txs 3
Sometimes blocks can be found quickly, and a child block received before a
parent block, these blocks are held in an orphan block pool while the node waits
for a parent block.
A miner will switch to a new block once an old block is found, to do this they would
replace the hash of the previous block header, remove txs from their mempool and
recalculate their Merkle root, update their timestamp.
The last sections of the header are the difficulty and the nonce. With the difficulty
known and added the miner can start mining, performing the double SHA256 hash
of the header until they find a result less than the difficulty.
Target Difficulty Adjustments

Miners will double-SHA the header which gives them a random number, if the
resulting hash-digest is less than the target difficulty then increment nonce and try
again.
Once they run through the nonce field (less than a second at the current hash
rate) they will start modifying the extra nonce and if needed the timestamp.
The difficulty is recalculated by every node on the network every 2,016 blocks, and
that difficulty target lasts until the next recalculation.
The difficulty is encoded as a coefficient and an exponent which combine to give
the difficulty target.
Target Difficulty Adjustments 2

The difficulty is based on the idea that a block should take 10 minutes to find. So
the network will try to measure the current hash power by seeing how fast the last
2,016 blocks were mined and adjust the difficulty so that blocks should take 10
minutes to find with that network hash power. T
he network will modify the difficulty by up to a factor of four to avoid extreme
changes.
2,016 blocks of 10 minutes is 14 days or two weeks. Historically advances in
mining have made blocks be found quicker than every 10 minutes, resulting in a
net increase in the difficulty over time.
In fact difficulty drops have become spread out by years.
Difficulty
Miners might mine when it isn't profitable in the hopes it will be again soon. But as
new devices come out and the difficulty goes up some are priced out of new
hardware; leading to some centralization of miners.
Influences of Mining Profitability

Location is a big factor being near a power plant can help; plants that have extra
power are best. Being in a place with high demand may increase rent and building
costs. Some items are interrelated.
Maintenance of hardware and connections. ASIC need to be cooled and are more
likely to break if they overheat. Mining is popular in cold climates with geothermal
or hydroelectric plants.
Mining hardware is expensive and as difficulty goes up the Return On Investment
(ROI) may get less over time. Some manufacturers make and use their own
equipment to save on costs, they might sell the used units to the public after they
have been heavily used.

Internet connections can make a difference, if one is limited by how much data
they can send they will only want to mine small blocks and may resist others
moving to larger blocks than they can handle. If speed is an issue then miners risk
finding blocks that they can't spread fast enough. Both issue can occur in
combination.

Electricity cost is a very large factor, with better miners and higher difficulty the
cost in electricity to mine 1 btc goes up over time. So the price of a miners
electricity is a big factor in the ROI calculation. Cities will often offer better rates for
industrial businesses and heavy use during non peak times (night time), but many
miners have found that by moving to a country with more lax laws and cheaper
electricity they can make more profit.
Exchange rate is the other side of electricity Miners buy electricity with fiat gain
cryptocurrency tokens like bitcoin. The price in electricity to mine 1btc was been
approaching the market value.
Forks
If two blocks are mined at the same time and each spread to half of the network,
then half the world will have a different main chain from the other until the next
block is found on either chain.
This unlikely event would be an example of a type of a fork, the blockchain has
split but it can easily go back together with one block fading away.
In development of the client and the creation of other clients, forks change the
protocol rules. These forks come in two flavors, 'hardforks' and 'softforks'.
Softforks restrict the protocol. Nothing that wasn't possible before is possible after
a softfork.
Forking
Nodes should but don't need to update for a softfork, but if a miner doesn't they
may find a block with a tx that the majority of the network rejects they lose their
reward. E.g. Adding the 1mb temp cap to the size of the blocks in the block chain
when blocks bigger than 1mb were allowed before.
Hardforks can augment the protocol or have less restrictive rules. If nodes and
miners don't update and the majority of the network do then they will reject 'new'
blocks as invalid. Miners will build their blocks off of only blocks they see valid,
leading to them dropping behind the network and creating invalid blocks.
Both can be a mechanism of change, though soft forks are preferred when
possible, and soft forks have been the source of many developments. There is hot
contention over when, what, and how to fork Bitcoin over.
Hash Functions and Hashing

Hash functions or hash algorithms take data and turn it into other data of a fixed
size. A particular hash function will make the same sized output for any sized
input.
They are also deterministic, so anyone running a hash function will get the same
output with the same input.
The input data can be or arbitrary length and is often called the message and the
output is called a message digest, hash digest or often just a hash. This is a
'digital fingerprint' of the data. Which is easy to compute and verify by others.
Not to be confused with the verb 'to hash' which means to run a hash function.
Hash Functions and Hashing 2

Hash functions that are by all means impossible to reverse are known as secure
hash functions or cryptographic hash functions and they are the 'workhorses of
modern cryptography'.
Hash functions are an important part of computer science. They can be
implemented in many applications.
E.g. to mask the identity of users visiting a website or patents in a medical
database, allowing for studies of information without compromising the identity of
the subjects.

Hash functions output digests of a fixed sized depending on what function they
are. Different functions can have different sized digests.
The size of the digest plays a large part in how resistant to cracking the function is.
In general an attacker only needs to try have the combinations to have a good
probability of cracking the code. So a function with a 100 bit digest would only
need to try 2^50 calculations.

A secure hash function should have 3 things: collision free, infeasible to find two
different messages with the same hash; hiding, can't use many more computers to
work backwards; puzzle friendly, there is no better strategy to finding nonces then
guessing.
In secure hash functions the idea of 'continuity' is unwanted. This is the idea that
two similar inputs would have similar outputs.
By changing any part of the input the result is different in an unpredictable way.
This variable part of the input that is changes in hash functions to elicit a different
digest is known as the 'nonce'.

Hashing is used in computer applications such as record keeping and video game
software as well as websites.
Hashes of data can be used to store fingerprints of the data in a way that doesn't
take up much space, this can be used to check if files have been tampered with.
Hashes of passwords are often used so that passwords used online don't fall into
the wrong hands. The entity on the other end will verify that the digests match
before granting you access.
There are many different hash functions, Bitcoin primarily uses SHA-256, and
sometimes RIPEMD160.
SHA or Secure Hash Algorithms

Different families of Secure Hash Algorithms have been created by the NSA.
SHA-1 family functions haven't been recommended for years but there are no
documented collisions. Many websites and applications still uses these functions
despite suggestions by security experts
There are many hash functions, the one Bitcoin uses is called SHA-256, which
was published in 2001 with the rest of the SHA-2 family functions. There are 6
functions in the SHA-2 family with some slight variations in hashing structure and
size in bits of digest.
SHA-3 functions were approved by the US National Institute of Standards and
Technology (NIST) in 2012.
SHA or Secure Hash Algorithms Cont

The US Gov has recently begun recommending functions other than SHA-2 family
in order to preemptively combat quantum computer attacks. Bitcoin and other
cryptos (as well as all modern electronic communication) will have to upgrade at
some point.
SHA-256 breaks up data into chunks, the first chunk is combine with a
documented number 'IV', and run through a compression function 'c' which gives a
smaller digest than the input. This digest is combine with the next chunk and the
process repeated until there is only one 256 bit hash digest.
The operations in the compression function include: modular addition, right rotate
and exclusive-or / XOR.
Hashing Occurrences in Bitcoin

Miners double SHA-256 hash the block header and compare it to the target
difficulty. If it is less then they have found a block and can broadcast it, otherwise
they need to try again. They iterate the nonce and repeat until a block is found, if
needed iterating the extra nonce and then the timestamp. Many parts of the tx are
fixed, data structure and txs, but some of it is variable and that can be modified to
change the nonce.
Changing the difficulty changes how hard it is to double hash the block header into
a digest less then the new target. Requiring one more '0' in the target reduces the
amount of possible answers by half, an exponential increase.
Hashing Occurrences in Bitcoin Cont

Hashing occurs in other places in Bitcoin as well.
Generating an address
P2SH txs
Merkle tree root
Signing messages
By including a hash of the previous block header each block contains a 'hash pointer', with the blockchain
being a linked-list of hash pointers.
Calculating the tx ID
Used to validate and authenticate data with BIP 32 (HD wallets) and BIP 39 (mnemonic seeds)
Sources
Bitcoin Knots https://bitcoinknots.org/
Try hashing with SHA256 http://www.movable-type.co.uk/scripts/sha256.html
Idea that total number of satoshis is due to computational constraints https://www.reddit.com/r/Bitcoin/comments/20etko/why_21_million/cg2r7ks
'educated guess' link to copy https://bitcoinfoundation.org/forum/index.php?/topic/54-my-first-message-to-satoshi/
Picture of btc tx https://www.cryptocoinsnews.com/bitcoin-transaction-really-works/
Tx stack/script for P2PH table https://en.bitcoin.it/wiki/Transaction#Pay-to-PubkeyHash
Script validation table https://bitcoin.org/en/developer-guide#p2pkh-script-validation
Learn more about generation txs https://en.bitcoin.it/wiki/Transaction#Types_of_Transaction
Byte info https://en.wikipedia.org/wiki/Byte
Some locktime info https://bitcoin.org/en/developer-guide#term-locktime
Check LockTime Verify or CLTV https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
SN's 100 million tx / day idea https://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html
How tx sigs work https://www.cryptocompare.com/wallets/guides/how-do-digital-signatures-in-bitcoin-work/
Math behind sigs https://en.wikipedia.org/wiki/Digital_Signature_Algorithm
Digital sig pic https://upload.wikimedia.org/wikipedia/commons/2/2b/Digital_Signature_diagram.svg and
https://en.wikipedia.org/wiki/File:User_Acdx_SVG_Test.svg
Tx type analysis http://www.quantabytes.com/articles/a-survey-of-bitcoin-transaction-types
BIP 16 https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
reads like propaganda
https://bitcoinmagazine.com/articles/bitcoin-rbf-bitcoin-knots-and-bitcoin-addrindex-three-core-forks-that-don-t-break-with-consensus-1458237046
Sources 2
More on smart contracts https://en.bitcoin.it/wiki/Contract
Standard txs https://bitcoin.org/en/developer-guide#standard-transactions
MultiSig uses https://coinkite.com/faq/multisig, https://en.bitcoin.it/wiki/Multisignature
MultiSig max bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses
Send to IP https://en.bitcoin.it/wiki/IP_transaction
Non std txs https://medium.com/@alcio/a-look-at-bitcoin-non-standard-outputs-c97f65cccbb6#.9me3b6kvn
Address prefixes https://en.bitcoin.it/wiki/List_of_address_prefixes
MultiSig itself https://bitcointalk.org/index.php?topic=317569
Raw txs https://en.bitcoin.it/wiki/Raw_Transactions
Crypto Graffiti https://bitcointalk.org/index.php?topic=524877.0
OP_RETURN history https://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like
Missing Gox coins http://blog.wizsec.jp/2015/04/the-missing-mtgox-bitcoins.html
Unix time https://en.wikipedia.org/wiki/Unix_time
Block info https://en.bitcoin.it/wiki/Block_hashing_algorithm
Hashcash info https://en.bitcoin.it/wiki/Hashcash
Merkle Tree info https://en.wikipedia.org/wiki/Merkle_tree
Merkle Tree graphs and images http://chimera.labs.oreilly.com/books/1234000001802/ch07.html#merkle_trees
Discussion on 'lite' nodes https://bitcointalk.org/index.php?topic=88208.0
Pruning discussion https://news.bitcoin.com/pros-and-cons-on-bitcoin-block-pruning/
What is a blockchain http://www.coindesk.com/danger-blockchain-monoculture/
Sources 3
A better timestamp? https://www.certificate-transparency.org/log-proofs-work
Ripple as TTP http://www.coindesk.com/report-conflict-ripple-labs-consensus-protocol/
Article on UK science office report
http://bravenewcoin.com/news/british-prime-minister-and-cabinet-advised-to-start-using-distributed-ledger-technology/
Bitcoin's curve https://en.bitcoin.it/wiki/Secp256k1
Elliptic curves in general https://en.wikipedia.org/wiki/Elliptic_curve
Computer Ports, or network endpoints, btc has an open port tohttps://en.wikipedia.org/wiki/Port_(computer_networking)
Some small info on full nodes https://en.bitcoin.it/wiki/Full_node
Source for 'What's required to run a full node?' req.s https://bitcoin.org/en/full-node#what-is-a-full-node
More than 8 peers https://www.reddit.com/r/Bitcoin/comments/1scd4z/im_running_a_full_node_and_so_should_you/cdw3lrh
Setting up a full node https://bitcore.io/guides/full-node/
Calculate max total number of bitcoins https://bitcoin.stackexchange.com/questions/161/how-many-bitcoins-will-there-eventually-be
A banks way to create money https://en.wikipedia.org/wiki/Fractional-reserve_banking
Block versions https://bitcoin.org/en/developer-reference#block-versions
More on version bits http://bitcoin-development.narkive.com/2P0s5SLn/bip-proposal-version-bits-with-timeout-and-delay
Version bits BIP https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
Generation tx structure http://www.righto.com/2014/02/bitcoin-mining-hard-way-algorithms.html and
https://bitcoin.stackexchange.com/questions/20721/what-is-the-format-of-coinbase-transaction
Block timestamp deviations https://en.bitcoin.it/wiki/Block_timestamp
Sources 4
Hashing algorithm https://en.bitcoin.it/wiki/Block_hashing_algorithm
Verification and Validation https://en.wikipedia.org/wiki/Verification_and_validation
Tx priority example https://en.bitcoin.it/wiki/Transaction_fees
List of distributed computing projects https://en.wikipedia.org/wiki/List_of_distributed_computing_projects
Soft fork wiki https://en.bitcoin.it/wiki/Softfork
One way hash functions https://en.wikipedia.org/wiki/One-way_function
Compression function https://en.wikipedia.org/wiki/One-way_compression_function
Cryptographic hash functions https://en.wikipedia.org/wiki/Cryptographic_hash_function
Avalanche effect https://en.wikipedia.org/wiki/Avalanche_effect
Comparison of hash functions https://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions
SHA-2 family hash functions https://en.wikipedia.org/wiki/SHA-2
HMACs https://en.wikipedia.org/wiki/Hash-based_message_authentication_code
Hashing when signing txs https://tools.ietf.org/html/rfc6979#section-3.2
In blocks https://jornc.github.io/bitcoin-transaction-explorer/
Why it is hard to factor a certain large integer from another larger integer https://en.wikipedia.org/wiki/Integer_factorization
Studies https://docs.google.com/spreadsheets/d/1VaWhbAj7hWNdiE73P-W-wrl5a0WNgzjofmZXe0Rh5sg/edit?pli=1#gid=0
Mining with Pools https://deepbit.net/longpolling.php
'From' addresses don't exist https://en.bitcoin.it/wiki/From_address
Genesis block can't be spent https://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552

https://en.wikipedia.org/wiki/Double-precision_floating-point_format#IEEE_754_double-precision_binary_floating-point_format:_binary64
https://bitcoinmagazine.com/articles/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet-1382996984
https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki
http://www.coindesk.com/bitcoins-nervous-system-getting-upgrade
https://en.bitcoin.it/wiki/Block_hashing_algorithm
Intro to Script part 1 http://davidederosa.com/basic-blockchain-programming/bitcoin-script-language-part-one/

2.0 Bitcoin Vs Bitcoin

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2.0 Bitcoin Vs Bitcoin

Transféré par

Droits d'auteur :

Formats disponibles

How does Bitcoin work?

Here we will go over the various parts of the Bitcoin

The Bitcoin Protocol

The Bitcoin Protocol Continued 2

The Bitcoin Protocol Continued 3

The Bitcoin Protocol Continued 4

Example of Pay-to-PubKeyHash tx script validation,

Example of Pay-to-PubKeyHash tx script validation,

The Bitcoin Protocol Continued 5

The Bitcoin Protocol Continued 6

The Bitcoin Protocol Continued 7

The Bitcoin Protocol Continued 8

SN's remarks on picking values

Code that makes up a tx

The 5 Standard Transaction Scripts

P2PKH or Pay to PubKey Hash

Signing digital signatures

P2SH or Pay to Script Hash

P2PK or Pay to PubKey

Multi-Sig, Multiple-Signature, or M-of-N

MultiSig example uses from bitcoin.it

MultiSig example uses from bitcoin.it Cont

OP_RETURN or Data Output

Non standard tx scripts

Generation Transaction Cont

Generation Transaction Cont 3

What is in the Coinbase data?

Block Header Structure

Merkle Trees and Merkle Roots

Merkle Trees and Merkle Roots

Illustration of a Merkle Tree from 'Mastering Bitcoin'

The Blockchain Cont

The Blockchain Continued 3

The Blockchain Continued 4

Other Blockchains Cont

Blockchains, Blockchain Technology

Nodes 4 original functions

Node functions cont

Types of Nodes, from Mastering Bitcoin

Types of Nodes, from Mastering Bitcoin (2)

Memory Pool and Orphan Pool

Memory Pool and Orphan Pool Cont

Full Nodes Cont

Gathering the Blocks

Gathering the Blocks 2

Nodes verify data before sharing it

Nodes verify data before relaying it

Rules for Verification of txs, from Master Bitcoin

The transaction size in bytes is greater than or

Neither lists of inputs or outputs are empty.

The number of signature operations contained in

The transaction size in bytes is less than

The unlocking script (scriptSig) can only push

None of the inputs have hash=0, N=1

A matching transaction in the pool, or in a block

nLockTime is less than or equal to INT_MAX.

Rules for Verification of txs, from Master Bitcoin 2

For each input, the referenced output must exist

What's required to run a full node?

So you want to run a full node

Simple Payment Verification or SPV Nodes

Mining and Miners

Mining and Miners 2