Mybitcoins gadget bitstamp api

If people trust that I'll keep my promise and consider my signature unforgeable, they can pass around these pieces of paper just like banknotes. In fact, banknotes themselves got their start as promissory notes issued by commercial banks. It's only in fairly recent history that governments stepped in to centralize the money supply and legally require banks to redeem notes.

I can do the same thing electronically with digital signatures, but that runs into the annoying "double spending" problem — if you receive a piece of data representing a unit of virtual cash, you can make two or more copies of it and pass it on to different people. To stick with our analogy, let's stretch it a little bit and assume that people can make perfect copies and we have no way to tell copies from the original. Can we solve double spending in this world?

Here's a possible solution: I put unique serial numbers into each note I give out. When you receive such a note from someone, you check my signature, but you also call me on the phone to ask if a note with that serial number has already been spent.

Hopefully I'll say no, in which case you accept the note. I'll record the serial number as spent in my ledger, and if you try to spend that note, it won't work because the recipient will call me and I'll tell them the note has already been spent. What you'll need to do instead is to periodically bring me all the notes you've received, and I'll issue you the same number of new notes with fresh serial numbers.

This works. It's cumbersome in real life, but straightforward digitally provided I've set up a server to do the signing and record-keeping of serial numbers. The only problem is that this isn't really cash any more, because it's not anonymous — when I issue a note to you I can record the serial number along with your identity, and I can do the same when someone else later redeems it.

That means I can keep track of all the places where you're spending your money. This is where Chaum's innovation comes in. He figured out to both keep the system anonymous and prevent double-spending by inventing the digital equivalent of the following procedure: when I issue a new note to you, you pick the serial number. You write it down on the piece of paper, but cover it so that I can't see it. Then I'll sign it, still unable to see the serial number. This is called a "blind signature" in cryptography.

It'll be in your interest to pick a long, random serial number to ensure that it will most likely be unique. I don't have to worry that you'll pick a serial number that's already been picked — you can only shoot yourself in the foot by doing so and end up with a note that can't be spent. It works, but it still requires a server run by a central authority, such as a bank, and for everyone to trust that entity.

Moreover, every transaction needs the participation of this server to go through. If the server goes down temporarily, payments grind to a halt. A few years later, in , Chaum in collaboration with two other cryptographers Fiat and Naor proposed offline electronic cash. At first sight this might seem to be impossible: if you try to spend the same digital note or coin at two different shops, how can they possibly stop this unless they're both connected to the same payment network or central entity?

The clever idea is to stop worrying about preventing double-spending and focus on detecting it, after the fact, when the merchant re-connects to the bank server. After all, this is why you're able to use your credit card on an airplane even if there is no network connection up in the skies. The transaction processing happens later when the airline is able to re-connect to the network. If your card is denied, you'll owe the airline or your bank money.

If you think about it, quite a bit of traditional finance is based on the idea of detecting an error or loss, followed by attempting to recover the money or punish the perpetrator. If you write someone a personal check, they have no guarantee that the money is actually in your account, but they can come after you if the check bounces. Conceivably, if an offline electronic cash system were widely adopted, the legal system would come to recognize double spending as a crime.

Chaum, Fiat, and Naor's idea for detecting double spending was an intricate cryptographic dance. At a high level, what it achieved was this: every digital coin issued to you encodes your identity, but in such a way that no one except you, not even the bank, can decode it. Every time you spend your coin, the recipient will require you to decode a random subset of the encoding, and they'll keep a record of this. This decoding isn't enough to allow them to determine your identity.

But if you ever double spend a coin, eventually both recipients will go to the bank to redeem their notes, and when they do this, the bank can put the two pieces of information together to decode your identity completely, with an overwhelmingly high probability. You might wonder if someone can frame you as a double spender in this system. Say you spend a coin with me, and then I turned around and tried to double-spend it without redeeming it with the bank and getting a new coin with my identity encoded.

This won't work — the new recipient will ask me to decode a random subset, and this will almost certainly not be the same as the subset you decoded for me, so I won't be able to comply with their decoding request. Over the years, many cryptographers have looked at this construction and improved it in various ways. But a paper by Okamoto and Ohta uses "Merkle trees" to create a system that does allow you to subdivide your coins.

Merkle trees would show up in Bitcoin as well, and we'll meet them in Chapter 1. The Chaum-Fiat-Naor scheme also leaves a lot of room for improvements in efficiency. In particular, the application of something called zero-knowledge proofs to this scheme most notably by Brands; and Camenisch, Flohenberger, 9 and Lysyanskaya was very fruitful—zero-knowledge proofs have also been applied to Bitcoin as we will see in Chapter 6.

But back to Chaum: he took his ideas and commercialized them. He formed a company in called DigiCash, probably the earliest company that tried to solve the problem of online payments. They had about a five-year head start on other companies like FirstVirtual and CyberCash that we just discussed. The actual cash in Digicash's system was called Ecash and they had another system called cyberbucks.

There were banks that actually implemented it — a few in the US and at least one in Finland. This was in the s, long before Bitcoin, which might come as surprise to some Bitcoin enthusiasts who view banks as tech-phobic, anti-innovative behemoths. Ecash is based on Chaum's protocols. Clients are anonymous, so banks can't trace how they're spending their money.

But merchants in ecash aren't anonymous. They have to return coins as soon as they receive them, so the bank knows how much they're making, at what times, and so on. As you can see, it shows you your balance as well as all the coins that you have that have been issued to you from the bank.

Since there's no way to split your coins, the bank issues you a whole set of coins in denominations of a cent, two cents, four cents, 10 and so on — powers of two. That way, you or your software, on your behalf can always select a set of coins to pay for the exact amount of a transaction. When you want to make a transaction, say, as in this example, you want to make a donation to the non-profit privacy group EPIC, you'd click on a donation link that takes you to the Digicash website.

That would then open a reverse web connection back to your computer. That means your computer had to have the ability to accept incoming connections and act as a server. If the connection was successful, then the ecash software would launch on your computer and you'd be able to approve the transaction and send the money. Chaum had several patents on Digicash technology, in particular, the blind-signature scheme that it used.

