BITCOINS

Department of ISE, RRIT-Bangalore-09 2014 Page 1

BITCOINS
Department of ISE, RRIT-Bangalore-09 2014 Page 2

BITCOINS
Contents
1 Introductio n
2 Using Bitcoin
Wallet s
Funding Your Wallet
Sending Payment s
Cryptograph y
3.1 Cryptographic Hash Functions
Merkle Tree s
Pulic !ey Cryptography
"igital Signature s
# Digital Currencies
Propertie s
"oule$Spendin g
Types o% "igital Payment System s
Precursor s
&.1 Triple 'ntry (ccounting
Pulicly (nnounced Transaction s
Proo% o% Wor k
6 Technical Overview
(rchitectur e
)*nershi p
(ddresse s
Transaction s
Structur e
+eri%icatio n
Scriptin g
Minin g
Procedur e
Proo% o% Wor k
"i%%iculty Targeting
,e*ar d
Department of ISE, RRIT-Bangalore-09 2014 Page 3

BITCOINS
-.& Mining Pools
Mining Hard*are
Department of ISE, RRIT-Bangalore-09 2014 Page 4

BITCOINS
Chapter 1
Introduction
.itcoin is the *orld/s %irst decentrali0ed digital currency. 1nlike most e2isting
payment systems3 it does not rely on trusted authorities such as go4ernments and anks to
mediate transactions or issue currency. With .itcoin3
Transaction costs can e reduced to pennies 5in contrast to typical credit card %ees
o% 678. 'lectronic payments can e con%irmed in aout an hour *ithout e2pensi4e
*ire trans%er %ees3 e4en internationally.
There is a lo* risk o% monetary in%lation
1
since the production rate o% itcoins is
algorithmically limited and there can ne4er e more than 61 million itcoins produced.
Payments are irre4ersile 5there are no chargeacks83 so there is a reduced risk o%
payment %raud.
Payments can e made *ithout identi%ication3 though some e2tra e%%ort is needed
to ensure that one/s identity cannot e e2posed 5See Section 6.18.
,esponsiility is shi%ted to the consumers3 *ho can permanently lose all o% their
itcoins i% they lose their encryption keys.
hat is a !itcoin"
( itcoin is asically a digital record in a pulic ledger that keeps track o%
o*nership in the .itcoin system.
6
The ledger records o*nership *ithout re4ealing any
real identities y using digital addresses3 *hich are like pseudonyms. )*nership depends
on possession o% a secret digital key that gi4es the o*ner the e2clusi4e aility to trans%er
itcoins to other addresses. The o*ner can spend itcoins to purchase goods and ser4ices
%rom any usiness that chooses to accept them.
ho operates Bitcoin"
Department of ISE, RRIT-Bangalore-09 2014 Page 5

BITCOINS
There is no company or organi0ation that runs .itcoin. 9t is run y a net*ork o%
computers that anyone can :oin y installing the %ree open$source .itcoin so%t*are. The
system is designed such that malicious attackers can participate ut *ill e e%%ecti4ely
ignored as long as the ma:ority o% the net*ork is still honest. 9% attackers e4er ac;uired the
ma:ority o% the computing po*er in the net*ork3 they could re4erse their o*n
transactions and lock ne* transactions *hile they held the ma:ority3 ut they still
*ouldn/t e ale to steal itcoins directly. People ha4e an incenti4e to :oin the .itcoin
net*ork ecause those *ho process transactions are re*arded *ith ne*ly created
itcoins.
ho created Bitcoin"
.itcoin started as a %ree3 open$source computer program *ritten y an author or
group o% authors *ho used the pseudonym Satoshi <akamoto. The pseudonym *as used
in oth the source code
3
and in the *hite paper that descries the idea.= 1 > <akamoto/s
possile moti4ations %or creating .itcoin can e gleaned %rom some o% his or her
discussions on mailing lists?
@=.itcoin is> 4ery attracti4e to the liertarian 4ie*point i% *e can e2plain it properly.
9/m etter *ith code than *ith *ords though.@ $ Satoshi <akamoto= A >
9t is estimated that <akamoto no* o*ns o4er B1CC million *orth o% itcoins3 as o% May
6C13.= - > <akamoto/s in4ol4ement *ith the .itcoin pro:ect %aded in mid$6C1C3 a%ter
*hich the open$source community3 headed y Da4in (ndresen3 took o4er responsiility
%or the source code.= 6 >
hy do !itcoins have value"
People consider itcoins to e 4aluale %or a 4ariety o% reasons.
Utility? .itcoins can e used to uy goods and ser4ices3 most notaly drugs
on the Silk ,oad3 *here other currencies are not accepted.
#$change %alue? .itcoins can e traded %or other currencies on e2changes
such as Mt.Do2. Speculation? .itcoin/s popularity has een surging3 and its
Department of ISE, RRIT-Bangalore-09 2014 Page 6

BITCOINS
4alue has surged along *ith it. Speculators pay %or itcoins in the hopes o%
making ;uick pro%its.
&carcity' The supply o% itcoins is limited. Production is algorithmically
limited and is capped at 61 million itcoins.
Historically3 most currencies ha4e een acked y either commodities or legal tender
la*s. .itcoin is acked y asolutely nothing3 so one might ;uestion *hether its 4alue is
sustainale. There is one case o% a currency that continued to %unction a%ter its legal
tender status *as re4oked? the 9ra;i S*iss dinar.= & > (%ter the Dul% War3 the 9ra;i
go4ernment replaced S*iss dinars *ith Saddam dinars3 ut the S*iss dinars continued to
circulate in the !urdish regions o% 9ra; due to concerns aout in%lation o% the ne* notes.
This e2ample demonstrates that it/s possile %or a currency like .itcoin to maintain its
4alue.
ill Bitcoin succeed"
There are two pri(ary threats to Bitcoin)s success? go4ernment inter4ention
and competition. )% the t*o3 competition is proaly the igger concern3 as discussed
elo*.
.itcoin is %amous %or eing a %acilitator o% illegal acti4ities such as drug dealing and
gamling.
#
The pseudonymous nature o% .itcoin makes it more di%%icult to use money$
tracking methods to catch itcoin$ased drug dealers3 gamlers3 money launderers3 and
criminals. 9n the long run3 i% .itcoin egins to replace the dollar3 the %easiility o%
en%orcing an income ta2 may ecome a ma:or concern since itcoin income can easily e
hidden. Do4ernments may decide that these concerns constitute grounds %or anning
.itcoin.
There *as a case in 6CC- *here the 1S Do4ernment success%ully prosecuted a
company that *as producing a gold$ and sil4er$acked pri4ate currency called @Eierty
"ollars@. The case *as ased on the charge that the lierty dollars resemled and
competed *ith 1S dollars. .itcoin3 ho*e4er3 could not e dealt *ith in the same *ay
Department of ISE, RRIT-Bangalore-09 2014 Page 7

BITCOINS
since itcoins don/t resemle 1S dollars at all. Plus3 there *ould e noody to prosecute.
9t *ould e ;uite di%%icult to en%orce a an on .itcoin due to its distriuted nature.
'4en i% a an *orked3 it *ould :ust push .itcoin underground in the country that anned
it. The system *ould still continue to operate normally in countries *ithout a an3 and
underground users *ould %ind *ays to a4oid eing caught 5y using the Tor ser4ice3 %or
e2ample8.
( more likely threat to .itcoin/s success is its competition. Since the introduction o%
.itcoin3 se4eral alternati4e currencies ha4e sprung up. These alternati4es claim to ha4e
ad4antages o4er .itcoin3 though none yet ri4al .itcoin in popularity. .itcoin de%initely
has the %irst$mo4er ad4antage3 ut i% a competitor manages to ecome noticealy superior3
there could e an e2odus %rom .itcoin. Commentators ha4e critici0ed .itcoin in 4arious
*ays3 most notaly on its inaility to scale to larger transaction 4olumes. Ho*e4er3
.itcoin de4elopers are acti4ely impro4ing the system and these criticisms could e
addressed e%ore competitors get o%% the ground.
*ow sa+e is it to hold !itcoins"
The 4alue o% a itcoin has een ;uite 4olatile. The %irst purchase made in itcoins
*as %or t*o pi00as at a price o% 1C3CCC .TC 5.TC is the currency code %or itcoins8. (t
itcoin/s current price le4el3 those pi00as *ould ha4e cost aout a million dollars. Since
there is no %i2ed e2change rate3 the 4alue o% itcoins can %luctuate greatly ased on
people/s perceptions o% their 4alue. The price3 sho*n in the chart elo*
&
3 has gone %rom
BC all the *ay up to B6FF. (%ter it reached this peak on (pril 1Cth 6C133 it crashed to
elo* BFC on (pril 16th. (nd this *asn/t the only time the price crashed. There *as also
a FA7 drop et*een Gune Ath and 16th3 6C113 and a &17 drop et*een (ugust 1Hth and
1-th3 6C16.=1C>
Department of ISE, RRIT-Bangalore-09 2014 Page 8

BITCOINS
"espite this e2treme 4olatility3 the price has trended up*ard and *ill likely continue in
this direction i% .itcoin sees %urther adoption. So *hile holding itcoins is y no means a
sa%e in4estment3 it has the potential to e a good in4estment.
Department of ISE, RRIT-Bangalore-09 2014 Page 9

BITCOINS
Chapter 2
Using Bitcoin
allets
To get started *ith .itcoin3 you need a *allet to hold your itcoins. See
itcoin.orgIenIchoose$your$*allet
%or a list o% options. The options %or otaining a *allet are?
,unning a itcoin client on your computer or smartphone 5clients come
*ith *allets8. 1sing a ser4ice that manages your *allet %or you.
1sing a ser4ice may e some*hat easier3 ut you really ha4e to trust the
ser4ice ecause they can potentially lose or steal your itcoins. Since
transactions are pseudonymous3 they could e4en steal your itcoins and tell
you they lost them and you *ouldn/t kno* the di%%erenceJ So it is
recommended that you run a .itcoin client. There are se4eral clients
a4ailale currently. The original .itcoin client is called .itcoin$Kt or the
@Satoshi Client@. The rest o% this section *ill assume that you are using the
.itcoin$Kt client.
Department of ISE, RRIT-Bangalore-09 2014 Page 10

BITCOINS
Department of ISE, RRIT-Bangalore-09 2014 Page 11

BITCOINS
,igure 2-1' The overview ta! o+ the Bitcoin./t client that shows the !alance in your wallet
The %irst time you run the .itcoin$Kt client3 it *ill create a *allet %or you
automatically. ( *allet is a %ile that contains a set o% addresses and keys that can e used
to send or recei4e itcoins.
(n address is like a ank account numer3 e2cept you can easily make as many as
you *ant so there is no need to limit yoursel% to :ust one. (ddresses are 6H$3# character
case$sensiti4e codes that look like this?
1t01MBDDM2D33cyh14e5P4tUdcP$g666
You could choose to use :ust one address3 ut it is important to reali0e that all
transaction data %or .itcoin is pulic3 so someody could %ind patterns in the transactions
going to and %rom that address. 9t is possile that these patterns could e used to re4eal
your identity. 9% you use many addresses though3 there *on/t e any patterns to %ind. <ote
that e4en though the addresses are pulicly 4isile3 noody kno*s *ho o*ns *hich
addresses3 so you can still e%%ecti4ely maintain your anonymity. Theoretically3 the
go4ernment or a skilled hacker could link your .itcoin address to an 9P address and
Department of ISE, RRIT-Bangalore-09 2014 Page 12

BITCOINS
get your identity %rom your internet ser4ice pro4ider. 9% you are *orried aout that3 you
should use .itcoin *ith the Tor ser4ice3 *hich *ould make it nearly impossile to %ind
your 9P address.
F
(lso3 to e anonymous you *ould ha4e to e 4ery care%ul aout ho*
you uy and sell your itcoins and only use untraceale payment methods like cash.
The keys in the *allet are cryptographic codes that enale trans%er o% itcoins %rom
your addresses to other addresses. The keys look like addresses3 ut they are longer3
containing &1 characters. 9% someone else gets access to the keys in your *allet3 they can
steal your itcoins y trans%erring it to one o% their addresses. 9% a hacker can hack into
your computer3 then they can proaly get your keys3 so make sure your system is secure.
Some people don/t %eel sa%e keeping their *allet on their PC %or this reason. Fortunately3
more secure *ays o% storing *allets are a4ailale.
Hard*are *allets are o%%line electronic de4ices that store keys in a micro$controller/s
memory. .ecause they are not connected to the internet and o%ten re;uire a user/s
con%irmation o% each transaction on the de4ice3 they are much harder to hack. To use a
hard*are *allet3 you setup a payment on your computer and then plug the de4ice into a
1S. port. The so%t*are on your computer *ill re;uest the keys %rom the de4ice and *ait
%or you to con%irm the transaction y pressing a utton on the de4ice. Then the de4ice
sends the keys to the computer to e2ecute the transaction.
The most secure type o% *allet is proaly the paper *allet3 *hich is :ust a piece o%
paper *ith keys *ritten on it. The main do*nside o% a paper *allet is that it is less
con4enient ecause you ha4e to type in a long string o% characters e4ery time you *ant to
make a payment. 9% you choose to make a paper *allet3 you should still e care%ul aout
ho* you make it. For e2ample3 printing it on a printer may e unsa%e. Sometimes printers
*ill store data in their internal memory3 *hich can e hacked.
The%t is not the only risk %actor *ith *alletsL you also ha4e to e 4ery care%ul to not
lose your *allet. 9% you lose your keys3 you lose all your itcoins3 so good ackups are
4ery important. 9% you are using a ne* address %or e4ery transaction3 it can e di%%icult to
ackup e4ery address indi4idually. ( good solution is to use a deterministic wallet3 *hich
Department of ISE, RRIT-Bangalore-09 2014 Page 13

BITCOINS
allo*s you to generate unlimited addresses %rom a single seed code. 9% you use a
deterministic *allet3 you only ha4e to ackup one code %or all o% your transactions
ecause all keys and addresses can e regenerated %rom the seed code. The (rmory and
'lectrum .itcoin clients oth use deterministic *allets3 though the .itcoin$Kt client does
not.
,unding 7our allet
<o* that you ha4e a *allet3 the ne2t step is to %ill it *ith itcoins. The simplest
option is to use a ser4ice that accepts currencies such as 1S dollars and sends itcoins to
an address that you pro4ide. 9% you *ant to get the est deal3 you should use an e2change.
(n e2change lets participants sumit orders to uy or sell itcoins at speci%ied prices3 or
:ust e2ecute an order at the current market price. The prices can e e2pressed in a 4ariety
o% other currencies such as 1S dollars or Gapanese Yen. Currently3 the iggest e2change is
Mt.Do2. 9t charges transaction %ees o% et*een C.6&7 and C.F7 depending on your 3C
day trading 4olume.
H

There are many other *ays o% otaining itcoins. .it9nstant is popular ser4ice that
accepts cash %or itcoins through MoneyDram agents at retail locations 5C+S3 Walmart3
Drocery stores3 etc.8 %or aout a #7 %ee. (nother ser4ice called Coinase allo*s you to
uy or sell itcoins using direct trans%ers toI%rom your ank account %or a 17 %ee. You
can e4en uy and sell itcoins through Craigslist or Eocal.itcoins y meeting in person
and paying cash.
9% you are a usiness o*ner and :ust *ant to accept itcoins3 you can %ill your *allet
y pulishing a .itcoin address and re;uesting that customers send %unds to that address.
Mining3 the means y *hich itcoins are initially put into circulation3 pro4ides
another *ay o% otaining itcoins. When mining3 you get paid itcoins to run a computer
that processes transactions %or the itcoin net*ork. Mining *ill e discussed more in
Chapter -.
Department of ISE, RRIT-Bangalore-09 2014 Page 14

BITCOINS
,igure 2-2' The @,ecei4e coins@ ta o% the .itcoin$Kt client *here you can manage your addresses.
Department of ISE, RRIT-Bangalore-09 2014 Page 15

BITCOINS
&ending Pay(ents

)nce you ha4e itcoins in your *allet3 you *ill e ale to see the alance in your
*allet on the )4er4ie* ta o% the .itcoin client. You can then use the .itcoin client to
send %unds to any other .itcoin user. (ll you need is one o% their addresses. Take the
destination address and enter it in the @Send coins@ ta along *ith the ;uantity you *ant
to send. You don/t ha4e to *orry aout mistyping the address ecause it has a uilt$in
checksumL i% there is a typo in the address3 the client *ill detect it and re:ect the
payment.
A
The ;uantity %ield has A digits to the right o% the decimal point so that itcoins
are di4isile to a granularity o% 1I1CC3CCC3CCCth o% a itcoin3 a ;uantity kno*n as a
Satoshi. (%ter you press the send utton3 the net*ork *ill spend aout an hour con%irming
the transaction. When the con%irmation is complete the recei4er *ill see their con%irmed
alance go up. .itcoin is not ideal %or in$store transactions ecause o% the long
con%irmation time3 ut merchants are still %ree to accept partially con%irmed or
uncon%irmed transactions3 *hich e%%ecti4ely trades %raud$resistance %or speed.
,igure 2-4' The 8&end coins8 ta! o+ the Bitcoin./t client where you can (a1e pay(ents-
Department of ISE, RRIT-Bangalore-09 2014 Page 16
Chapter 4
Cryptography
( digital payment system like .itcoin re;uires strong security against %raud. This
chapter introduces the cryptographic technologies that .itcoin utili0es to ensure that the
system can/t e %oiled y hackers.
Cryptographic *ash ,unctions
When transmitting data o4er a net*ork3 it is 4ery important to make sure that the data is
not corrupted during transmission. ( cryptographic hash function can help sol4e this
prolem. ( cryptographic hash %unction takes a se;uence o% ytes and computes a %i2ed$
length 4alue ased on the data3 called a hash or digest3 *ith some special properties?
9t is easy to compute the hash %or any input
Changing any it in the input produces a completely di%%erent output
9t is not %easile to %ind any input that corresponds to a gi4en output or any t*o
inputs *ith the same output
The hash %unction used in .itcoin is called SH($6&F. The output o% SH($6&F is 6&F its3
or 36 ytes. Here are some e2amples 5C2 at the eginning o% a numer means that the
numer is e2pressed in he2adecimal notation8?
sha6&F5M.itcoin/8 N C2#C&Fd%FF-1%AdcH6e&F3C6ddad3#&d
F&%ead3ead-6--FC-aA6Fe63##eF3aa#
sha6&F5Mitcoin/8 N C2FAAcCAH6#Haa6%CHee1c&-&FAe1a-
%#cH%A-6aHCe36#%13d1F1eC&ca1CH
'4en though the only di%%erence in the input is a change in the case o% the %irst letter3 the
outputs are unrecogni0aly di%%erent.
Hash %unctions are not :ust use%ul %or guarding against transmission %ailuresL they are
also 4aluale %or pre4enting tampering o% input data. For e2ample3 let/s say (lice and
.o are mo4ing into a t*o$edroom apartment together3 ut one edroom is igger than
the other. They oth pre%er the igger room3 ut it isn/t clear ho* much more one should
ha4e to pay %or it. <either one *ants to e the %irst to suggest a numer ecause it *ould
*eaken their argaining position. So they agree to the %ollo*ing protocol?
1. Write do*n a id %or ho* much they *ould pay per month to li4e in the igger
room.
6. Place the ids %ace do*n on the tale *ithout sho*ing the other person.
3. When oth ids are on the tale3 %lip the papers o4er to re4eal the ids.
#. The higher idder gets the igger room. The price the *inner pays is the a4erage o%
the t*o ids.
With this protocol3 oth parties are guaranteed to get a deal that is etter than or e;ual to
*hat they id %or.
<o* let/s say that .o is on a trip3 so this process has to e done remotely. 9% they
try to negotiate o4er the phone or email3 there is no guarantee that oth sides *ill
announce a numer at the same time. Hash %unctions can sol4e this prolem. (lice and
.o can each *rite do*n a sentence like @9/ll pay BF&C@ or @BHCC is my id@3 take the
hash3 and email the hash to the other person. (t this point3 neither kno*s the id o% the
other3 ut the ids are locked in. 9% one o% them tries to change their id3 they *ould ha4e
to %ind another sentence that matches the gi4en hash3 *hich is not %easile. (%ter
e2changing hashes3 (lice and .o e2change the sentences containing their ids and
compare. They each rehash the sentence o% the other to 4eri%y that the id *asn/t changed
since the hash e2change. 9% one o% them %inds that the hash doesn/t match3 they *ill kno*
it/s time to start looking %or a more honest roommate.
Di4en a hash o% a piece o% data3 it is possile to later con%irm that the data *as not
tampered *ith y rehashing the data and making sure that the hash comes out the same.
,igure 4-1' Calculating the SH($6&F hash o% a sentence using shasum in the Mac )SO Terminal. 9n the
Einu2 terminal3 sha6&Fsum can e used.
Mer1le Trees
Cryptographic hash %unctions are o%ten used to 4eri%y the integrity o% a list o%
items3 such as the roken$up chunks o% a large do*nload. 9n such cases3 one option is to
merge all the chunks and take the hash o% the complete do*nload. The prolem *ith this
is that i% one chunk is corrupted3 the user *on/t %ind out until the entire do*nload is
complete3 and e4en then they *on/t kno* *hich chunk is corrupt. ( etter solution is to
take the hash o% each chunk indi4idually so that each chunk can e 4eri%ied as it comes in.
Ho*e4er3 i% there are a large numer o% chunks3 then there is a greater chance that some
o% the hash 4alues *ill ecome corrupted. Furthermore3 this is a lot o% data %or the trusted
source to store. 9deally3 a trusted source *ould only ha4e to pro4ide one hash3 and the rest
o% the hashes could e do*nloaded %rom untrusted sources3 such as peers in a peer$to$peer
net*ork. This can e accomplished using a top hash generated y hashing all o% the
hashes o% the chunks. The resulting structure is called a hash list.
9% the numer o% chunks is 4ery large3 the list o% hashes o% all the chunks might also
e ;uite large. 9n order to 4eri%y :ust one chunk against the trusted top hash3 one *ould
need to otain all o% the hashes in the hash list. ,alph Merkle proposed the idea o% a hash
tree in 1-H-3 *hich allo*s a chunk to e 4eri%ied *ith only a logarithmic numer o%
hashes.= F > 9n a hash tree3 or Merkle tree3 hashes are taken o% all chunks as in a hash list3
ut then these hashes are paired and the hash o% each pair is taken3 and these hashes are
then paired again3 and so on until there is only one hash at the top o% this tree o% hashes.
,igure 4-2' The structure o+ a Mer1le Tree.
To 4eri%y the integrity o% :ust one chunk3 it is only necessary to otain a small suset
o% the hashes in the hash tree. For any hash in the tree3 i% the desired chunk is not in the
ranch elo* it3 then that ranch can e stued out y dropping it and keeping only the
hash at the top o% that ranch. For e2ample3 i% you *anted to 4eri%y data lock 1 in the
diagram3 you need Hash C$C3 Hash C$13 Hash C3 Hash 1 and the Top hash. The ranch
rooted y Hash 1 can e stued out3 remo4ing Hash 1$C and Hash 1$13 keeping :ust Hash
1 to represent the *hole ranch. For large trees3 the numer o% hashes needed to 4eri%y
one chunk can e much smaller than the numer o% chunks.
Pu!lic 9ey Cryptography
.itcoin does not do any encryptionL all transaction in%ormation is pulicly 4isile.
Ho*e4er3 it does rely hea4ily on digital signing3 *hich is a technology ased on pulic
key cryptography.
'arlier %orms o% cryptography *ere ased on the idea o% secretly sharing an
encryptionIdecryption key that *ould e kept pri4ate at all times. This method3 kno*n as
private key cryptography3 is use%ul in situations *here t*o parties can communicate
pri4ately at one point in time and *ant to e ale to securely communicate o4er an
insecure channel3 like radio or the internet3 at a later point in time. The simplest and most
secure encryption scheme is called one-time pad encryption. ( one-time pad is a long
string o% its 50eroes and ones8 that ser4es as an encryptionIdecryption key. To encrypt a
message3 the one$time pad is lined up ne2t to the its o% the message3 and %or any position
*here the pad has a 13 the corresponding it in the message is %lipped. To decrypt the
encrypted message3 the e2act same procedure is used. 9t is called @one$time@ ecause once
a portion o% the it se;uence is used3 it is thro*n out and ne4er used again. )ne$time pad
encryption is 4ery simple and has een mathematically pro4en to e asolutely
impossile to crack.= H > The only prolem is that the t*o parties ha4e to e2change the
one$time pad *ithout e2posing it to anyone else. This may e %ine i% oth parties can meet
in$person3 ut it isn/t 4ery help%ul %or communicating o4er the internet.
Pulic key cryptography allo*s encrypted communication *ithout pri4ate key
e2change. 9% (lice and .o *ant to talk securely3 they can do so y agreeing to use the
%ollo*ing protocol. First3 they each run a special algorithm to produce a key pair
consisting o% a pulic key and a pri4ate key. They each keep their pri4ate keys secret ut
pulish their pulic keys3 *hich ecome 4isile to the *hole *orld. The pulic and
pri4ate keys ha4e a special mathematical relationship that allo*s (lice to encrypt a
message M using .o/s pulic key K
pub
that only .o/s pri4ate key K
priv
can decrypt.
Eetting C denote the encrypted message3
This is accomplished y using mathematical %unctions that are computationally
intractale to in4ert. For e2ample3 it is 4ery easy to multiply t*o large prime numers3 ut
it is much more di%%icult to %ind the prime %actors o% a product. The mathematical details
are eyond the scope o% this ook3 ut search %or @,S(@ %or more in%ormation.
1sing pulic key cryptography3 secure messages can e sent et*een indi4iduals
*ho ha4e only e4er had contact through insecure channels3 such as the internet.
Digital &ignatures
!ey pairs in pulic key cryptography are complementary in that they can e%%ecti4ely e
s*apped. For normal encryptionIdecryption3 the pulic key is used to encrypt and the
pri4ate key is used to decrypt. 9% instead the pri4ate key is used to encrypt3 then only the
corresponding pulic key can e used to decrypt the result. This can e used to create a
digital signature that pro4es that a particular indi4idual sent a message. ( recipient o% a
signed message can con%irm that a message *as not sent y an impostor 5authenticity83
*as not tampered *ith 5integrity83 and can dispro4e any sender *ho denies sending the
message 5nonrepudiation8. This is e2actly *hat the .itcoin systems needs to pre4ent
%raudulent transactions.
To send a signed (essage with contents M'
1. Take the hash o% M?
6. 'ncrypt H *ith the pri4ate key to get the signature?
3. Send the signature S along *ith the message M
To veri+y that a signature S is valid +or (essage M'
1. Take the hash o% M?
6. "ecrypt S *ith the pulic key?
3. Compare to see i% H N HP. The signature is 4alid i% they are the same.
.itcoin uses a digital signature scheme called the 'lliptic Cur4e "igital Signature
(lgorithm 5'C"S(8. The mathematics underlying the algorithm are rather comple2. 9t is
more comple2 than the more common ,S( pulic key crypto$system3 ut it is considered
to e more secure %or a gi4en key length.
Chapter :
Digital Currencies
Properties
( secure digital payment system should ha4e the %ollo*ing properties to pre4ent %raud?
1. (uthenticity $ )nly the o*ner o% a ;uantity o% money can spend it
6. Security $ Money can not e counter%eited 5token %orgery83 and the o*ner can only
spend it once 5the @doule$spending@ prolem8
3. <onrepudiation $ ( recipient cannot deny recei4ing money
<onrepudiation is not as crucial as the other t*o3 ut i% the system did not ha4e this
property3 it *ould e impossile to aritrate disputes in *hich a seller denied recei4ing
payment and re%used to pro4ide the merchandise.
There are also three optional properties that make the system more po*er%ul?
-

1. (nonymous $ payer identi%ication is not disclosed to payee or third parties 5this can
e roken do*n into three components? payer anonymity3 untraceaility3 and
unlinkaility8
6. )%%line $ payee can e con%ident that they *ill recei4e %unds %rom a transaction
*ithout immediately contacting a third party such as a ank
3. "ecentrali0ed $ there is no trusted authority 5e.g. ank8 needed to process
transactions
Digital cash is de%ined to e any digital payment system that satis%ies properties 1$#.= 1 1 >
.itcoin doesn/t completely satis%y property #3 so it is not technically digital cash3 ut it is
close ecause it is pseudonymous.
Dou!le.&pending
(ll electronic payment systems rely hea4ily on cryptography. "igital signing can
easily e used to guarantee most o% properties 1$33 ut it doesn/t help pre4ent the prolem
o% @doule$spending@.
"oule$spending is a type o% digital payment %raud in *hich a user tries to spend the
same money t*ice. For e2ample3 imagine Chuck has a deit card *ith B1CC in his
account. <o* let/s say he opens t*o tas in his *e ro*ser3 one %or (ma0on and one
%or 'ay. 9n each o% these tas3 he adds a B1CC item to his cart3 enters his deit card
numer3 and presses sumit at almost the same time. 9% his ank had really ad security3
oth sites *ould see that he had B1CC in his account and appro4e the purchase3 yielding
B6CC *orth o% goods. This is a doule$spend. For online centrali0ed systems such as
credit cards3 detecting doule$spending is easy since all transactions are seen
immediately. For o%%line or decentrali0ed systems3 ho*e4er3 it is more di%%icult.
Sol4ing the doule$spending prolem is the main hurdle that digital payment systems
need to o4ercome. The tricky part aout doule$spending is that each payment *ould e
completely legitimate i% the other didn/t e2ist. The only *ay to detect doule$spending is
to e a*are o% all transactions and look %or duplicates.
(%ter detecting a doule$spend3 there are a couple o% options. )ne option is to re4eal
the identity o% doule spenders so that the 4ictims can sue. )4iously3 this isn/t ideal
ecause it *ould re;uire a lot o% legal o4erhead and *ould still re;uire some trusted
authorities in the system3 e4en i% only the courts.
The est option is to only consider the %irst transaction o% a doule$spend to e 4alid.
,e:ecting oth doule$spend payments *ould e ad ecause recipients *ould ne4er
ha4e con%idence that their incoming payments *ere secure. The sender could later
doule$spend and they *ould lose their %unds. So in this case it is necessary that the
system e ale to determine *hich o% t*o doule$spend payments came %irst. .itcoin/s
solution to this prolem *ill e discussed in Chapter A.
Types o+ Digital Pay(ent &yste(s
Type 1- Credit;De!it Cards <Properties 1.4=
Most o% the *orld is still operating *ith the most primiti4e type o% electronic
payment system? credit cards and deit cards. These transactions are @identi%ied@ ecause
the merchant can see the o*ner/s name on the card and the credit card company can track
their purchases. These transactions are also @online3@ *hich means that merchants must
contact a ank or credit card company %or e4ery transaction to 4eri%y that %unds are
a4ailale. (nd these transactions are @centrali0ed@ ecause the system doesn/t *ork
*ithout the credit card company or ank. This also means that i% the credit card company
or ank decides to %ree0e a user/s account3 the user *ould lose access to their money.
Type 2- Digital Cash <Properties 1.:=
9n 1-A63 "a4id Chaum pulished a paper called @.lind signatures %or untraceale
payments3@= 1 6 > *hich contained the %irst description o% a digital cash scheme. 9n
Chaum/s proposed system3 anks issue cryptographically signed digital notes that can e
used anonymously like cash. 9ndi4iduals may re;uest digital notes %rom the ank %or a
speci%ied amount o% money. The ank then creates a set o% special digital notes that only
the ank can produce *ith its secret cryptographic key. 'ach note issued is *orth a %i2ed
;uantity3 say B13 and *hoe4er has access to the note can spend it3 so it can e stolen :ust
like cash. When the ank sends the notes to the customer3 it simultaneously deducts the
corresponding ;uantity %rom the customer/s ank account. (t this point3 the ank kno*s
*ho they issued the notes to3 ut the customer then modi%ies the notes in such a *ay that
the ank is not e ale to trace them. Ho*e4er3 e4en a%ter the modi%ication3 the ank can
still 4eri%y that they *ere in %act notes issued y that ank.
This is the magic o% lind signatures that Chaum introduces. He e2plains it *ith an
paper$ased analogy. Eet/s say (lice is a customer at Chaum .ank and *ants some paper
lind signature notes. She goes to the ank and approaches the desk *ith the old$
%ashioned deposit slips. .ut at Chaum ank3 there are also stacks o% lind note %orms3
en4elopes3 and caron paper. The lind note %orm :ust has a long se;uence o% empty
o2es *here (lice %ills in random numers to %orm a uni;ue serial numer3 and a line %or
a signature that she lea4es lank. She puts this paper and a slip o% caron papering an
en4elope3 seals it3 and rings it to the teller. The teller asks %or (lice/s 9"3 signs the
en4elope *ith a special signature that indicates it is *orth B1CC3 and deducts B1CC %rom
(lice/s account. (s (lice lea4es the ank3 she opens the en4elope and e2tracts the lind
signature %orm that no* has the ank/s signature on the signature line ecause o% the
caron paper. She can no* spend this note at her %a4orite store. The merchant then takes
the note ack to the ank. The teller 4eri%ies the signature and makes sure that the serial
numer has not already een used to ensure that (lice didn/t photocopy the note. 59n the
cryptographic case3 (lice can create an e2act duplicate o% the note3 ut she can/t modi%y it
in any *ay3 so *e don/t ha4e to *orry aout her changing the serial numer a%ter the
ank signs it. (lso3 since (lice chooses a serial numer randomly3 it is nearly impossile
%or it to e a duplicate on accident.8 9% e4erything checks out3 the ank credits the
merchant/s account *ith B1CC. Since the ank didn/t see the serial numer *hen (lice
got the note signed3 there is no *ay to tell that the merchant/s note came %rom (lice. (t
the end o% this process3 B1CC got trans%erred %rom (lice/s account to the merchant/s
account *ithout the ank kno*ing that (lice did usiness *ith the merchant3 and *ithout
the merchant needing to kno* *ho (lice is. )% course3 the merchant has to get
con%irmation %rom the ank e%ore gi4ing (lice her merchandise3 so this is still an
@online@ system3 ut electronically this can e done almost instantly.
Type 4- O++line Digital Cash <Properties 1.>=
)%%line payment systems ha4e a signi%icant challenge that online systems don/t
ha4e. They ha4e to allo* transactions to clear *ithout contacting the trusted authority3
such as the ank. (t %irst this seems impossile3 ecause i% a customer uses the same
piece o% digital cash at t*o merchants consecuti4ely3 and oth o% those merchants are
disconnected %rom the rest o% the system3 then there is no *ay to tell that the cash *as
doule$spent. .ut i% the merchants could identi%y the customer3 they could later sue the
customer %or the %raudulent transaction *hen they %ind out %rom the ank that the digital
cash *as doule$spent. The only prolem *ith this solution is that i% the merchant can
identi%y the customer3 the system is no longer anonymous. 9t turns out there is a *ay to
re4eal the customer/s identity only a%ter a doule spend. This is the idea %irst presented y
Chaum3 Fiat3 and <aor in their 1-A- paper @1ntraceale 'lectronic Cash@.= 1 3 >
The idea is to attach a set o% ! pairs o% numers to e4ery digital cash note. (ny
single pair contains enough in%ormation to re4eal the o*ner/s identity3 ut one numer
%rom each pair is not enough to determine anything. '4ery time a note is spent3 the
merchant issues a challenge that re;uires one numer %rom each pair. The merchant
randomly chooses *hich numer %rom each pair the customer must present. 9% t*o
merchants randomly get one numer %rom each pair %or the same note3 it is 4ery likely
that they *ill ha4e at least one pair *here they chose di%%erently3 so together they ha4e
the complete pair. When they oth sumit their records to the ank at a later date3 the
ank can comine the t*o parts o% the pair to re4eal the thie%/s identity.
Type :- Decentrali?ed Digital Currency <Properties 1.4@ 6=
.itcoin is the %irst decentrali0ed digital currency. Making a decentrali0ed system
is signi%icantly more challenging than making a centrali0ed system3 so some sacri%ices
had to e made on the other properties listed at the start o% the chapter. .itcoin re;uires
net*ork access %or payment 4eri%ication3 so it is not o%%line and does not satis%y property
&. 9t is also not anonymous ecause all transactions are pulicly announced3 so it does not
satis%y property # either. Ho*e4er3 it is pseudonymous3 *hich means that it is possile %or
users to a4oid re4ealing their identity i% they are care%ul. The rest o% this ook *ill e2plain
ho* .itcoin *orks.
Chapter >
Precursors
Triple #ntry Accounting
The *ay .itcoin records o*nership is ased on an idea originally presented in
6CC& y 9an Drigg called @Triple 'ntry (ccounting@.= 1 # > 9n this system3 payment
receipts are not :ust 4eri%ication that the o*nership ledger changed3 the receipts
themsel4es are the ledger. 9t is called @triple entry@ ecause the sender3 recei4er3 and a
third party all ha4e a copy o% the receipt3 and any single copy pro4ides su%%icient proo% o%
the transaction. Drigg e2plains ho* digital signatures can e used to sign the receipts so
that they cannot e %orged or repudiated. 9% (lice *ants to send money to .o3 (lice
creates a message that assigns a speci%ied ;uantity o% her money to .o and signs the
message *ith her pri4ate key3 much like a paper check. This signed message is the receipt
o% the transaction and anyone can use this receipt to con%irm that (lice made the payment.
The third party in Drigg/s triple entry accounting system *as a trusted authority that
*ould issue money and 4eri%y that the sender had enough %unds to make the payment.
.itcoin does not ha4e any trusted authorities3 so it must per%orm these checks di%%erently.
Pu!licly Announced Transactions
Some o% the concepts .itcoin uses to maintain a decentrali0ed ledger are ased on
a digital currency proposal that Wei "ai presented in 1--A called @.$Money@.= 1 & > 9n
"ai/s proposed system3 e4ery participant maintains a log o% ho* much money elongs to
each pseudonym and money is trans%erred y pulicly announcing a digitally signed
message. .oth o% these concepts are used in .itcoin. Furthermore3 .itcoin/s method o%
creating ne* money ased on an in4estment o% computation time is similar to "ai/s3
*here sol4ing a di%%icult computational prolem constitutes a proof of work that is
re*arded *ith ne* money.
Proo+ o+ or1
.oth "ai and <akamoto cite (dam .ack/s 1--H Hashcash protocol= 1 F >3 *hich is a proo%
o% *ork scheme originally designed to %ight email spam. When using Hashcash3 the
sender/s email client sol4es a di%%icult computational prolem e4ery time it sends an
email. The recei4er considers this e4idence that the sender is not a spammer ecause it
*ould e e2pensi4e %or spammers to sol4e the prolem %or e4ery email sent.
Conceptually3 this is similar to charging a small %ee %or e4ery email sent3 ut instead o%
money3 the %ee is :ust a it o% computer time.
The idea o% using a proo% o% *ork to %ight email spam *as originally pulished y
"*ork and <aor in 1--3.= 1 H > Hashcash di%%ers in the proo% o% *ork prolem it uses. 9n
Hashcash3 the computational prolem is to %ind a 4alue that has a hash starting *ith a
speci%ied numer o% 0eroes. This is con4enient ecause it is 4ery %ast to 4eri%y and easy to
proailistically estimate ho* much *ork it takes to sol4e the prolem3 ecause the only
kno*n method is to try random 4alues until a solution is %ound. .itcoin adopted this proo%
o% *ork prolem *ith slight modi%ications.
Chapter 6
Technical Overview
Architecture
.itcoin is run y a peer$to$peer net*ork o% computers called nodes. <odes are responsile
%or processing transactions and maintaining all records o% o*nership. (nyone can
do*nload the %ree open$source .itcoin so%t*are and ecome a node. (ll nodes are treated
e;uallyL no node is trusted. Ho*e4er3 the system is ased on the assumption that the
ma:ority o% computing po*er *ill come %rom honest nodes 5see Chapter A8. )*nership
records are replicated on e4ery %ull node.
Ownership
There are t*o *ays to track o*nership o% a currency?
1. Possession o% a token that independently represents 4alue 5e.g. paper cash3 metal
coins3 and Chaum/s digital cash8
6. Possession o% a key that controls access to records in a ledger 5e.g. checks3 credit
cards3 Paypal3 and .itcoin8
"esigning a decentrali0ed currency is challenging ecause it is not o4ious ho*
either o% these methods can e used *ithout some trusted authority like a ank. 9n method
13 someody has to issue the tokens and in method 63 someody has to maintain the
ledger. 9% anyone can issue tokens or edit the ledger3 then the system is ound to %ail.
.itcoin uses the ledger$ased method3 ut it manages to *ork due to a no4el method that
allo*s a distriuted net*ork o% untrusted peers to maintain a trust*orthy ledger.
.itcoin/s ledger3 kno*n as the block chain3 can e thought o% as a record o% receipts
%or all transactions that ha4e e4er occurred in the .itcoin system. 1nlike a typical ank/s
ledger3 it doesn/t contain any account alances. ,ather than recording a ;uantity o%
itcoins %or each o*ner3 it records an o*ner %or each ;uantity o% itcoins transacted. The
o*ner is :ust the recipient listed on the transaction receipt in the lock chain 5until the
itcoins in that transaction are spent8. To spend itcoins3 the o*ner creates a ne*
transaction that takes the itcoins %rom a prior transaction 5one that *as sent to the o*ner8
and assigns them to someone else. The o*ner is the only one *ho has the aility to create
such a transaction ecause it re;uires their digital signature.
The pre4ious transaction %rom *hich itcoins are taken is called an input. When a
transaction is used as an input3 *e say that the transaction itsel% is spent ecause all o% its
4alue *ill e sent to the recipient5s8 and the transaction can ne4er e used as an input
again. 9% an input/s 4alue is greater than the desired payment amount3 that is not a
prolemL transactions allo* multiple recipients3 so the o*ner can send a portion o% the
input/s 4alue ack to one o% their o*n addresses as change.
Addresses
(s pre4iously mentioned3 the lock chain doesn/t record o*ners y their true
identitiesL it uses codes called addresses 5introduced in section 6.18. 9t is di%%icult or
sometimes impossile to connect an address to a person unless the person allo*s it3 *hich
pro4ides a degree o% anonymity. To create an address3 the .itcoin client %irst generates a
pulic$pri4ate key pair. The address is then %ormed y a applying the %ollo*ing %unction
to the pulic key 5in pseudocode3 QQ represents concatenation8?=1->
4ersion N 51 yte 4ersion numer8 keyHash N ,9P'M"$1FC5SH($6&F5pulic!ey88 data
N 4ersion QQ keyHash
dataHash N SH($6&F5SH($6&F5data88 checksum N 5%irst # ytes o% dataHash8 address N
.ase&A'ncode5data QQ checksum8
The 4ersion yte represents the 4ersion o% the address3 *hich has the 4alue o% C %or
normal addresses on the main .itcoin net*ork.
1C
The ,9P'M"$1FC %unction is a hash
%unction *ith a 6C yte output. .ase&A'ncode con4erts a inary 4alue to a string o%
numers and letters. .ecause the %irst yte in the input to .ase&A'ncode is the 4ersion
yte3 *hich is C3 all normal addresses start *ith the digit @1@ ecause 1 is the .ase&A
representation o% C.
The *hole address generation %unction is a hash %unction itsel%3 so addresses are :ust
hashes o% pulic keys. .itcoin could ha4e used pulic keys directly *ithout hashing3 ut
there are three ene%its that hashed addresses ha4e o4er pulic keys?=63>
1. (ddresses are shorter than pulic keys.
6. (ddresses ha4e uilt$in checksums so that a mistyped address can e detected.
3. (ddresses are more secure against cryptographic attacks. '4en i% someone came up
*ith a *ay to re4erse the supposedly one$*ay %unction in the elliptic cur4e digital
signature algorithm3 they *ould still need the pulic key to use it. With :ust the
address3 the only option is a rute$%orce attack 5trying e4ery possile pri4ate key
until one *orks8.
Chapter B
Transactions
&tructure
When a .itcoin user initiates a payment3 the client creates a transaction message
and sumits it to the peer$to$peer net*ork. ( transaction contains the %ollo*ing
in%ormation3 *ith CT29n and CT2)ut sho*n elo*?
1

1

class CTransaction int n+ersionL
std''vectorCCT$InD vinE std''vectorCCT$OutD voutE unsigned int n3oc1Ti(eE
,igure B-1' "iagram o% a .itcoin trans%er *here ( is sending itcoins to .. The transaction on the le%t
sho*s multiple inputs 5CT29n8 in 4in and multiple outputs 5CT2)ut8 in 4out toillustrate that 4in and
4out are arrays. The laels @5nNC8@ and @5nN18@ indicate the position in the array. The contents o% the inputs
5CT29n8 and outputs 5CT2)ut8 on the le%t are hidden to simpli%y the diagram.
.asically3 the transaction message lists a set o% inputs 54in83 *hich re%ers to pre4ious
transactions3 and a set o% outputs 54out83 *hich speci%ies destination addresses. This
allo*s a transaction to pull money %rom multiple sources3 pool it together3 and then
distriute it to multiple destinations. )% course3 any transaction that distriutes more
money than it pulls in *ill e considered in4alid and *ill e ignored 5e2cept coinase
transactions that *ill e e2plained later8. The n+ersion 4ariale is a 4ersion numer %or
the transaction so that the peer$to$peer net*ork can still %unction e4en *hen di%%erent
nodes ha4e di%%erent 4ersions o% the .itcoin code running. The nEockTime 4ariale can
e used to pre4ent the transaction %rom eing processed e%ore a speci%ied time3 *hich is
use%ul %or making contracts.
1

6

class CT29n
C)utPoint pre4outL CScript scriptSigL unsigned int nSe;uenceL
class C)utPoint uint6&F hashL unsigned int nL
(n input 5CT29n8 re%erences an output o% a pre4ious transaction 5pre4out83 *hich is
the output to e spent. 9n order to uni;uely re%erence an output3 it is su%%icient to pro4ide
the hash o% the transaction the output is in 5hash8 and the inde2 o% the output *ithin that
transaction/s 4out 4ector 5 n8. This is precisely the data contained in C)utPoint3 the type
o% pre4out. This output re%erenced in pre4out *ill e completely spent. 9% the user *ants
to spend only a portion o% the pre4ious output3 they can create an e2tra output in the ne*
transaction that points ack to their o*n *allet3 :ust like recei4ing change in a cash
transaction.
9nputs also speci%y a scriptSig that contains the o*ner/s pulic key and a signature to
pro4e that the spender o*ns the output eing spent. The CScript type e2tends
std??4ectorRunsigned charS3 so it/s a type o% string class. The nSe;uence 4ariale3 along
*ith nEockTime is used %or making contracts 5see the %ootnote %or nEockTime8.
class CT2)ut intF# n+alueL
CScript scriptPu!eyL
( simple transaction output 5CT2)ut8 speci%ies an address 5in scriptPu!ey8 and
ho* much to send to that address 5n+alue83 speci%ied in Satoshis3 the smallest unit in the
.itcoin currency3 *orth 1I1CC3CCC3CCCth o% a itcoin. The script is customi0ale though3
so it can e more complicated than :ust speci%ying a destination address. More
complicated scripts can e used to create customi0ed contracts that pre4ent a transaction
%rom completing until certain conditions are met.
%eri+ication
(%ter a .itcoin client sumits a ne* transaction to the peer$to$peer net*ork3 other
nodes in the net*ork *ill start trying to process it into the lock chain 5this procedure *ill
e e2plained in Chapter -3 @Mining@8. The %irst step in this process is to make sure that
the transaction is 4alid. The %ollo*ing checks are per%ormed during 4alidation?
'nsure that transaction passes 4arious sanity checks 5ounds checking3
syntactic correctness3 etc.8.
,e:ect i% this e2act transaction is already in the lock chain or pool o%
transactions *aiting to e processed. This pre4ents the same transaction
%rom eing processed t*ice.
For each input3 concatenate the scriptSig script o% the input *ith the script
Pu!ey script o% the output that it re%erences3 e2ecute this script3 and 4eri%y
that the result is True. 9% these scripts are o% the standard %ormat3 this *ill
con%irm that the o*ner o% the itcoin initiated the transaction. ,e:ect i% any
o% the transaction outputs speci%ied in the transaction/s inputs ha4e already
een used in another transaction in the lock chain. This is used to pre4ent
doule$spending.
'nsure that the sum o% the input 4alues is greater than or e;ual to the sum o%
the output 4alues 5i% the inputs are greater3 the di%%erence is the transaction
%ee3 *hich is paid to the miner o% the transaction 5see Section -.#88.
The script e2ecution step re;uires %urther e2planation. The purpose o% the script is to
4eri%y that the transaction *as digitally signed y the o*ner 5the person the pre4ious
transaction *as sent to8. Transactions only speci%y an address as a destination3 ut
addresses are :ust hashes o% pulic keys. So asically3 the script/s :o is to make sure the
hash o% the pro4ided pulic key is the destination address o% the pre4ious transaction and
this same pulic key elongs to the user *ho signed the transaction. 9n python3 the script
*ould look something like this 5racketed names represent hard$coded 4alues in the
script8?
de% scriptSig58?
return RsigS3 Rpu!eyS
de% scriptPu!ey5t2Hash8? sig3 pu!ey N scriptSig58
return 5hash5pu!ey8 NN Rpu!eyHashS and 4eri%ySig5sig3 pu!ey3 t2Hash88
The parameter t2Hash is a hash o% some parts o% the transaction3 and this hash is the
message that *as signed to generate the signature. This ensures that these parameters o%
the transaction can not change *ithout a ne* signature. The script in .itcoin looks ;uite a
it di%%erent though3 ecause .itcoin uses its o*n custom scripting language.
&cripting
The scripting language used in .itcoin is a stack$ased language similar to Forth. 9t is
intentionally not Turing$complete so that it can e e2ecuted *ithout concern %or *hether
the script *ill hang. 9t *orks like a re4erse polish notation calculator. The script is read
%rom le%t to right. When a 4alue is encountered in the script3 it is pushed onto a stack.
When an operator is encountered in the script3 some 4alues are popped o%% the stack3 the
operator is applied to these 4alues3 and the result is pushed onto the stack.
There are only a %e* operators that are used in standard transactions.
)PT"1P $ Pop one 4alue o%% the stack and push t*o copies o% it ack onto the
stack. )PTH(SH1FC $ Pop one 4alue o%% the stack3 apply a hash %unction3 and
push the hash onto the stack.
)PT'K1(E+',9FY $ Pop t*o 4alues o%% the stack3 i% they are e;ual3 do nothing3
i% they are not e;ual3 aort the script *ith return code %alse.
)PTCH'C!S9D $ Pop t*o 4alues o%% the stack and assume that the %irst is a
pulic key and the second is a signature. Check the signature using the pulic key3
assuming the message signed *as a simpli%ied transaction *ith some parts
remo4ed. This operator has direct access to the transaction as i% it *ere a hidden
gloal 4ariale in the script. 9% the signature is 4eri%ied3 push True onto the stack3
other*ise push False onto the stack.
( standard transaction uses the %ollo*ing scripts.
scriptPu!ey N @)PT"1P )PTH(SH1FC Rpu!eyHashS )PT'K1(E+',9FY
)PTCH'C!S9D@
scriptSig N @RsigS Rpu!eyS@
*here sig is the signature o% a simpli%ied transaction3 pu!ey is the o*ner/s pulic key3
and pu!eyHash is the address that the itcoins *ere pre4iously sent to 5and currently
elong to8. For
a 4alid transaction3 pu!eyHash should e the same as the hash o% pu!ey to guarantee
that the person spending the itcoins is their true o*ner. Concatenating the scripts3 *e get
script N @RsigS Rpu!eyS )PT"1P )PTH(SH1FC Rpu!eyHashS
)PT'K1(E+',9FY )PTCH'C!S9D@
.
Chapter F
Mining
Procedure
The process o% creating ne* locks is called mining3 and nodes that do mining are called
miners. Mining consists o% the %ollo*ing steps3 per%ormed in a continuous loop?
Collecting transactions that *ere roadcast on the peer$to$peer net*ork into a lock.
'ach miner can aritrarily decide *hich transactions to include in their lock.
Transactions typically ha4e a %ee that the miner *ill recei4e i% their lock is
accepted3 so miners ha4e an incenti4e to include as many transactions as possile3
up to the 1 megayte lock si0e limit. 1 #
1. +eri%ying that all transactions in the lock are 4alid 5as e2plained in section H.68.
6. Selecting the most recent lock on the longest path in the lock chain and inserting
a hash o% its header into the ne* lock 5as e2plained in section A.68.
3. Trying to sol4e the proo% o% *ork prolem 5discussed in the ne2t section8 %or the
ne* lock and simultaneously *atching %or ne* locks coming %rom other nodes.
9% a solution is %ound to the proo% o% *ork prolem3 the ne* lock is added to
the local lock chain and roadcasted to the peer$to$peer net*ork.
9% another node sol4es the proo% o% *ork prolem %irst 5most likely83 the proo%
o% *ork and the transactions in their lock are checked %or 4alidity. 9% the
checks pass3 their lock is added to the local copy o% the lock chain and
relayed on the net*orkL other*ise their lock is discarded.
(ll miners are trying to create ne* locks at the same time3 *ith almost all their time
eing spent on the proo% o% *ork prolem. Since nodes cannot communicate
instantaneously3 di%%erent nodes may ha4e slightly di%%erent 4ersions o% the lock chain at
any gi4en instant3 ut under normal circumstances the 4ast ma:ority o% nodes *ill e in
agreement. This is ecause ne* locks are created at a regulated rate o% one e4ery 1C
minutes or so 5see section -.33 @"i%%iculty Targeting@83 *hereas propagation o% a ne*
lock only takes seconds. So normally there is a period o% 5on a4erage8 1C minutes *here
all the nodes are churning through the proo% o% *ork prolem3 until one random node is
lucky enough to sol4e it. Then the ne* lock is roadcast and *ithin seconds all the
nodes accept it and start *orking on the %ollo*ing lock. When t*o nodes coincidentally
create a ne* lock at aout the same time3 the nodes may e split %or a *hile on *hich
;uickly 5see the .lock Chain chapter8.
There is no guarantee that all miners *ill e processing the same set o% transactions
at any gi4en time ecause miners select transactions aritrarily %or inclusion into their
locks. Ho*e4er3 it is likely that there *ill e a lot o% o4erlap in the sets o% transactions
that miners are processing since each miner *ill try to include as many as possile. So
*hen a ne* lock is added to the lock chain3 some portion o% the transactions that *ere
eing processed may not ha4e made it into the ne* lock. These transactions are kept in
the pool o% unprocessed transactions so that miners can choose to include them in the ne2t
lock.
Proo+ o+ or1
Miners search %or acceptale locks using the %ollo*ing procedure3 per%ormed in a loop?
1. 9ncrement 5add 1 to8 an aritrary numer in the lock header called a nonce.
6. Take the hash o% the resulting lock header 5see C.lockHeader3 sho*n elo*8.
3. Check i% the hash o% the lock header3 *hen e2pressed as a numer3 is less than a
predetermined target 4alue.
9% the hash o% the lock header is not less than the target 4alue3 the lock *ill e re:ected
y the net*ork. Finding a lock that has a su%%iciently small hash 4alue is the proo% o%
*ork prolem3 :ust as in (dam .ack/s Hashcash 5see section &.38. The target %or
Hashcash *as a certain numer o% 0eroes at the eginning o% the inary representation o%
the hash3 *hich means that all targets are po*ers o% t*o. .itcoin generali0es this y
allo*ing targets to e numers that start *ith 0eroes %ollo*ed y a speci%ied pattern o%
inary digits3 not all o% *hich ha4e to e 0ero.
.ecause o% the properties o% cryptographic hash %unctions3 there is no etter *ay to
%ind a solution than this rute$%orce method. The proo% o% *ork is a useless computation
aside %rom the %act that it gi4es a proailistically predictale cost to lock creation.
class C.lockHeader int n+ersionL
uint6&F hashPre4.lockL uint6&F hashMerkle,ootL unsigned int nTimeL unsigned int
n.itsL unsigned int n<onceL
class C.lock ? pulic C.lockHeader std??4ectorRCTransactionS 4t2L
n+ersion is a 4ersion numer to support multiple concurrent 4ersions on the
net*ork. hashPre4.lock is a doule SH($6&F hash o% the header o% the pre4ious lock in
the lock chain. This is the @pointer@ that links locks and de%ines the chain structure.
hashMerkle,oot is the top hash o% the Merkle tree %or all the transactions in the lock 5all
transactions in 4t28. nTime is the appro2imate time *hen the lock *as created3 speci%ied
as a uni2 timestamp 5seconds since the %irst second o% the year 1-HC8. n.its is a
compressed representation o% the target %or the proo% o% *ork. n<once is the nonce that is
incremented *hen trying to sol4e the proo% o% *ork prolem.
Di++iculty Targeting
9t is important that ne* locks are not created too ;uickly or too slo*ly. 9% locks are
continually created %aster than the time it takes %or them to e distriuted o4er the
net*ork3 then the lock chain *ill ecome %ull o% %orks. Too many %orks make it much
harder %or nodes to reach a consensus on *hich ranch o% the lock chain to use. )n the
other hand3 i% locks are created too slo*ly3 it takes too long %or transactions to e
con%irmed.
)4er time3 as more miners start mining and as hard*are speed increases3 the rate o%
sol4ing the
proo% o% *ork prolem %or a gi4en di%%iculty le4el *ill likely increase. This gro*th can/t
e accurately predicted3 so .itcoin nodes acti4ely regulate the rate o% creation o% ne*
locks so that it takes an a4erage o% 1C minutes to create each lock. The regulation is
done y periodically ad:usting the hash target 4alue %or locks. Since the hash o% the
lock/s header must e less than the target3 a smaller target makes it harder to %ind
acceptale locks.
'4ery 6C1F locks 5*hich spans 6 *eeks i% each lock takes 1C minutes83 the nodes
calculate a ne* di%%iculty ased on the time it took to mine the last 6C1F locks. ( hash
4alue is a numer *ith 6&F its3 so there are 6
6&F
possile hash 4alues. The proaility o%
%inding a hash 4alue less than T in a single trial is
The e2pected numer o% trials needed to %ind a hash less than a target T is
9% the last 6C1F locks *ere mined in an a4erage time o% t
avg
using a target o% T3 then *e
can estimate that the miners *ere collecti4ely hashing at a rate o% aout
The e2pected time to disco4er a lock %or a di%%iculty T and hash rate r is
So the target should e ad:usted to TP so that t5TPr
est
8 N FCCs3 or 1C minutes.
This target is not al*ays used though ecause there is an additional rule that the target can
only change y a %actor o% # up or do*n in an single retargeting.
The difficulty D is de%ined as the ma2imum target o4er the current target3 *here the
ma2imum target is F&&3& U 6
6CA
3
0eward
Sol4ing the proo% o% *ork prolem re;uires a lot o% computing po*er and that
po*er costs money. To encourage people to in4est their resources in mining3 .itcoin
pro4ides a re*ard in each success%ully mined lock. (s the %irst transaction in each lock3
miners insert a coinbase transaction 5also kno*n as a generation transaction8 that pays a
re*ard to themsel4es. The coinase transaction has e2actly one input3 ut the pre4out
%ield o% the input is set to <1EE ecause it is creating ne* itcoins3 not trans%erring them.
The output o% the coinase transaction speci%ies one o% the miner/s addresses so that they
can recei4e their re*ard i% their lock makes it into the accepted ranch o% the lock
chain. Since the accepted ranch o% the lock chain can change3 it isn/t possile to kno*
immediately *hether a ne* lock *ill stay on the accepted ranch. This is *hy .itcoin
re;uires a 1CC lock maturation time e%ore coinase transactions can e spent. So unlike
normal transactions that take aout an hour to process3 coinase transactions take aout
1H hours.
The re*ard system is also the e2clusi4e *ay that ne* itcoins are released into
circulation. 1sing this mechanism to release ne* itcoins pro4ides a slo* and steady rate
o% production and distriutes them in proportion to in4estment in the system. 9% all
itcoins *ere created in one atch at the eginning3 then Satoshi <akamoto *ould ha4e
o*ned them all and he *ould proaly ha4e had a hard time selling them.
9nitially3 the re*ard *as &C itcoins per lock. .ut i% that continued %ore4er3 the
currency *ould perpetually e2perience in%lation due to an increasing money supply.
There%ore3 .itcoin hal4es the si0e o% the re*ard e4ery 61C3CCC locks3 *hich is
appro2imately e4ery # years since each lock takes an a4erage o% 1C minutes to mine 5#
years U 3F& daysIyear U 6# hoursIday U F locksIhour N 61C6#C8.= 6 1 > There%ore there are
61C3CCC payments at each re*ard le4el3 making a total o%
(%ter 61 million itcoins ha4e een produced3 production *ill stop and remain at this
le4el %ore4er. (t this point miners *ill still recei4e transaction fees on each transaction in
locks that they mine. Transaction %ees are an optional *ay %or a sender to increase the
speed at *hich their transaction *ill e processed y pro4iding an incenti4e %or miners to
include the transaction in their ne2t lock. When creating a transaction3 any e2cess o% the
4alue o% the inputs o4er the 4alue o% the outputs is considered a transaction %ee that goes
to *hiche4er miner processes the transaction. Currently3 the total 4alue o% transaction %ees
is much smaller than the 4alue o% the coinase transaction3 ut as the coinase
transaction/s 4alue diminishes3 transaction %ees *ill pro4ide an increasing portion o%
mining pro%its.
Mining Pools
Mining *orks like a lottery *here a unit o% computing po*er corresponds to a
lottery ticket. (s in the lottery3 *ith only one ticket 5one unit o% o% computing po*er3 say
a desktop PC doing 1C million hashes per second8 it re;uires a lot o% luck to get any
re*ard at all. .ut the more ticketsIcomputing po*er one has3 the etter the odds ecome.
To earn more steady re*ards3 miners sometimes %orm pools that collaorate on sol4ing
the proo% o% *ork prolem and share the re*ards.
Mining pools are coordinated y a central ser4er that assigns *ork to miners and
distriutes re*ards to all pool memers *hen any miner in the pool sol4es the proo% o%
*ork %or a ne* lock. The main challenge o% a pool ser4er is to %airly calculate the
percentage o% the re*ard to gi4e to each memer. 9n a %air pool3 memers that contriute
more computing po*er should get paid more3 so contriuted computing po*er is
measured and tracked y the ser4er. This tracking is accomplished y recording the
numer o% solutions miners %ind to an easier 4ersion o% the proo% o% *ork prolem? the
same prolem3 ut *ith a higher target 5lo*er di%%iculty8. This simpler prolem pro4es
that the miner *as *orking on the proo% o% *ork prolem. 'ach solution sumitted to the
ser4er %or this easier proo% o% *ork prolem earns the miner a share. The more computing
po*er a miner contriutes3 the more %re;uently they *ill %ind solutions and earn shares.
When a miner in the pool sol4es the real proo% o% *ork prolem3 the ser4er distriutes the
re*ard to all miners in proportion to ho* many shares they earned since the last re*ard
payout 5sometimes *ith a *eighting %actor3 see elo*8.
There are many di%%erent types o% pool ser4ers3 ut a simple one might *ork like this?
The pool ser4er prepares a lock *ith the coinase transaction pointing to the
pool/s address. Miners in the pool contact the pool ser4er and make a get*ork
re;uest to get the lock to *ork on.
'ach miner tries to sol4e the proo% o% *ork prolem %or the lock y incrementing
the nonce and hashing the lock header.
Whene4er a miner %inds a hash 4alue that is elo* the easier target3 it sumits the
solution to the ser4er %or a share.
The mining ser4er 4eri%ies sumitted shares and tracks ho* many each miner has.
When a miner %inds a solution to the proo% o% *ork prolem3 the ser4er pays out
the re*ard in proportion to the numer o% shares each miner earned since the last
payout.
Miners periodically contact the pool ser4er %or updates on *hat to *ork on in case
a ne* lock *as disco4ered.
9% a miner tries to cheat y sumitting shares *hile *orking on locks that pay to
their o*n address3 the pool ser4er *ill detect this and re:ect the shares. The ser4er only
accepts lock header solutions that correspond to the ones it issues. The only %ields that
miners can change are n<once and on some ser4ers nTime. 9% the miner changes the
destination o% the coinase transaction3 the hashMerkle,oot %ield *ill change and the
ser4er *ill kno* that the miner is cheating.
To pre4ent duplicate *ork3 a pool ser4er should ha4e a uni;ue response to e4ery
get*ork re;uest. )ther*ise multiple miners *ill e checking the same nonce 4alues
ecause each miner is :ust going to increment the nonce starting %rom 0ero. To ensure
uni;ueness3 the ser4er can t*eak the nTime %ield y a %e* seconds or reorder the
transactions3 *hich *ould change the hashMerkle,oot.
There are se4eral *ays to optimi0e the pool mining system ao4e. )ne ine%%iciency
arises %rom the %act that miners only re;uest ne* *ork %rom the ser4er periodically3 and a
ne* lock could e disco4ered *ithin that period. (ny *ork done %or a lock that *as
already disco4ered is a *aste. ( method kno*n as long polling optimi0es this y ha4ing
the ser4er contact the miners *hen a ne* lock is %ound. Eong polling can also reduce
net*ork tra%%ic ecause miners can continue *orking until the entire nonce search space
is co4ered *ithout contacting the ser4er.
Pools that pay in direct proportion to the numer o% shares sumitted3 as descried
ao4e3 ha4e
di%%erent pro%itaility %or miners at di%%erent times. The reason is that i% it takes a longer
time to %ind a solution3 more shares *ill e sumitted3 and the payout per share *ill e
lo*er. So it is more pro%itale %or a miner to spend more time mining in short rounds3
*here a round is the inter4al et*een payouts in a gi4en pool. This encourages pool
hopping3 *here miners hop %rom one pool to another to try to oost their pro%its. The
optimal strategy to e2ploit proportional$paying pools is to s*itch to another pool *hen
the numer o% shares in the round e2ceeds #3.&7 o% the current di%%iculty3 assuming each
share has di%%iculty o% 1.=6#> 9% a miner %ollo*s this strategy3 they *ill increase the
percentage o% their time that they are *orking in shorter rounds ecause they acti4ely
lea4e rounds *hen they start to ecome long. Since shorter rounds pay more per share3
this ma2imi0es the payout per share. Many pools no* ha4e ad:ustments that discourage
pool hopping y making later shares *orth more.
Mining *ardware
9nitially3 Satoshi/s .itcoin client did mining on a user/s PC3 ut no* CP1s ha4e een
eclipsed y more e%%icient mining hard*are. DP1s 5Draphics Processing 1nit $ Draphics
cards8 are designed %or doing lots o% simple calculations in parallel and are orders o%
magnitude %aster than CP1s. ,ecently3 (S9Cs 5(pplication$Speci%ic 9ntegrated Circuits8
ha4e een de4eloped that are orders o% magnitude %aster than DP1s. (t this point3 miners
need to ha4e custom hard*are to make mining a pro%itale in4estment.