Bitcoin

Satoshi Nakamoto A Peer-to-Peer Electronic Cash System [email protected]  Www.bitcoin.org Version 1.0 • 2020.11.03 Designed and published by [email protected]. My design of this document is not copyrighted. I have placed it in the public domain. I encourage you to freely distribute and print it. www.KlausNordby.com/bitcoin

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Table of Contents Page 2 of 24 Table of Contents Designing Remarks . . . . . . . . . . . . . 3 Reclaiming Disk Space . . . . . . . . . . .13 Abstract . . . . . . . . . . . . . . . . . . . 4 Simplified Payment Verification . . . . 15 Introduction . . . . . . . . . . . . . . . . 5 Combining and Splitting Value . . . . 17 Transactions . . . . . . . . . . . . . . . . 6 Privacy . . . . . . . . . . . . . . . . . . . . .18 Timestamp Server . . . . . . . . . . . . . . 8 Calculations . . . . . . . . . . . . . . . . 19 Proof-of-Work . . . . . . . . . . . . . . . 9 Conclusion . . . . . . . . . . . . . . . . . 22 Network . . . . . . . . . . . . . . . . . . . 11 References . . . . . . . . . . . . . . . . . . 23 Incentive . . . . . . . . . . . . . . . . . . .12

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Designing Remarks Page 3 of 24 Designing Remarks IN LATE OCTOBER 2020, MY GOOD FRIEND TOMER STROLIGHT This URL will be my Bitcoin documents’ permanent location — that suggested I create a custom-designed version of the foundational is where new versions will be found if typos are fixed or other changes Bitcoin whitepaper, written in 2008 by Satoshi Nakamoto — who are implemented: clearly is as brilliant as he is mysterious. www.KlausNordby.com/bitcoin And so I did. However, I have not changed anything of the text or graphics, but My design of this document is not copyrighted — I have released it have only sought to make it reader-friendly to human eyes and minds to the public domain. I encourage you to freely distribute and print it. — which Nakamoto’s original PDF document is not. Since most people nowadays will read this on their computer, the If you find any errors, please let me know and I will soon fix them. requirements of screen reading have been given first priority in my If you appreciate my design work, I will gratefully accept your con- design. But you may also print it out, in color or black-and-white. tribution to this address (copy-paste it — or scan the QR Code): I have also designed a one-page poster version of this White- paper, which you may download and print in any size you like bc1q7zjywmvn36d5acmm5tgzz7smceqp8dz9dvjy90 (though I used the 24\"×30\" size as my design surface). Klaus Nordby [email protected] Kalista, 2020.10.31

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Abstract Page 4 of 24 Abstract APURELY PEER-TO-PEER VERSION OF timestamps transactions by hashing them the longest chain and outpace attackers. The electronic cash would allow online pay- into an ongoing chain of hash-based proof- network itself requires minimal structure. ments to be sent directly from one party to of-work, forming a record that cannot be Messages are broadcast on a best effort basis, another without going through a financial changed without redoing the proof-of-work. and nodes can leave and rejoin the network institution. Digital signatures provide part The longest chain not only serves as proof of at will, accepting the longest proof-of-work of the solution, but the main benefits are the sequence of events witnessed, but proof chain as proof of what happened while they lost if a trusted third party is still required that it came from the largest pool of CPU were gone. to prevent double-spending. We propose power. As long as a majority of CPU power a solution to the double-spending problem is controlled by nodes that are not cooper- using a peer-to-peer network. The network ating to attack the network, they’ll generate

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Introduction Page 5 of 24 1Introduction COMMERCE ON THE INTERNET HAS for non-reversible services. With the possi- without the need for a trusted third party. come to rely almost exclusively on finan- bility of reversal, the need for trust spreads. Transactions that are computationally cial institutions serving as trusted third par- Merchants must be wary of their customers, impractical to reverse would protect sellers ties to process electronic payments. While hassling them for more information than from fraud, and routine escrow mechanisms the system works well enough for most trans- they would otherwise need. A certain per- could easily be implemented to protect buy- actions, it still suffers from the inherent weak- centage of fraud is accepted as unavoidable. ers. In this paper, we propose a solution to nesses of the trust based model. Completely These costs and payment uncertainties can the double-spending problem using a peer- non-reversible transactions are not really be avoided in person by using physical cur- to-peer distributed timestamp server to gen- possible, since financial institutions cannot rency, but no mechanism exists to make pay- erate computational proof of the chrono- avoid mediating disputes. The cost of medi- ments over a communications channel with- logical order of transactions. The system is ation increases transaction costs, limiting the out a trusted party. secure as long as honest nodes collectively minimum practical transaction size and cut- control more CPU power than any cooperat- ting off the possibility for small casual trans- What is needed is an electronic pay- ing group of attacker nodes. actions, and there is a broader cost in the loss ment system based on cryptographic proof of ability to make non-reversible payments instead of trust, allowing any two willing parties to transact directly with each other

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Transactions Page 6 of 24 2Transactions WE DEFINE AN ELECTRONIC COIN AS Transaction Transaction Transaction a chain of digital signatures. Each Owner 1’s Owner 2’s Owner 3’s owner transfers the coin to the next by dig- Public Key Public Key Public Key itally signing a hash of the previous transac- tion and the public key of the next owner and Hash Verify Hash Verify Hash adding these to the end of the coin. A payee Owner 0’s Owner 1’s Owner 2’s can verify the signatures to verify the chain of Signature Signature Signature ownership. Sign Sign Owner 1’s Owner 2’s Owner 3’s Private Key Private Key Private Key

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Transactions Page 7 of 24 The problem of course is the payee depends on the company running the mint, the mint was aware of all transactions and can’t verify that one of the owners did not with every transaction having to go through decided which arrived first. To accomplish double-spend the coin. A common solution them, just like a bank. this without a trusted party, transactions is to introduce a trusted central authority, or must be publicly announced [1], and we mint, that checks every transaction for dou- We need a way for the payee to know need a system for participants to agree on ble spending. After each transaction, the that the previous owners did not sign any a single history of the order in which they coin must be returned to the mint to issue earlier transactions. For our purposes, the were received. The payee needs proof that at a new coin, and only coins issued directly earliest transaction is the one that counts, the time of each transaction, the majority of from the mint are trusted not to be dou- so we don’t care about later attempts to nodes agreed it was the first received. ble-spent. The problem with this solution double-spend. The only way to confirm the is that the fate of the entire money system absence of a transaction is to be aware of all transactions. In the mint based model,

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Timestamp Server Page 8 of 24 3Timestamp Server ... THE SOLUTION WE PROPOSE BEGINS Hash Hash with a timestamp server. A timestamp server works by taking a hash of a block of Block ... Item Block items to be timestamped and widely pub- Item Item Item lishing the hash, such as in a newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the time, obvi- ously, in order to get into the hash. Each time- stamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Proof-of-Work Page 9 of 24 4Proof-of-Work TO IMPLEMENT A DISTRIBUTED TIME- Block Nonce Block Nonce stamp server on a peer-to-peer basis, we Previous Hash ... Previous Hash ... will need to use a proof-of-work system sim- ilar to Adam Back’s Hashcash [6], rather than Tx Tx Tx Tx newspaper or Usenet posts. The proof-of- work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The aver- age work required is exponential in the num- ber of zero bits required and can be verified by executing a single hash.

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Proof-of-Work Page 10 of 24 For our timestamp network, we imple- based on one-IP-address-one-vote, it could show later that the probability of a slower ment the proof-of-work by incrementing be subverted by anyone able to allocate attacker catching up diminishes exponen- a nonce in the block until a value is found many IPs. Proof-of-work is essentially one- tially as subsequent blocks are added. that gives the block’s hash the required zero CPU-one-vote. The majority decision is rep- bits. Once the CPU effort has been expended resented by the longest chain, which has the To compensate for increasing hardware to make it satisfy the proof-of-work, the block greatest proof-of-work effort invested in it. If speed and varying interest in running nodes cannot be changed without redoing the work. a majority of CPU power is controlled by hon- over time, the proof-of-work difficulty is As later blocks are chained after it, the work est nodes, the honest chain will grow the fast- determined by a moving average target- to change the block would include redoing est and outpace any competing chains. To ing an average number of blocks per hour. all the blocks after it. modify a past block, an attacker would have If they’re generated too fast, the difficulty to redo the proof-of-work of the block and increases. The proof-of-work also solves the prob- all blocks after it and then catch up with and lem of determining representation in major- surpass the work of the honest nodes. We will ity decision making. If the majority were

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Network Page 11 of 24 5Network THE STEPS TO RUN THE NETWORK ARE 6. Nodes express their acceptance of the ken when the next proof- of-work is found as follows: block by working on creating the next and one branch becomes longer; the nodes block in the chain, using the hash of the that were working on the other branch will 1. New transactions are broadcast to all accepted block as the previous hash. then switch to the longer one. nodes. Nodes always consider the longest chain New transaction broadcasts do not nec- 2. Each node collects new transactions into to be the correct one and will keep working essarily need to reach all nodes. As long as a block. on extending it. If two nodes broadcast dif- they reach many nodes, they will get into ferent versions of the next block simultane- a block before long. Block broadcasts are 3. Each node works on finding a difficult ously, some nodes may receive one or the also tolerant of dropped messages. If a node proof-of-work for its block. other first. In that case, they work on the first does not receive a block, it will request it one they received, but save the other branch when it receives the next block and realizes 4. When a node finds a proof-of-work, it in case it becomes longer. The tie will be bro- it missed one. broadcasts the block to all nodes. 5. Nodes accept the block only if all transac- tions in it are valid and not already spent.

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Incentive Page 12 of 24 6Incentive BY CONVENTION, THE FIRST TRANS-­ The incentive can also be funded with est nodes, he would have to choose between action in a block is a special transaction transaction fees. If the output value of a trans- using it to defraud people by stealing back that starts a new coin owned by the creator action is less than its input value, the differ- his payments, or using it to generate new of the block. This adds an incentive for nodes ence is a transaction fee that is added to the coins. He ought to find it more profitable to to support the network, and provides a way incentive value of the block containing the play by the rules, such rules that favour him to initially distribute coins into circulation, transaction. Once a predetermined number with more new coins than everyone else since there is no central authority to issue of coins have entered circulation, the incen- combined, than to undermine the system them. The steady addition of a constant of tive can transition entirely to transaction fees and the validity of his own wealth. amount of new coins is analogous to gold and be completely inflation free. miners expending resources to add gold to circulation. In our case, it is CPU time and The incentive may help encourage nodes electricity that is expended. to stay honest. If a greedy attacker is able to assemble more CPU power than all the hon-

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Reclaiming Disk Space Page 13 of 24 7Reclaiming Disk Space ONCE THE LATEST TRANSACTION IN Block Block a coin is buried under enough blocks, the spent transactions before it can be dis- Block Header (Block Hash) Block Header (Block Hash) carded to save disk space. To facilitate this without breaking the block’s hash, transac- Previous Hash Nonce Previous Hash Nonce tions are hashed in a Merkle Tree [7][2][5], with only the root included in the block’s hash. Root Hash Root Hash Old blocks can then be compacted by stub- bing off branches of the tree. The interior Hash01 Hash23 Hash01 Hash23 hashes do not need to be stored. Hash0 Hash1 Hash2 Hash3 Hash2 Hash3 Tx0 Tx1 Tx2 Tx3 Tx3 Transactions Hashed in a Merkle Tree After Pruning Tx0-2 from the Block

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Reclaiming Disk Space Page 14 of 24 A block header with no transactions of RAM as of 2008, and Moore’s Law predict- would be about 80 bytes. If we suppose ing current growth of 1.2GB per year, storage blocks are generated every 10 minutes, 80 should not be a problem even if the block bytes × 6 × 24 × 365 = 4.2MB per year. With headers must be kept in memory. computer systems typically selling with 2GB

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Simplified Payment Verification Page 15 of 24 8Simplified Payment Verification Block Header Nonce Block Header Nonce Block Header Nonce Previous Hash Previous Hash Previous Hash Merkle Root Merkle Root Merkle Root Hash01 Hash23 IT IS POSSIBLE TO VERIFY PAYMENTS can’t check the transaction for himself, but without running a full network node. A user by linking it to a place in the chain, he can Hash2 Hash3 only needs to keep a copy of the block head- see that a network node has accepted it, and ers of the longest proof-of-work chain, which blocks added after it further confirm the net- Merkle Branch for Tx3 Tx3 he can get by querying network nodes until work has accepted it. he’s convinced he has the longest chain, and obtain the Merkle branch linking the trans- As such, the verification is reliable as long action to the block it’s timestamped in. He as honest nodes control the network, but is more vulnerable if the network is overpow-

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Simplified Payment Verification Page 16 of 24 ered by an attacker. While network nodes can prompting the user’s software to download verify transactions for themselves, the sim- the full block and alerted transactions to plified method can be fooled by an attack- confirm the inconsistency. Businesses that er’s fabricated transactions for as long as receive frequent payments will probably still the attacker can continue to overpower the want to run their own nodes for more inde- network. One strategy to protect against pendent security and quicker verification. this would be to accept alerts from network nodes when they detect an invalid block,

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Combining and Splitting Value Page 17 of 24 9Combining and Splitting Value ALTHOUGH IT WOULD BE POSSIBLE TO It should be noted that fan-out, where Transaction handle coins individually, it would be a transaction depends on several transac- In Out unwieldy to make a separate transaction for tions, and those transactions depend on In . . . every cent in a transfer. To allow value to be many more, is not a problem here. There is ... ... split and combined, transactions contain never the need to extract a complete stand- multiple inputs and outputs. Normally there alone copy of a transaction’s history. will be either a single input from a larger pre- vious transaction or multiple inputs combin- ing smaller amounts, and at most two out- puts: one for the payment, and one returning the change, if any, back to the sender.

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Privacy Page 18 of 24 10Privacy THE TRADITIONAL BANKING MODEL one is sending an amount to someone else, them from being linked to a common owner. achieves a level of privacy by limiting but without information linking the trans- Some linking is still unavoidable with multi- access to information to the parties involved action to anyone. This is similar to the level input transactions, which necessarily reveal and the trusted third party. The necessity of information released by stock exchanges, that their inputs were owned by the same to announce all transactions publicly pre- where the time and size of individual trades, owner. The risk is that if the owner of a key is cludes this method, but privacy can still be the “tape”, is made public, but without tell- revealed, linking could reveal other transac- maintained by breaking the flow of informa- ing who the parties were. tions that belonged to the same owner. tion in another place: by keeping public keys anonymous. The public can see that some- As an additional firewall, a new key pair should be used for each transaction to keep Traditional Privacy Model Identities Transactions Trusted Third Party Counterparty Public New Privacy Model Transactions Public Identities

as creating value out of thin air or taking m Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Calculationnsot going to accept an invaPlaigde 1t9roafn24saction a containing them. An attacker can only try Calcu1l1ationsmoney he recently spent. The race between the honest chain and Random Walk. The success event is the ho lead by +1, and the failure event is the attac gap by -1. The probability of an attacker catching WE CONSIDER THE SCENARIO OF AN Ruin problem. Suppose a gambler with un attacker trying to generate an alter- honest chain being extended by one block, infinp i=tepfirnondbusatmbhielbitnyeearxntohbfolonctekrsitanlosdeto nate chain faster than the honest chain. Even increasing its lead by +1, and the failure try to reach b if this is accomplished, it does not throw the system open to arbitrary changes, such as event is the attacker’s chain being extended reaches breakeven, or that an attacker ever creating value out of thin air or taking money by one block, reducing the gap by -1. that never belonged to the attacker. Nodes q = probability the attacker are not going to accept an invalid transac- The probability of an attacker catching up tion as payment, and honest nodes will never from a given deficit is analogous to a Gam- finds the next block accept a block containing them. An attacker bler’s Ruin problem. Suppose a gambler qpqz ===wpppirlrrol ooebvabbebaarilbbcitaiiytllctiihhttyyeuaptathtfnraeochmkaeotrtnaecsktenrofdinedfsintdhse the can only try to change one of his own trans- ne actions to take back money he recently spent. with unlimited credit starts at a deficit and qz =z bplroockbsabbehiliintdy the attacker will ever ca The race between the honest chain and an attacker chain can be characterized as a Bino- plays potentially an infinite number of trials mial Random Walk. The success event is the to try to reach breakeven. We can calculate { }qz= the probability he ever reaches breakeven, 1 if p≤q or that an attacker ever catches up with the q/ pz if pq honest chain, as follows [8]:

it continuously until he is lucky enough to ge that momentht.atOmnocme ethnet. trOannscaecttihoen tirsansseanctt, Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Calculaptioanrsallel chapinarcaolnletlaicnhianign acnonPaatlgateei2nr0nionafgt2e4avnearsltieornn Given our assumption that p > q, the when that happens, but the sender phaoipr easnditalisnskuetmTehmxadheadcieaentav,agrebfmertuaectotghrialuaepiesnsnsiietsutekxhu.omTnpefometidhpnnciHegrwtenoeatsgedgarhftreetietetcdtisbhsmhrsioolpeeotunehiicentspeeh.sknenttaoirs'tbtltntblHaowttelkcoochskekcnaoeteskiokr,ttdbtowshtroholataoeuhksenctneshskntaeisa'lctvttetiekohoxrnoenaaokgc probability drops exponentially as the num- will be too late. ber of blocks the attacker has to catch up The receiver generates a new key with increases. With the odds against him, if gives the public key to the sender shortlyprogatrteacskserw’s piploltreobngetiraael psPrsoogwirseisslsolwnbiledl biaestaPrPioobiiusssstoiononndwisittrhibeu he doesn’t make a lucky lunge forward early before signing. This prevents the sender from distribution with expected value: on, his chances become vanishingly small as preparing a chain of blocks ahead of time by =z q =z q he falls further behind. working on it continuously until he is lucky p p enough to get far enough ahead, then execut- We now consider how long the recip- ing the transaction at that moment. Once the To get the probability the attacker could still ient of a new transaction needs to wait before being sufficiently certain the sender transaction is sent, the dishonest sender starts scgiatetycthfothurpeanpcTohrwooa, bmwgaeoebutminltutihltoteyifplppytrhrotohegebraeaPstobstiaishlsceioktncyeodrutehlcnde-oualtdtasctkile can’t change the transaction. We assume the sender is an attacker who wants to make the working in secret on a parallel chain containT- o recipient believe he paid him for a while, then ing an alternate version of his transaction. eachhaavemmoaudneetbayoctfhhepaprmorogborauebnsilitstyohhfeepccoroouulgdlrdceasthcsahvhee cmoaudlde The recipient waits until the transaction up from that point: switch it to pay back to himself after some has been added to a block and z blocks have ∑ {∑ { }∞kke!−⋅k∞/p1kke!z−−⋅k qif/ kp≤ z−zk if k time has passed. The receiver will be alerted been linked after it. He doesn’t know the if k1 z if k k =0 q =0 RearrangingRteoararvaonigdinsgumtomaivnogidthseuimnfmininitge ttha kke!−1−1k=z−0 qkk/e!p− z−1k− q / ∑ ∑  z p z−k 1− k =0 Converting CtoonCvceortdine.g..to C code...

∞ q / p z−k  if k ≤ z 1 ∑ { ke! ⋅Ska=to0shi Nakamoto }if k  zBitcoin • A Peer-to-Peer Electronic Cash System • Calculations Page 21 of 24 RearRtareailanorrfgatnihngeigndgitsottroibaauvvtoiooiindd.s.us.ummmimnginthge tinhfeiniitnefinite tail of the Running some results, we z=30 P=0.0001522 z=35 P=0.0000379 distribuctaionnse.e..the probability drop z=40 P=0.0000095 z=45 P=0.0000024 off exponentially with z. z=50 P=0.0000006 zk e− Solving for P less than 0.1% . . . k! ∑  1− P < 0.001 k =0 q=0.10 z=5 1−q / p z−k q=0.1 P=1.0000000 q=0.15 z=8 z=0 P=0.2045873 q=0.20 z=11 z=1 q=0.25 z=15 q=0.30 z=24 ConCvoenrvteinrtgingtotoCC ccooded.e..... z=2 P=0.0509779 q=0.35 z=41 z=3 P=0.0131722 q=0.40 z=89 q=0.45 z=340 #include <math.h> z=4 P=0.0034552 #idnoucblluedAett<amckaetrhS.uchc>essProbability(double q, int z) z=5 P=0.0009137 do{uble AttackerSuccessProbability(double q, int zz)=6 P=0.0002428 { double p = 1.0 - q; z=7 P=0.0000647 ddoouubblle elapmbd=a 1=.z0 *-(qq;/ p); z=8 P=0.0000173 ddoouubblle esulma=mb1d.0a; = z * (q / p); z=9 P=0.0000046 dinotubil, ek;sum = 1.0; z=10 P=0.0000012 ifonrt (ik ,= k0;; k <= z; k++) f{or (k = 0; k <= z; k++) q=0.3 { double poisson = exp(-lambda); z=0 P=1.0000000 fodro(uibl=e1;poii<s=sokn; i=++e) xp(-lambda); z=5 P=0.1773523 foprois(sion=*=1;lamibd<a=/ ki;; i++) z=10 P=0.0416605 sum -= ppooiissssoonn* *(=1 -lapmowb(dqa/ /p,iz; - k)); z=15 P=0.0101008 } sum -= poisson * (1 - pow(q / p, z - k));z=20 P=0.0024804 }return sum; z=25 P=0.0006132 } return sum; }

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • Conclusion Page 22 of 24 12Conclusion WE HAVE PROPOSED A SYSTEM FOR cal for an attacker to change if honest nodes were gone. They vote with their CPU power, electronic transactions without rely- control a majority of CPU power. The net- expressing their acceptance of valid blocks ing on trust. We started with the usual frame- work is robust in its unstructured simplicity. by working on extending them and reject- work of coins made from digital signatures, Nodes work all at once with little coordina- ing invalid blocks by refusing to work on which provides strong control of ownership, tion. They do not need to be identified, since them. Any needed rules and incentives can but is incomplete without a way to prevent messages are not routed to any particular be enforced with this consensus mechanism. double-spending. To solve this, we proposed place and only need to be delivered on a best a peer-to-peer network using proof-of-work effort basis. Nodes can leave and rejoin the to record a public history of transactions that network at will, accepting the proof-of-work quickly becomes computationally impracti- chain as proof of what happened while they

Satoshi Nakamoto Bitcoin • A Peer-to-Peer Electronic Cash System • References Page 23 of 24 References [1] W. Dai, “b-money,” http://www. [4] D. Bayer, S. Haber, W.S. Stornetta, [6] A. Back, “Hashcash — a denial of weidai.com/bmoney.txt, 1998. “Improving the efficiency and service counter-measure,” http:// reliability of digital time-stamping,” www.hashcash.org/papers/ [2] H. Massias, X.S. Avila, and J.-J. In Sequences II: Methods in hashcash.pdf, 2002. Quisquater, “Design of a secure Communication, Security and Computer timestamping service with minimal Science, pages 329-334, 1993. [7] R.C. Merkle, “Protocols for public trust requirements,” In 20th key cryptosystems,” In Proc. 1980 Symposium on Information Theory [5] S. Haber, W.S. Stornetta, “Secure Symposium on Security and in the Benelux, May 1999. names for bit-strings,” In Proceedings Privacy, IEEE Computer Society, of the 4th ACM Conference on pages 122-133, April 1980. [3] S. Haber, W.S. Stornetta, “How to Computer and Communications time-stamp a digital document,” Security, pages 28-35, April 1997. [8] W. Feller, “An introduction In Journal of Cryptology, vol to probability theory and 3, no 2, pages 99-111, 1991. its applications,” 1957.