This was controversial, and it stopped other people from developing ecash systems that used the same protocol. But a bunch of cryptographers who hung out on what was called the cypherpunks mailing list wanted an alternative. Cyperpunks was the predecessor to the mailing list where Satoshi Nakamoto would later announce Bitcoin to the world, and this is no coincidence.

We'll talk about the cypherpunk movement and the roots of Bitcoin in Chapter 7. The cypherpunk cryptographers implemented a version of of ecash called MagicMoney. It did violate the patents, but was billed as being only for experimental use. It was a fun piece of software to play with.

The interface was all text-based. You could send transactions by email. You would just copy and paste the transactions into your email and send it to another user. Hopefully, you'd use end-to-end email encryption software such as PGP to protect the transaction in transit. Then there's a proposal called Lucre by Ben Laurie with contributions from many other people.

Lucre tries to replace the blind-signature scheme in ecash with a non-patent-encumbered alternative, with the rest of the system largely the same. Yet another proposal, by Ian Goldberg, tries to fix the problem of not being able to split your coins to make change.

His idea was that the merchant could send you coins back if they had some coins, so that you might overpay for the item if you didn't have exact change, and then you'd get some coins back. But notice that this introduces an anonymity problem. As we saw earlier, in ecash, senders are anonymous but merchants aren't. When the merchant sends cash back, technically, they're the sender, so they're anonymous.

But you, as someone who has to return this cash to the bank, aren't anonymous. There's no way to design this system without breaking the anonymity of users trying to buy goods. So Goldberg came up with a proposal where there were different types of coins that would allow these transactions to occur, allow you to get change back, and still preserve your anonymity. Now, why did DigiCash fail? The main problem with DigiCash was that it was hard to persuade the banks and the merchants to adopt it.

Since there weren't many merchants that accepted ecash, users didn't want it either. Worse, it didn't support user-to-user transactions, or at least not very well. It was really centered on the user-to-merchant transaction. So if merchants weren't on board, there was 11 no other way to bootstrap interest in the system.

So at the end of the day, DigiCash lost and the credit card companies won. As a side note, Bitcoin allows user-to-merchant and user-to-user transactions. In fact, the protocol doesn't have a notion of merchant that's separate from the notion of user. The support for user-to-user transactions probably contributed to Bitcoin's success.

There was something to do with your bitcoins right from the beginning: send it to other users, while the community tried to drum up support for Bitcoin and get merchants to accept it. In the later years of the company, DigiCash also experimented with tamper-resistant hardware to try to prevent double-spending rather than just detecting it. In this system, you'd get a small hardware device that was usually called a wallet, or some sort of card.

The device would keep track of your balance, which would decrease when you spent money and increase if you loaded the card with more money. The point of the device is that there should be no way to physically or digitally go in and tamper with its counter. So if the counter hits zero, then the card stops being able to spend money until it's re-loaded.

There were many other companies that had electronic cash systems based on tamper-resistant hardware. Another company formed around this idea was called Mondex and it was later acquired by Mastercard. Visa also had their own variant called VisaCash. Figure 3: Mondex system, showing user card and wallet. There's a smart card and there's a wallet unit, and you can load either of them with cash.

And if you wanted to do user-to-user swap of money, the giver user would first put their card into the wallet and move money off of the card onto the wallet. Then the receiver would stick their card in the wallet then you'd move the money onto the second card. This was a way to exchange digital cash, and it was anonymous. Mondex trialled their technology in a bunch of communities. One community happened to be a city very close to where I grew up: Guelph, Ontario. You've probably already guessed that it didn't really catch on.

A major problem with Mondex cards is that they're like cash — if you lose them or they get stolen, the money's gone. Worse, if there's some sort of malfunction with the card, if the card reader wouldn't read it, there's no way to figure out if that card had balance on it or not. In these scenarios, Mondex would typically eat the cost. They'd assume that the card was loaded and reimburse the user for that lost money. Of course, that can cost a company a lot of money. Further, the wallet was slow and clunky.

It was much faster to pay with a credit card or with cash. And retailers hated having several payment terminals; they wanted just one for credit cards. All these factors together did Mondex in. Flowever, these cards were smart cards, which means that they have small microcontrollers on them, and that technology has proved successful. In many countries today, including Canada, where I live, every single credit card and every single debit card now has smart card technology in it.

It's used for a different purpose, though. It's not used to prevent double-spending — the problem doesn't arise since it's not a cash-based technology. The bank, rather than your card, keeps track of your balance or available credit. Instead the chip is used for authentication, that is, to prove that you know the PIN that's associated with your account.

But Mondex was using it long before this technology was adopted widely by the banking industry. But there were a bunch of different proposals for how to do this and different companies did it differently. One far-fetched possibility: what if the government of a particular country actually authorized services to mint digital money, creating new cash out of thin air?

That was the idea behind NetCash, although it never got beyond the proposal stage. A different system, used by e-Gold, was to put a pile of gold in a vault and to issue digital cash only up to the value of the gold.

Another company called Digigold wasn't fully backed by gold, but had partial reserves. All of these ideas ultimately peg the value of digital cash to the dollar or a commodity. If the dollar's value goes up or down, the value of your digital money holdings will change along with it.

A radically 13 different possibility is to allow digital money to be it own currency, issued and valued independently of any other currency. To create a free-floating digital currency that is likely to acquire real value, you need to have something that's scarce by design. In fact, scarcity is also the reason why gold or diamonds have been used as a backing for money. In the digital realm, one way to achieve scarcity is to design the system so that minting money requires solving a computational problem or "puzzle" that takes a while to crack.

This is what happens in Bitcoin "mining", which we'll look at in Chapter 5. The basic idea — that solutions to computational puzzles could be digital objects that have some value — is pretty old. It was first proposed by cryptographers Dwork and Naor as a potential solution to email spam back in What if, every time you sent an email, your computer would have to solve one of these puzzles that would take a few seconds to solve?

To enforce this requirement, the recipient's email program would simply ignore your email you didn't attach the solution to the computational puzzle. For the average user, it wouldn't be that much of a barrier to sending emails because you're not sending emails very frequently. But if you're a spammer, you're trying to send out thousands or millions of emails all at once, and solving those computational puzzles could become prohibitive. A similar idea was later discovered independently by Adam Back in in a proposal called Flashcash.

