 I'm Gilbert Gottfried and your friend sent you this video because you're investing in Bitcoin even though it's obvious you don't know what the f**k it even is. What is Bitcoin? You ask? A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to the other without going through a financial institution. Digital signatures provide part of the solution but the main benefits are lost if a trusted third party is still required to prevent double spending. We propose a solution to double spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof of work forming a record that cannot be changed without redoing the proof of work. The longest chain not only serves as proof of sequence of events witnessed but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis and nodes can leave and rejoin the network at will accepting the longest proof of work chain as proof of what happened while they were gone. See, was that so hard for you f***ing idiots? Alright, let's get into the white paper. Section 1 Introduction Commerce on the internet has come to a lie almost exclusively on financial institutions serving as trusted third parties to process electronic payments while the system works well enough for most transactions. It still suffers from the inherent weaknesses of the trust-based model. Completely non-reversible transactions are not really possible since financial institutions cannot avoid mediating disputes. The cost of the mediation increases transaction costs limiting the minimum practical transaction size and cutting off the possibility for small casual transactions and there is a broader cost in the loss of ability to make non-reversible payments for non-reversible services with the possibility of reversal and need for trust spreads. Merchants must be wary of their customers hassling them for more information than they would otherwise need. A certain percentage fraud is accepted as unavoidable. These cost and payment uncertainties can be avoided in person by using physical currency but no mechanism exists to make payments over a communications channel without a trusted party. What is needed is an electronic payment system based on cryptographic proof instead of trust allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud and routine escrow mechanisms could easily be implemented to protect buyers. In this paper we propose a solution to the double spending problem using peer-to-beer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. You understand this? Of course not because you're fucking idiots and you're not paying attention. When you're starving to death in the street I'm gonna be looking out my window laughing. Section 2 transactions. We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify signatures to verify the chain of ownership. The problem of course is the payee can verify that one of the owners did not double spend the coin. A common solution is to introduce a trusted central authority or mint that checks every transaction for double spending. Each transaction the coin must be returned to the mint to issue a new coin and the only coins issued directly from the mint are trusted not to be double spent. The problem with the solution is that the fate of the entire money system depends on the company running the mint with every transaction having to go through them just like a bank. We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes the earliest transactions is the one that counts so we don't care about attempts to double spend. The only way to confirm the absence of a transaction is to be aware of all transactions in the mint based model. The mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party transactions must be publicly announced and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that the time of each transaction the majority of nodes agreed it was the first received. Okay do you understand this? Please pay attention pay attention I'm here to help you. Section three time stamp server. The solution we propose begins with a time stamp server. A time stamp server works by taking a hash of a block of items to be time stamped and widely publishing the hash such as in a newspaper or Usenet post. The time stamp proves that the data must have existed at a time obviously in order to get into the hash. Each time stamp includes the previous time stamp in its hash proving a chain with each additional time stamp reinforcing the ones before it. Are you paying attention? Please I don't have all day. You know what a fucking time stamp is? Probably not. Section four proof of work. To implement a distributed time stamp server on a peer-to-peer basis we will need to use a proof of work system similar to Adam Bach's hash cash rather than newspaper or Usenet post. The proof of work involves scanning for a value that when hash such as with SHA 256 the hashtag begins with a number of zero bits. The average work required is an exponent. Screw it. In a number of zero bits required can be verified by executing a single hash. For our time stamp network we implement a proof of work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been extended to make it satisfy the proof of work the block cannot be changed without redoing the work. As later blocks are chained after it the work to change the block would include redoing all the blocks after it. The proof of work also solves the problem of determining, deader mining, it's something like that. Representation in the majority decision making the majority were based on IP address. One vote it could be subverted by anyone able to allocate IPS. Proof of work is essentially one CPU one vote. The majority decision is represented by the longest chain which has the greatest proof of work effort invested in it. In the majority of CPU power is controlled by honest nodes. The honest chain will grow the fastest and outpace any competing chains. To modify a pass block an attacker would have to redo the proof of work of the block and all the blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up on diminishes exponentially as subsequent blocks are added to compensate for increasing hardware speed and verifying interest in running nodes over time. The proof of work difficulty is determined by a moving average of targeting an average number of blocks per hour. If they generated too fast the difficulty increases. Hey dummies that was the bitcoin mining part. I hope you understood it because if you don't I want nothing to do with it. Section five network. The steps to run the network are as follows. One new transactions are broadcast to all nodes. Two each node collects new transactions into a block. Three each node works on finding a difficult proof of work for its block. Four when a node finds a proof of work it broadcasts the block to all nodes. Five nodes accept the block only if all transitions in it are valid and not already spent. Six nodes express their acceptance of the block by working on creating the next block in the chain using the hash of the accepted block as the previous hash. Nodes always consider the longest chain to be correct. One and will keep working on it extending it. If two nodes broadcast different versions of the next block simultaneously some nodes may receive one or the other first. In that case they work on the first one they receive but save the other branch in case it becomes longer. The tie will be broken when the next proof of work is found and one branch becomes longer and the nodes that were working on the other branch will then switch to the longer one. New transaction broadcasts do not necessarily need to reach all nodes as long as they may reach many nodes. They will get into a block before long. Block broadcasts are also tolerant of dropped messages. If a node does not receive a block it will request it when it receives the next block and realize it missed one. Get it? I stopped listening to this an hour ago. I hope you are. I know. I know. It's up to you to learn. Bunch of fucking idiots. Section six incentive. By convention the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for the nodes to support the network and provides a way to initially distribute coins into circulation since there is no central authority to issue them. The steady addition of a constant of amount of new coins acknowledges this. To gold miners I don't fucking know what that means or how to pronounce it but you should know it. Okay? Expending resources to add gold to circulation. In our case it is CPU time and electricity that is expanded. The incentive can also be funded with transaction fees if the output value of a transaction is less than its input value. The difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation the incentive can transition entirely to transition fees and be completely inflation free. The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes he would have to choose between using to defraud people by stealing back his payments or using to generate new coins. He ought to find it more profitable to play by the rules. Such rules that favor him with more new coins than everyone else combined than to undermine the system and the validity of his own wealth. Section 7 Reclaiming Disc Space Once the latest transaction in a coin is buried under enough blocks to spend transactions before it can be discarded to save disk space to suffocate. Ah fuck it I don't know it. You know what? Suck my cock. This is for you to learn. This, without breaking the blocks hash transactions, are hashed into a merkle tree with only the root included in the blocks hash. All blocks then can be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored. A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes times 6 times 24 times 365 equal 4.2 megabytes per year. With computer systems typically selling with 2 gigabytes of r of ram of, well I was spelling it because I don't know if you people understand. Ram is R-A-M. R-A-M. You have a crayon and a piece of paper. Write it down. Because I want to have taken that. As of 2008 and Moore's law predicting current growth of 1.2 gigabytes per year storage should not be a problem even if the block headers must be kept in memory. You get it? Pay attention. This is the bitcoin that's headed to the moon. You could be driving a Lambo. And now I know what your old saying right now. You're saying Lambo. Was he like the seventh Monks brother? There was Groucho, Chico, Harpo, Gumbo, Zeppo and Lambo. No, it's a car. Section 8, Simplified Payment Verification. It is possible to verify payments without running a full network node. A user needs to keep a copy of the block headers of the longest proof of work chain which he can get by querying network nodes until he's convinced he has the longest chain and obtained the Merkle branch linking the transaction to the block. It's time-stanted. He can check the transaction for himself but by linking to a place in the chain he can see that a network node has accepted it and blocks added after it. Further confirm the network has accepted it. As such, the verification as reliable as long as honest nodes control a network but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block prompting the user's software to download the full block and alerted transactions to confirm the inconsistency businesses that receive frequent payments will probably want to run their modes for more independent security and quicker verification. Get that? I mean anything? Do you want me to start from the beginning? I'll do it because I don't think you understand any of this. Section nine, combining and splitting value. Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally, there will either be a single input from a larger previous transaction on multiple inputs combining smaller amounts and at most two outputs, one for the payment and one returning the change. If any, back to the sender. It should be noted that fan out where a transaction depends on several transactions and those transactions depend on many more is not a problem here. There is never the need to extract a completely standalone copy of transactions history. Get that? A transcendalone? That's a flower, a transcendalone. Yeah, yeah. There are old kind. There are roses and there are transcendalones. Those are the most pretty. They are the most pretty colors. I get your girlfriend a bunch of transcendalones. Section 10, privacy. The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but the privacy can still be maintained by breaking the flow of information in another place by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking to the transaction to anyone. This is similar to the level of information released by stock exchanges where the time and size of individual trades, the tape is made public without telling who the parties were. An additional firewall, a new pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions which necessarily reveal that their inputs were owned by the same owner. The risk is that the owner of a key is revealed linking could reveal other transactions that belong to the same owner. It's very easy. Satoshi, explain this to me. See, we're on a first name basis. Me and Satoshi and sometimes I call him Toe. I say, hey, Toe. Toe, what about that transaction? You like that? And Toe says, yeah, it's okay. That's how he talks. Surprisingly, he goes, it's okay with me. I don't care. And I say, that's why I like you, Toe. Section 11 calculations. We consider the scenario of an attacker trying to generate an alternate chain faster than the honest claim. Even if this is accomplished, it does not throw the system open to arbitrary changes such as creating value out of thin air or taking money that never belong to the attacker. Nodes are not going to accept an invalid transaction such as payment and honest nodes will never accept a block containing them. An attacker can try to change one of his own transactions to take the money back he recently spent. The race between the honest chain and the attacker chain can be characterized as a binomial random walk. The success event is the honest chain being extended by the one block, increasing its lead by plus one and the failure event to the attacker's chain being extended by one block, reducing the gap by minus one. The probability of an attacker catching up from a given deficit is an analogous to gambler's ruin problem. Suppose a gambler with an unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven or that an attacker catches up with the honest chain as follows. Now watch when I clap my hands the chart is going to go from that shoulder to that one. Watch this, see? Given our assumption that p is greater than q the probability drops exponentially as the number of blocks that the attacker has to catch up with increases. With the odds against him it doesn't make a lucky lunge. Forward early on his chances become vanishingly small as he falls further behind. We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid for a while and then switch it back to himself after some time has passed. The receiver will be alerted when that happens but the sender hopes it will be too late. The receiver generates a new pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead then executing the transactions by that moment. Once the transaction is sent the dishonest sender starts in on a secret on a parallel chain containing an alternative version of the transaction. The recipient waits until a transaction has been added and to a block and Z blocks have been linked after it. He doesn't know the exact amount of the progress the attacker has been made but assuming the honest blocks took the average blocks time per block the attacker's potential progress will be poisoned. Distributor with expected value. Where did it go? Oh there it's back there. To get probability of the attacker could still catch up now we multiply the poison density for each amount of progress he could have made by the probability he could catch up from that point. Rearranging to avoid summoning the infinite tail of the distribution converting to C code. Running some results we can see that the probability drop exponentially to Z solving for P less than 0.1 percent. Now that uh that was uh I said before P less and if you have problems P less you should go to a urologist if you P less. You know Toshi said that uh that uh you know all this bitcoin it's all well and good but I couldn't P less and I said you should drink more water to see and uh sometimes he'd pull his socks off and go toes see he thought it was funny. Our graphics department worked over time for that one. Section 12 conclusion we have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures which provide strong control of ownership but is incomplete without a way to prevent double spending. To solve this we proposed a peer-to-peer network using proof of work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will accepting the proof of work chain as proof of what happens while they work on. They vote with your CPU power expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism. See was that so hard for you you fucking idiots? If any of this was lost on you and you are even thinking about trading crypto check out CoinTelegraph Markets Pro. They have analysis on every coin. They have crypto news. The second it happens they even have an academy to teach fucking nitwits like you how to trade. Go to cointelegraph.com for more info and get smart about crypto.