These computational puzzles need to have some specific properties to be a useful spam deterrent. First, it should be impossible for a spammer to solve one puzzle and attach the solution to every email he sends. To ensure this, the puzzle should be specific to the email: it should depend on the sender and receiver, the contents of the email, and the approximate time at which it's sent.

Second, the receiver should be able to easily check the puzzle solution without having to repeat the process of solving the puzzle. Third, each puzzle should be totally independent of the others, in the sense that solving one puzzle does not decrease the amount of time it takes to solve any other puzzle. Finally, since hardware improves with time and solving any given computational puzzle gets faster and cheaper, recipients should be able to adjust the difficulty of the puzzle solutions that they will accept.

These properties can be achieved by using cryptographic hash functions to design the puzzles, and we'll study this in Chapter 1. Bitcoin uses essentially the same computational puzzle as Flashcash, but with some minor improvements. Bitcoin does a lot more than Flashcash does, though — after all, it takes a whole book to explain Bitcoin!

I only mention this because Flashcash inventor Adam Back has said, "Bitcoin is Flashcash extended with inflation control. It's sort of like saying, "a Tesla is just a battery on wheels. Observe that in Flashcash, your cost to solve a number of puzzles is simply the sum of the individual costs, by design.

But this is different from the cost structure for a government to mint money. If you think about how anti-counterfeiting technology in a paper currency, there's a huge 14 initial cost to acquire all the equipment, create the security features, and so on. But once they've done all that, their costs go down, and it doesn't matter much if they print one bill or a hundred bills.

In other words, minting paper money has a huge fixed cost but low marginal cost. Rivest and Shamir wanted to design computational puzzles that would mimic these properties, so that minting the first coin is massively computationally challenging, but minting subsequent coins is a lot cheaper. Their proposal also utilized hash functions, but in a different way. We won't get into the details of their solution, but the problem they were trying to solve is interesting at a high level.

Why did Hashcash never catch on for its intended purpose of preventing spam? Perhaps spam just wasn't a big enough problem to solve. For most people spam as a nuisance, but not something that they want to spend their computing cycles on combatting.

We have spam filters today that work pretty well at keeping spam out of our inboxes. It's also possible Hashcash wouldn't have actually stopped spammers. In particular, most spammers today send their spam using 'botnets', large groups of of other people's computers that they take control of using malware.

They might just as well use those computers to harvest Hashcash. That said, the idea of using computational puzzles to limit access to resources is still an idea that's kicking around. You can see it in some proposals for replacing network protocols, such as MinimaLT. Recording Everything in a Ledger Another key component of Bitcoin is the block chain: a ledger in which all Bitcoin transactions are securely recorded.

The ideas behind the block chain are again quite old, and trace back to a paper by Haber and Stornetta in Their proposal was a method for secure timestamping of digital documents, rather than an digital money scheme. The goal of timestamping is to give an approximate idea of when a document came into existence.

More importantly, timestamping accurately conveys the order of creation of these documents: if one came into existence before the other, the timestamps will reflect that. The security property requires that a document's timestamp can't be changed after the fact. In Haber and Stornetta's scheme, there's a timestamping service to which clients send documents to timestamp. When the server receives a document, it signs the document together with the current time and as well as a link or a pointer to the previous document, and issues a "certificate" with this information.

The pointer in question a special type pointer which links to a piece of data instead of a location. That means that if the data in question changes, the pointer automatically become invalid. In Chapter 1 we'll study how we can create such pointers using hash functions. What this achieves is that each document's certificate ensures the integrity of the contents of the previous document. In fact, you can apply this argument recursively: each certificate essentially fixes the entire history of documents and certificates up until that point.

If we assume that each client in the system keeps track of at least a few certificates — their own documents' certificates, and those of 15 the previous and following documents — then collectively the participants can ensure that the history cannot be changed after the fact. In particular, the relative ordering of documents is preserved. Figure 4: linked timestamping. To create a certificate for a document, the timestamp server includes a hash pointer to the previous document's certificate, the current time, and signs these three data elements together.

A later paper proposed an efficiency improvement: instead of linking documents individually, we can collect them into blocks and link blocks together in a chain. Within each block, the documents would again be linked together, but in a tree structure instead of linearly. This decreases the amount of checking needed to verify that a particular document appears at a particular point in the history of the system.

Visually, this hybrid scheme looks like Figure 5. Figure 5: efficient linked timestamping. Arrows represent hash pointers and dotted vertical lines indicate time intervals. This data structure forms the skeleton of Bitcoin's block chain, as we'll see in Chapter 3. Bitcoin refines it a subtle but important way: a Hashcash-esque protocol is used to delay how fast new blocks are added to the chain.

This modification has profound and favorable consequences for Bitcoin's security model. There is no longer the need for trusted servers; instead, events are recorded by a collection of untrusted nodes called "miners".

Every miner keeps track of blocks, rather than having to rely on regular users to do it. Anyone can become a miner by solving computational puzzles to create blocks. Bitcoin also gets rid of signatures, relying only on hash pointers to ensure the integrity of the data structure. Finally, the actual timestamps aren't of much importance in Bitcoin, and the point of 16 the system is to record the relative ordering of transactions in a tamper-resistant way.

In fact, Bitcoin blocks aren't created in a fixed schedule. The system ensures that a new one is created every 10 minutes on average, but there's considerable variation in the time between successive blocks. In essence, Bitcoin combines the idea of using computational puzzles to regulate the creation of new currency units with the idea of secure timestamping to record a ledger of transactions and prevent double spending.

There were earlier, less sophisticated proposals that combined these two ideas. The first is called b-money, and it was by Wei Dai in In b-money, anyone can create money using a hashcash-like system. There's a peer-to-peer network, sort of like in Bitcoin. Each node maintains a ledger, but it's not a global ledger like in the Bitcoin block chain. Each node has its own ledger of what it thinks everyone's balance is.

Another similar proposal, by Nick Szabo, is called Bitgold. Szabo says he had the idea for Bitgold as early as , but didn't get around to blogging about it until The reason I mention this is that there's a minor conspiracy theory popularized by Nathaniel Popper, a New York Times reporter who wrote a very good book on the history of Bitcoin. Popper notes that the blog post timestamps were changed after Satoshi posted the Bitcoin whitepaper so that the Bitgold proposal looks like it was written up about two months after Bitcoin was released.

The problem with this explanation is that if you actually read the contents of the blog posts, Szabo is very clear about having had this idea in , and he doesn't try to change those dates. So a more reasonable explanation is that he just bumped the post to the top of his blog after Bitcoin popularized similar ideas, to make sure that people were aware of his prior proposal. Bitcoin has several important differences from b-money and Bitgold.

In those proposals, computational puzzles are used directly to mint currency. Anyone can solve a puzzle and the solution is a unit of money itself. In Bitcoin, puzzle solutions themselves don't constitute money. They are used to secure the block chain, and only indirectly lead to minting money for a limited time. Second, b-money and Bitgold rely on timestamping services that sign off on the creation or transfer of money. Bitcoin, as we've seen, doesn't require trusted timestamping, and merely tries to preserve the relative order of blocks and transactions.

Finally, in b-money and Bitgold, if there is disagreement about the ledger among the servers or nodes, there isn't a clear way to resolve it. Letting the majority decide seems to be implicit in both authors' writings. But since anyone can set up a node — or a hundred, hiding behind different identities — these mechanisms aren't very secure, unless there is a centralized gatekeeper who controls entry into the network.

In Bitcoin, by contrast, for an attacker to change history, they must solve computational puzzles at a faster rate than the rest of the participants combined. This is not only more secure, it allows us to quantify the security of the system.

Neither took off, or was even implemented directly. Unlike the Bitcoin white paper, there wasn't a full specification or any code. The proposals gloss over issues that may or may not be solvable. The first, as we've already mentioned, is how to resolve disagreements about the ledger. Another problem is determining how hard the computational puzzle should be in order to mint a unit of currency.

Since hardware tends to get dramatically cheaper over time for a fixed amount of computing power, Bitcoin incorporates a mechanism to automatically adjust the difficulty of the puzzles periodically. B-money and Bitgold don't include such a mechanism, which can result in problems since coins may lose their value if it become trivially easy to create new ones. Hints about Satoshi You may know that Satoshi Nakamoto is the pseudonym adopted by the creator of Bitcoin.

While his identity remains a mystery, he communicated extensively in Bitcoin's early days. Let's use this to dig a little bit into questions like when he started working on Bitcoin, to what extent he was influenced by the prior ideas we've looked at, and what motivated him.

Satoshi says he started coding Bitcoin around May I'll take him at his word; the fact that he's anonymous is not a reason to think he'd lie about things like that. He registered the domain bitcoin. And at that time, he started sending private emails to a few people who he thought might be interested in the proposal.

Then a little later in October , he publicly released a white paper that described the protocol, and then soon after, he released the initial code for Bitcoin as well. Then he stuck around for about two years, during which he posted lots of messages on forums, emailed with lots of people, and responded to people's concerns. On the programming side, he submitted patches to the code. He maintained the source code in conjunction with other developers, fixing issues as they arose.

By December , others had slowly taken over the maintenance of the project, and he stopped communicating with them. I've been referring to Satoshi Nakamoto as a "he," but I have no particular reason to believe Satoshi is a man and not a woman. I'm just using the male pronoun since Satoshi is a male name. I've also been referring to him as a single individual.

There is a theory that Satoshi Nakamoto might be a collection of individuals. I don't buy this theory — I think Satoshi is probably just one person. The reason is that if we look at the entirety of the online interactions undertaken under the Satoshi pseudonym, if we think about the two years that Satoshi spent replying to emails and patching code, it's hard to imagine that this could be multiple people sharing user accounts and passwords, responding in a similar style and a similar voice, and making sure they didn't contradict each other.

It just seems a much simpler explanation that at least this portion of Satoshi's activity was done by a single individual. Furthermore, it's clear from his writings and patches that this individual understood the full code base of Bitcoin and all its design aspects. So it's very reasonable to assume that the same individual wrote the original code base and the white paper as well.

Finally, it's possible that Satoshi had help with the original design. However, after Bitcoin's release, we can see for ourselves that Satoshi was quick to attribute any help he received from other contributors. It would be out of character for him to mislead us about inventing something by himself if he had had help from other people. Next, we might ask ourselves, "What did Satoshi know about the history of ecash?

In the white paper he cites some papers on basic cryptography and probability theory. He also cites the time-stamping work that we saw earlier, and it's very natural to think that he based the design of the block chain on these references since the similarities are so apparent. He also cites the Hashcash proposal whose computational puzzle is very similar to the one that's used in Bitcoin. He also has a reference to b-money. Later, on the website, he added references to Bitgold and as well to a scheme by Hal Finney for reusing computational puzzle solutions.

But, if we look at the email exchanges that were made public by people who corresponded with Satoshi Nakamoto in the early days, we find that the b-money proposal was actually added after-the-fact, at the suggestion of Adam Back. Satoshi then emailed Wei Dai who created b-money and apparently, Dai was the one that told him about Bitgold. So these proposals weren't probably inspirations for the original design.

He later corresponded a lot with Hal Finney, and that's quite a reasonable explanation for why he cites Finney's work, at least on the website. Based on this, it seems plausible that when creating Bitcoin, Hashcash and time-stamping were the only things from the history of ecash that Satoshi knew about or thought were relevant. After he came to know of b-money and Bitgold, however, he seems to have appreciated their relevance.

In mid, the Wikipedia article on Bitcoin was flagged for deletion Wikipedia's editors because they thought it wasn't noteworthy. So there was some discussion between Satoshi and others about how to word the article so that Wikipedia would accept it.

To that end, Satoshi suggested this description of Bitcoin: "Bitcoin is an implementation of Wei Dai's b-money proposal on Cypherpunks in and Nick Szabo's Bitgold proposal. But, what about everything else — the Chaumian ecash schemes and the credit card proposals that we looked at? Did Satoshi know any of that history when designing Bitcoin? It's hard to tell. He didn't give any indication of knowing that history, but it's just as likely that he didn't reference this because it wasn't relevant to Bitcoin.

Bitcoin uses a completely different decentralized model and so there's no compelling reason to dwell on old centralized systems that failed. Satoshi himself makes this point, by mentioning Chaumian ecash in passing, in one of his posts to the Bitcoin forums.

Writing about another proposal called opencoin. Maybe they would be interested in a new direction. A lot of people automatically dismiss e-currency as a lost cause because of all the companies that failed since the 's.

I hope it's obvious 19 it was only the centrally controlled nature of those systems that doomed them. I think this is the first time we're trying a decentralized, non-trust-based system. Bitcoin's decentralization is indeed a defining feature that sets it apart from almost everything we've look at.

Another interesting quote from Satoshi suggests that he might not be an academic. Most academic researchers think about ideas and write them down immediately, before they build the system. Satoshi says that he took an opposite approach: "I actually did Bitcoin kind of backwards.

I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed specification. There are bugs and questionable design choices in the original Bitcoin code as well as in its design.

For example, there was a feature to send bitcoins to IP addresses that never caught on and, in retrospect, was a bad idea. When he described what Bitcoin was useful for, his scenarios were centered on the idea of using it across the internet. That use case is central to Bitcoin, of course, but it's not the only one.

He didn't indicate a vision of going into a coffee shop and being able to pay for your coffee with Bitcoin, for example. A final question we may ask ourselves, colored by what we understand from the history of digital cash, is, "Why does Satoshi maintain his anonymity? To begin with, it might be just for fun. Many people write novels anonymously, and there are graffiti artists like Banksy who maintain their anonymity.

In fact, in the community that Satoshi was involved in at that time, the Cypherpunk community and the cryptography mailing list, it was common practice for people to post anonymously. On the other hand, there could have been legal worries behind Satoshi's choice.

Two U. In , one of the founders of Liberty Reserve fled the United States, fearing that he would be indicted on money laundering charges. E-Gold's founders, on the other hand, stayed in the United States, and one was actually indicted and eventually pled guilty to the charges.

This guilty plea was registered just right before Satoshi set up the Bitcoin website and started emailing people about his proposal. That said, numerous people have invented ecash systems, and nobody else was scared of the legal implications or has chosen to remain anonymous.

So this may have been the reason, it may not have been the reason. It's also worth recalling that certain aspects of ecash were patented, and that members of the Cypherpunk movement were concerned about implementing ecash systems due to these patents. In fact, one post to the cypherpunks mailing list proposed that a group of anonymous coders implement ecash so that if someone were to sue, they wouldn't be able to find the coders. While it is difficult to think that Bitcoin would violate the ecash patents given how different its design is, perhaps Satoshi was being extra cautious.

Or maybe he was just inspired by the idea of an anonymous coder from the cypherpunk community. We know that Satoshi has a lot of bitcoins from his mining early on, and due to Bitcoin's success these are now worth a lot of money. I think this is a plausible reason.

After all, choosing to be anonymous isn't a decision you make once, it's something that you do on a continual basis. That said, it probably wasn't Satoshi's original reason. The first time Satoshi used the name Satoshi Nakamoto, he hadn't even released the whitepaper or the codebase for Bitcoin, and it's hard to imagine that he had any idea that it would be as successful as it was.

In fact, at many points in its early history, Satoshi was optimistic but cautious about Bitcoin's prospects. He seems to have understood that many previous efforts had failed and that Bitcoin might fail as well Concluding remarks The success of Bitcoin is quite remarkable if you consider all the ventures that failed trying to do what it does.

Bitcoin has several notable innovations including the block chain and a decentralized model that supports user-to-user transactions. It provides a practically useful but less-than-perfect level of anonymity for users. In Chapter 6 we'll take a detailed look at anonymity in Bitcoin.

In one sense it's weaker than the strong anonymity in DigiCash, but in another sense it's stronger. That's because in DigiCash, it was only the senders of the money that maintained their anonymity, and not the merchants. Bitcoin gives both senders and merchants whether users or merchants the same level of anonymity. Let me conclude with some lessons that we can learn from Bitcoin through the lens of the previous systems that we've looked at.

The first is to not give up on a problem. Just because people failed for 20 years in developing digital cash doesn't mean there isn't a system out there that will work. The second is to be willing to compromise. If you want perfect anonymity or perfect decentralization you'll probably need to worsen other areas of your design.

Bitcoin, in retrospect, seems to have made the right compromises. It scales back anonymity a little bit and requires participants to be online and connected to the peer-to-peer network, but this turned out to be acceptable to users. A final lesson is success through numbers. Bitcoin was able to build up a community of passionate users as well as developers willing to contribute to the open-source technology.

This is a markedly different approach than previous attempts at digital cash, which were typically developed by a company, with the only advocates for the technology being the employees of the company itself. Bitcoin's current success is due in large part to the vibrant supporting community who pushed the technology, got people using it, and got merchants to adopt it.

Digital Cash: commerce on the net 2nd ed. Morgan Kaufmann, A cryptographically-oriented overview of e-cash systems Chapter 1 and micropayments Chapter 7 B. Rosenberg ed. Handbook of Financial Cryptography and Security. CRC Press, Although not Chaum's earliest paper on e-cash, this is arguably the most innovative, and it formed a template replicated by many other papers: D.

Chaum, A. Fiat, M. Untraceable electronic cash. Many papers improved the efficiency of Chaum-Fiat-Naor using modern cryptographic techniques, but arguably the most significant is: J. Camenisch, S. Hohenberger, A. Lysyanskaya, Compact e-cash. Theory and Applications of Cryptographic Techniques, Some practical security observations on the financial industry and proposals, including Mondex: R.

Security Engineering 2nd ed. Wiley, An overview of the implementation of Chaum's ecash proposal: B. Basic security of the ecash payment system. State of the Art in Applied Cryptography, Two papers cited by Satoshi Nakamoto in the Bitcoin whitepaper that are integral to Bitcon's design: A. Haber, W. Secure names for bitstrings. CCS, In fiat currencies, organizations like central banks control the money supply and add anti-counterfeiting features to physical currency.

These security features raise the bar for an attacker, but they don't make money impossible to counterfeit. Ultimately, law enforcement is necessary for stopping people from breaking the rules of the system. Cryptocurrencies too must have security measures that prevent people from tampering with the state of the system, and from equivocating, that is, making mutually inconsistent statements to different people.

If Alice convinces Bob that she paid him a digital coin, for example, she should not be able to convince Carol that she paid her that same coin. But unlike fiat currencies, the security rules of cryptocurrencies need to be enforced purely technologically and without relying on a central authority. As the word suggests, cryptocurrencies make heavy use of cryptography. Cryptography provides a mechanism for securely encoding the rules of a cryptocurrency system in the system itself. We can use it to prevent tampering and equivocation, as well as to encode the rules for creation of new units of the currency into a mathematical protocol.

Before we can properly understand cryptocurrencies then, we'll need to delve into the cryptographic foundations that they rely upon. Cryptography is a deep academic research field utilizing many advanced mathematical techniques that are notoriously subtle and complicated to understand.

Fortunately, Bitcoin only relies on a handful of relatively simple and well-known cryptographic constructions. In this chapter, we'll specifically study cryptographic hashes and digital signatures, two primitives that prove to be very useful for building cryptocurrencies. Future chapters will introduce more complicated cryptographic schemes, such as zero-knowledge proofs, that are used in proposed extensions and modifications to Bitcoin.

Once we've learnt the necessary cryptographic primitives, we'll discuss some of the ways in which those are used to build cryptocurrencies. We'll complete this chapter with some examples of simple cryptocurrencies that illustrate some of the design challenges that we need to deal with. For the purpose of making the discussion in this chapter concrete, we will assume a bit output size. Flowever, our discussion holds true for any output size as long as it is sufficiently large.

Intuitively this means that for a given input string, you can figure 23 out what the output of the hash function is in a reasonable amount of time. More technically, computing the hash of an n-bit string should have a running time that is O n. Those properties define a general hash function, one that could be used to build a data structure such as a hash table. We're going to focus exclusively on cryptographic hash functions.

For a hash function to be cryptographically secure, we're going to require that it has the following three additional properties: 1 collision-resistance, 2 hiding, 3 puzzle-friendliness. We'll look more closely at each of these properties to gain an understanding of why it's useful to have a function that behaves that way. The reader who has studied cryptography should be aware that the treatment of hash functions in this book is a bit different from a standard cryptography textbook.

The puzzle-friendliness property, in particular, is not a general requirement for cryptographic hash functions, but one that will be useful for cryptocurrencies specifically. Property 1: Collision-resistance. The first property that we need from a cryptographic hash function is that it's collision-resistant.

A collision occurs when two distinct inputs produce the same output. A hash function H. Figure 1. Notice that we said nobody can find a collision, but we did not say that no collisions exist. Actually, we know for a fact that collisions do exist, and we can prove this by a simple counting argument. The input space to the hash function contains all strings of all lengths, yet the output space contains only strings of a specific fixed length. Because the input space is larger than the output space indeed, the input space is infinite, while the output space is finite , there must be input strings that map to the same output string.

In fact, by the Pigeonhole Principle there will necessarily be a very large number of possible inputs that map to any particular output. Now, to make things even worse, we said that it has to be impossible to find a collision. Yet, there are methods that are guaranteed to find a collision. Since we picked more inputs than possible outputs, some pair of them must collide when you apply the hash function.

The method above is guaranteed to find a collision. The fact that we can find a collision by only examining roughly the square root of the number of possible outputs results from a phenomenon in probability known as the birthday paradox.

In the homework questions at the end of this chapter, we will examine this in more detail. This collision-detection algorithm works for every hash function. But, of course, the problem with it is that this takes a very, very long time to do. That's of course an astronomically large number — if a computer calculates 10, hashes per second, it would take more than one octillion 10 27 years to calculate 2 hashes!

For another way of thinking about this, we can say that, if every computer ever made by humanity was computing since the beginning of the entire universe, up to now, the odds that they would have found a collision is still infinitesimally small. So small that it's way less than the odds that the Earth will be destroyed by a giant meteor in the next two seconds.

We have thus seen a general but impractical algorithm to find a collision for any hash function. A more difficult question is: is there some other method that could be used on a particular hash function in order to find a collision? In other words, although the generic collision detection algorithm is not feasible to use, there still may be some other algorithm that can efficiently find a collision for a specific hash function.

But this function also has an efficient method for finding a collision. Notice that this function just returns the last bits of the input. This simple example illustrates that even though our generic collision detection method is not usable in practice, there are at least some hash functions for which an efficient collision detection method does exist. Yet for other hash functions, we don't know if such methods exist. We suspect that they are collision resistant.

However, there are no hash functions proven to be collision-resistant. The cryptographic hash functions that we rely on in practice are just functions for which people have tried really, really hard to find collisions and haven't yet succeeded. In some cases, such as the old MD5 hash function, collisions were eventually found after years of work, leading the function to be deprecated and phased out of practical use.

And so we choose to believe that those are collision resistant. Application: Message digests Now that we know what collision-resistance is, the logical question is: What is collision-resistance useful for? Here's one application: If we know that two inputs x and y to a collision-resistant hash function H are different, then it's safe to assume that their hashes H x and H y are different — if someone knew an x and y that were different but had the same hash, that would violate our assumption that H is collision resistant.

This argument allows us to use hash outputs as a message digest. Consider SecureBox, an authenticated online file storage system that allows users to upload files and ensure their integrity when they download them. Suppose that Alice uploads really large file, and wants to be able to verify later that the file she downloads is the same as the one she uploads. One way to do that would be to save the whole big file locally, and directly compare it to the file she downloads. While this works, it largely defeats the purpose of uploading it in the first place; if Alice needs to have access to a local copy of the file to ensure its integrity, she can just use the local copy directly.

Collision-free hashes provide an elegant and efficient solution to this problem. Alice just needs to remember the hash of the original file. When she later downloads the file from SecureBox, she computes the hash of the downloaded file and compares it to the one she stored. If the hashes are the same, then she can conclude that the file is indeed the one she uploaded, but if they are different, then Alice can conclude that the file has been tampered with.

Remembering the hash thus allows her to detect accidental corruption of the file during transmission or on SecureBox's servers, but also intentional modification of the file by the server. Such guarantees in the face of potentially malicious behavior by other entities are at the core of what cryptography gives us. The hash serves as a fixed length digest, or unambiguous summary, of a message.

This gives us a very efficient way to remember things we've seen before and recognize them again. Whereas the entire file might have been gigabytes long, the hash is of fixed length, bits for the hash function in our example. This greatly reduces our storage requirement. Later in this chapter and throughout the book, we'll see applications for which it's useful to use a hash as a message digest. The problem is that this property can't be true in the stated form.

Consider the following simple example: we're going to do an experiment where we flip a coin. If the result of the coin flip was heads, we're going to announce the hash of the string "heads". If the result was tails, we're going to announce the hash of the string "tails".

We then ask someone, an adversary, who didn't see the coin flip, but only saw this hash output, to figure out what the string was that was hashed we'll soon see why we might want to play games like this. In response, they would simply compute both the hash of the string "heads" and the hash of the string "tails", and they could see which one they were given.

And so, in just a couple steps, they can figure out what the input was. The adversary was able to guess what the string was because there were only two possible values of x, and it was easy for the adversary to just try both of them. In order to be able to achieve the hiding property, it needs to be the case that there's no value of x which is particularly likely. That is, x has to be chosen from a set that's, in some sense, very spread out.

If x is chosen from such a set, this method of trying a few values of x that are especially likely will not work. The big question is: can we achieve the hiding property when the values that we want do not come from a spread-out set as in our "heads" and "tails" experiment?

Fortunately, the answer is yes! Stored Hashcash chris dixon's blog. Introduction — sx 1 documentation. Spondoolies-Tech SP10 Dawson 1. BIP - Bitcoin. Getting started - Bitcoin. Running Bitcoin - Bitcoin. New Links Hacker News. Quark crypto currency. Errno 9 using the multiprocessing module with Tornado in Python. Demonstration of sharing file descriptors across processes. Tornado Web Server Internals. Socket Programming In Python. Socket programming. Socket programming in C.

Tornado - different Web programming. Tornado web. Nullege: A Search Engine for Python source code. How to setup Django server with virtualenv on Ubuntu ZeroRPC Introduction - lightweight distributed communications framework. Un nginx. Fork system call - Wikipedia, the free encyclopedia.

Hello world tornado working with circus. Tornado Documentation — Tornado 2. Asynchronous networking — Tornado 2. Multiprocessing and sockets in Python - Stack Overflow. Run a method in a subprocess in a Tornado app. An example of how to use coroutines with IOStream. Simple example of creating a socket server with Tornado. Django websockets with tornado, gevent and zeromq. Little dumb experiment with Tornado and 0MQ. Shades of grey LinkedIn. Ben Shneiderman. Treemap Art. When does the tornado IOLoop get blocked?

Stop tornado ioloop using signal OmarHQ. Examples — fuggetaboutit 0. BloomFilter py - Google Search. Bloom Filters in Python - Random randomness. PySnippet: Named tuple. So, You Bought a Raspberry Pi. Now What? Newegg Unscrambled. Meet the Team — Asher. CoinJar Blog. Can't stop Bitcoin from dropping down? How easy or difficult is it to modify bitcoin source to change coin behavior. ISU breach? Data breach could affect 30, Iowa State students.

Biggest Bitcoin Mining Operation in Texas. Transaction inclusion and exclusion. Deep cold storage solutions for bitcoins? Hardware wallet wire protocol. YubiKey NEO. What's relay fee! Does blockchain distribution work like in bittorrent? Cipher Machines.

Cryptanalysis of the Enigma - Wikipedia, the free encyclopedia. Remove obsolete RequestHandler. How to use epoll? A complete example in C - Banu Blog. Logging Cookbook — Python v2. Using the WebSocket protocol with Twisted. Demonstration of sharing file descriptors across processes Tornado Gists. Multisignature MN Transactions — sx 1 documentation.

Deterministic Wallet — sx 1 documentation. Full Node Implementation — libbitcoin 1 documentation. Overview — libbitcoin 1 documentation. Crypto and Private Keys — libbitcoin 1 documentation. Network Protocol — libbitcoin 1 documentation. Using Threadpools in Python - Irrational Exuberance. Julien Herbin personal webpage - a Python ThreadPool implementation. ThreadPoolTask - Google Search. Blocks mined on. BTC-e Phneep!

Can we get some informations about "The rise and rise of Bitcoin" and when does it get released to the Public? Buy bitcoins instantly with mobile phone, sms or landline - bitby. Bitcoin Fees. Bitcoin Data. Bitcoin Theft. Transaction fees - Bitcoin. Bit Tech. Mt Gox to liquidate coins. Is trust the biggest barrier to Bitcoin adoption?

Introduction — libbitcoin 1 documentation. UpCoder coding blog. Conformal Systems, LLC. Enabling SSL on original client daemon - Bitcoin. Accept bitcoins using python - Agiliq Blog Django web app development. How to get information about a transaction bitcoin qt rpc. Where do I send it? On Exchange! Go Concurrency Patterns. Python and Flask Are Ridiculously Powerful.

API — snakeMQ 1. Exploits Database by Offensive Security. Request blocked Privoxy supermicro. Obelisk Of Light protocol documentation — obelisk 0. Libbitcoin Info Page. Sandia National Laboratories: News Releases : Modern-day cleanroom invented by Sandia physicist still used 50 years later. Satoshi Client Sockets and Messages - Bitcoin.

Alternative chain - Bitcoin. BitCoin and Cryptocurrencies - Will they fail? My 3 Predictions! API calls. Smart card wallet - Bitcoin. BTC Sender - Bitcoin. Black magic with metaclasses in Python - The Iconfinder Blog. A Primer on Python Metaclasses.

Kernel Density Estimation in Python. Frequentism and Bayesianism: A Practical Introduction. Data model — Python v2. How to export public key for an address in bitcoin-qt? Is it possible to get the public key of a bitcoin address I do not have the private keys for with the standard client?

Transactions - Bitcoin. WeWork Washington D. R - Google Search. Opportunities - Federal Business Opportunities: Opportunities. Lets Talk Bitcoin. Repost: Request: Make this anonymous? Russia Reconsiders Bitcoin? The panel not so much : Bitcoin. OpenBitTorrent - An open tracker project. Combining tornado and zmq ioloops: Connection reset by peer exception at Programming Languages.

ZeroMQ based tornado request handlers - Google Groups. Tornado Internals TechnoBeans. Obey the Testing Goat! The C10K problem. Good night, Posterous. NULL on error. An Introduction to Tornado. More than just a pretty web framework: the Tornado IOLoop. Just a little Python: ZeroMQ flow control and other options.

Evented Django part one: Socket. IO and gevent codysoyland. Am I evil, or is killing patents just plain fun? A proof of storage system filetype:pdf - Google Search. ZeroCater YC W11 is looking for a full-stack engineer to help feed the world. Amazon Web Services Sign In.

AWS Amazon Kinesis. Decentralized mining protocol standard: getblocktemplate ASIC ready! Proposal: Base58 encoded HD Wallet root key with optional encryption. Proof of stake instead of proof of work. Proof of Storage to make distributed resource consumption costly. Bitcoin Improvement Proposals - Bitcoin. HashCash filetype:pdf - Google Search. John Resig - Asm. Being truly asynchronous with Tornado paper cruncher.

How was tonight premiere of 'The Rise and Rise of Bitcoin'? Download bitcoin Torrents - KickassTorrents. Bitcoin on the big screen Fox Business Video. Chrome extension just stole my BTC : Bitcoin. Ghostery - Download. Ghostery Configuration Walkthrough. Protocol Specification - Bitcoin. Getblocktemplate - Bitcoin. Quantum computing for the determined Michael Nielsen. Essays Michael Nielsen. Why Bloom filters work the way they do DDI. HyperDex Homepage :: super. D-Wave - Google Search.

Hack The Multiverse Programming quantum computers for fun and profit. PostgreSQL: The world's most advanced open source database. Thank you for downloading PostgreSQL! Lerer Ventures. PeriodicCallback - Google Search. Asynchronous programming in Tornado.

Why We Accept Bitcoin. Servers Direct Blade Servers. Flappy Deployment notes for Ubuntu Instance Nginx, uwsgi, postgres, django, virtualenv stack. HashFast Bitcoin Mining. BTX Trader - Home. Atlas ATS. Coinfloor Limited. More bandwidth. More drive. Securing Your Server — Linode Library. At Mt. Gox bitcoin hub, 'geek' CEO sought both control and escape Reuters.

Tutorial — PyMongo 2. Latest posts of: Mike Hearn. BitAngels - Google Search. Security Strategy - Google Docs. Identity protocol v1 - Bitcoin. Contracts - Bitcoin. Bitcoin Forum - Index. Class-based views Django documentation Django. Commutative encryption - Google Search.

What are "named tuples" in Python? Help would be really aprechiated here, some digits of password unknown. Encrypted wallet. Using neural nets to recognize handwritten digits Hacker News. G Squared Capital Welcome. Partnered News. Automated Clearing House - Wikipedia, the free encyclopedia. Federal Reserve System - Wikipedia, the free encyclopedia. Electronic Payments Network - Wikipedia, the free encyclopedia. Fedwire - Wikipedia, the free encyclopedia.

ZenPayroll Engineering. A primer on financial derivatives. Derivative finance - Wikipedia, the free encyclopedia. Extolabs - EX1 3. Page not found - - AngelList. LikeInAMirror Thoughts on computing. People's home pages. Security via Sounding Impressive. Python DNS server with Redis backend. ByteCoin - Google Search. Bytecoin Explorer. Cryptography Research. Balance - CEX. Best practice for fast transaction acceptance - how high is the risk? Welcome to the BitSat project - Google Groups.

Regarding BitSat uplink rate - Google Groups. C1 Specifications - Google Groups. Dunvegan Space Systems, Inc. Nginx support — uWSGI 2. Bitcoin Dogged by Stubborn Downtrend. Follow The Coin Video: Mt. Gox and Decentralization. Download Bitcoin Armory. Facebook now has 1. You could soon use bitcoin to support political campaigns - Apr.

State's top banker to tackle bitcoin, digital currency. Is Bitcoin A Safe Bet? A Quick Guide To Cryptocurrency. Home - First Look Media. Grand St. The problems and some security implications of websockets. IPO Correct - Businessweek. Leslie Picker LesliePicker on Twitter. MIT Technology Review. Team — opencoin. BitStats The musings of a wannabe statgeek. Thank you for using Auto Refresh Plus. The Nation. What is Namedtuple in Python?

My Drive - Google Drive. TDD is dead. Long live testing. OnePlus One - OnePlus. Game Programming Patterns. SecureDrop Freedom of the Press Foundation. Dark Mail Technical Alliance. Compiling instructions - Bitmessage Wiki. The alarming rise of Adderall in two charts - Quartz. IO - Bitcoin mining pool. Sirius by Comcast: Technical Overview. Dai Wei. Wei Dai's Home Page. Nick Szabo, Wei Dai Who are their employers?

Real-time gross settlement - Wikipedia, the free encyclopedia. Page cannot be displayed: Bank of Japan that it was not able to display the page: Bank of Japan. Google Chrome could not find en. What is the blockchain equivalent?

Response rendering. The History of Python: New-style Classes. How to use Django with Gunicorn Django documentation Django. Design — Gunicorn Depth data viewer. Confirm your subscription. Bitcoin-Economy Bitcoin Made Simple. Chrome Web Store - Buffer. Good times ahead! I'm now using Buffer to make posting to Twitter and Facebook a lot easier.

Why Try Twitter Application Management. Julianne Kim - UMD ' Announcements — IPython. Banking Technology. Cointerra CryptoCoinUpdates. Getting Started - Vagrant Documentation. Invite David A. Form handling with class-based views Django documentation Django. Working with forms Django documentation Django. Using mixins with class-based views Django documentation Django. BitAngels DApps Fund. Bitcoin and Token based investment community. BitAngels - Google Groups. Dunne Capital AngelList.

The Quest for Randomness » American Scientist. Inbox 4, - a. Commotion Wireless. The page you were looking for doesn't exist Bitcoin Protocol Explained 1 - Bitcoin paper broken down step by step. Bitcoin and other DACs — a new cyber-lifeform?

What's in a Name? Built-in template tags and filters Django documentation Django. Working with trees in templates — django-mptt 0. The Django template language: For Python programmers — Django 1. Product Details.

Bitstamp mybitcoins api gadget hack para bitcoins for sale

Commit john mcfee bitcoin apologise

Healthy! double bitcoins in 100 hours from now amusing