Bitcoin: Virtual money created by CPU cycles
The Bitcoin virtual currency system was launched in 2009, but has gained increased exposure in recent months as a few businesses and entities announced that they would support transactions in Bitcoins (abbreviated "BTC"). Bitcoin is not the first attempt to create an entirely virtual currency, but it supports some very interesting features, including anonymity and a decentralized, peer-to-peer network structure that verifies Bitcoin transactions cryptographically.
One of Bitcoin's advantages over other currency systems is that it does not rely on a central authority or bank. Instead, the entire network keeps track of — and validates — transactions. It also separates "accounts" from identities, so transactions are, for all practical purposes, anonymous. Two users can make a Bitcoin exchange without knowing each others' real identities or locations. Because Bitcoin does not rely on brick-and-mortar banks and because the Bitcoin currency is divisible down to eight decimal places, it is seen by proponents as a potential micropayment system that works better than the fee-based, currency-backed banking systems of today.
Bitcoin 101
The Bitcoin project was devised and created by Satoshi Nakamoto. There is an RFC-style draft specification available on the project's wiki, although it is not an IETF project. The current specification is numbered 0.0.1, and outlines a Bitcoin transaction message. Considerably more detail is required to explain how the system works in practice, however. The two key ideas are Bitcoin addresses and blocks.
Actual Bitcoins do not exist as independent objects anywhere in the Bitcoin network. Instead, the P2P network of Bitcoin clients keep track of all Bitcoin transactions — including the transfer of Bitcoins from one Bitcoin address to another, and the creation of new Bitcoins, which is a tightly controlled process.
A Bitcoin address is a hash of the public key of an Elliptic Curve Digital Signature Algorithm (ECDSA) public/private key pair. Whenever a new user starts up the Bitcoin client, it generates a new Bitcoin address that is initially associated with zero Bitcoins. But the address is not tied to the identity of the user in any way; in fact clients can generate multiple Bitcoin addresses to easily isolate or categorize transactions. A user's keys are stored locally in a wallet.dat file; losing or erasing the file means that all Bitcoins associated with the addresses inside are effectively lost.
Sending Bitcoins from one address to another is done by publishing a transaction to the network, listing both the source and destination address along with the amount, signed by the source address's private key. The transaction is propagated to all of the active clients on the network. These transactions are collected into the other Bitcoin primitive, the block. Active clients periodically publish new blocks, which serve as the permanent record of all of the transactions that have taken place since the last block was published.
Unlike signing and verifying recent transactions, publishing a block is not a trivial affair. It is, instead, a cryptographic problem that a client must solve with a reward offered for doing so. The Bitcoin network is designed so that block publishing is a difficult task, and the reward will encourage users to run the client software, which in turn validates and records the ongoing transactions.
The Bitcoin network is currently in currency-issuing mode; during this phase, whenever a client solves and publishes the network's next block, the client is credited with 50 freshly-created Bitcoins. That provides the incentive for clients to contribute CPU (or GPU) cycles to the process. The block-solving reward amount is scheduled to drop on a regular basis; eventually dropping to zero. At that point, transaction fees will replace Bitcoin-generation as an incentive for clients to participate.
The problem that constitutes "solving" a block is novel. Clients perform SHA-256 hash calculations on a data set consisting of the recent transactions, the previous block's hash value, and a nonce. Each hash is then compared to a published threshold value; if the hash is below the threshold, the client has solved the block. If not, the client generates a new nonce and tries again. The threshold value is chosen to be artificially low, so that the hashes (which are pseudo-random) have a very small chance of being below it. Thus it takes many CPU cycles to stumble across a hash that solves the block, but it is trivial for all other clients on the network to check that the hash is genuine.
Bitcoining in practice
As of November 9, there have been just under 91,000 blocks published, and there are about 4.5 million BTC in circulation. The project says that approximately six blocks are solved and published per hour, and according to the reward-reduction schedule, the eventual total circulation will be just short of 21 million BTC. The threshold value is periodically adjusted to keep the rate of new blocks predictable — presumably to provide some level of guarantee that transactions are validated and recorded in a timely fashion.
The project has an official, MIT/X11-licensed Bitcoin client application available for download. The current release is numbered 0.3.14. OS X, Windows, and Linux builds (both 32-bit and 64-bit) are provided in addition to the source code. The client serves two purposes; it allows the user to keep track of his or her wallet and its associated Bitcoin addresses, and it runs a background process to solve blocks. There is a command-line version of the client available in addition to the GUI, for use on headless machines.
The GUI client's interface is simple: there is a transaction log, balance count, and Bitcoin "address book." From the address book, you can generate new Bitcoin addresses at will. The block-solving functionality is activated or deactivated from the "Settings" menu. The Options configuration dialog allows you to limit the number of processors on which to run (by default Bitcoin uses all available CPUs). The client communicates to Bitcoin peers over TCP port 8333, and for the moment is IPv4-compatible only.
At the moment, of course, running the fastest client possible is the key to grabbing as many fresh Bitcoins as you can. In addition to the official Bitcoin client, there are several third-party variants that tailor the block-solving routine for different processor architectures — including OpenCL and CUDA-capable 3-D graphics cards. The official client runs its solver with the lowest possible priority, so keeping it running constantly should not severely impact performance — third-party clients may or may not offer such a guarantee.
SHA-256 is generally considered to be strongly pseudo-random, so your odds of solving the current block on any given try do not increase the longer you run the client. However, all of the active Bitcoin clients "mine" — try to solve the current block — simultaneously, so dedicating more or faster cores increase your chances of solving the current block now, before someone else does and everyone starts over on a new block.
Criticisms and questions
Despite a design in which all clients supposedly have an equal chance of solving the next block and earning the reward, some Bitcoin users on the project's official forum seem to think that the current system is driving away casual users, because users with fast GPUs can check hashes ten- or twenty-times faster than a typical CPU. Several of the users that have written custom GPU-mining clients do not make their code publicly available, and thus generate significantly more Bitcoins than the average participant — including one individual who is alleged to represent 25% of the block-solving power of the network at any one time.
An online calculator allows you to put in the current hashes-per-second count reported by the client and estimate how long it would take on average to solve a block at that speed. I tested Bitcoin 0.3.14 on an (apparently modest) Athlon X2 system that is predicted to average one block solve every 94 days. That does seem like a discouragingly-low-payoff for keeping two CPU cores running 24 hours a day.
The system does seem to score high on privacy and fraud-prevention, though. All transactions between clients are conducted in the clear, but because Bitcoin addresses rely on public-key cryptographic signatures, an attacker cannot forge a transaction outright. The system has other safeguards in place to prevent attacks on the block-solving system. That is why, for example, each block includes the hash of the previous solved block — this creates a "block chain" that clients can trace backwards all the way to Bitcoin's first "genesis block" for verification purposes.
The distributed network design offers its own set of challenges. For example, if a rogue client simultaneously (or nearly simultaneously) broadcasts two transactions to different parts of the network that total more BTC than the client actually has, both transactions could temporarily be validated if two different clients simultaneously solve the current block. In that case, however, one of the two competing blocks will be invalidated by the next block solved, and all of the transactions in the invalidated block returned to the general queue. Thus the duplicate transaction will eventually be merged back into the same block chain as the original, and the insufficient funds will be noticed.
Some of Bitcoin's security relies on all of the participating clients knowing and agreeing on the rules of the game. For example, a rogue client could attempt to award itself 100 BTC upon solving a block, but the illegal amount would be caught and flagged by honest clients.
Nevertheless, there does not seem to have been a serious examination of Bitcoin's security by outside professional researchers. Beyond the basic transaction framework, there are numerous features in the system that might make for a plausible attack vector. For example, the system includes a way for senders to script transactions, so that they are only triggered after a set of conditions has been met.
Some of the adaptive measures in the system use arbitrary time frames that seem geared towards human convenience, rather than pro-active prevention of attacks — such as re-evaluating and adjusting the difficulty of the block-solving threshold only every 2,016 blocks. It is also possible to send Bitcoin payments directly to an IP address instead of to a Bitcoin address; in some sense, a "buyer beware" caution is advised, but it is also possible that there are exploits yet undiscovered.
Economics
The bigger open questions about Bitcoin are about its viability as a currency system. For the moment, the majority of the "businesses" that accept BTC as a payment method are online casinos, but a few less-shady establishments (such as the Electronic Frontier Foundation) have recently decided to accept Bitcoin transactions.
There is a dedicated economics forum on the Bitcoin project Web site; there debates circulate about the strengths and weaknesses of the Bitcoin system, specifically whether it has any value as a "real" currency, but also on more technical points, such as the arbitrary limit on the number of Bitcoins to be minted, and the decision to limit each Bitcoin's divisibility (a Bitcoin can be divided down to eight decimal places to spend in transactions).
Another wrinkle is that Bitcoins are effectively "virtual cash" — which makes them untraceable. Although the anonymity is important to some early-adopters, some are concerned that if the system were ever to catch on in widespread usage, governments would intervene to ban or block it because of the relative ease of tax evasion or money laundering.
Although BTC can be exchanged for other currencies, Bitcoin is different from electronic payment systems like Paypal that are really just computerized interfaces to traditional banks. There have been virtual cash systems in the past, such as David Chaum's digital-signature-based ecash, which in the late 1990s was redeemable at several banks, and more recently the Linden Dollars used and created inside Second Life.
Because Bitcoins are not tied to gold or to any other traded property, their value is determined solely by how much others are willing to exchange for them. Those who have had more economics than I will probably explain that this is true of all currency systems, but at the moment, there are several online BTC exchanges, such as BitcoinMarket.com, where one can observe the actual price of BTC-to-USD (or other currency) transactions. Whether those prices represent any real value seems to be entirely in the eye of the beholder. The rate on November 9 was 0.27 USD to 1 BTC. For comparison's sake, 94 days of dual-CPU processing power on Amazon's EC2 cloud service would cost $389.91. That is a for-profit example, of course, but the question remains: are the CPU cycles you spend "mining" for Bitcoins worth the value of the Bitcoins you receive? Does the abstract notion of "supporting the Bitcoin network" make up the difference? There is just no objective answer.
Some pundits think that Bitcoin is a viable prospect for a long-term virtual currency, but as always seems to be the case with economists, others disagree, citing government intervention and susceptibility to destruction by electromagnetic solar storms as risks to a digital-only currency system not backed by any physical monetary system.
The peculiarity of the idea itself seems to be waning in the face of recent global economic conditions, though, conditions which to Bitcoin proponents demonstrate how little "traditional" currencies offer over new, entirely virtual monetary systems. The Bitcoin network's current rate of BTC generation is scheduled to continue issuing new Bitcoins until 2140. If it lasts even a fraction of that amount of time, it will have outlasted the other purely-virtual currency systems, which is certainly worth ... something.
Index entries for this article | |
---|---|
Security | Cryptography |
GuestArticles | Willis, Nathan |
Posted Nov 11, 2010 2:38 UTC (Thu)
by fsateler (subscriber, #65497)
[Link] (2 responses)
Of course not. The value of any currency (at a very high level) depends on 2 factors: how much does it cost to get it, and how much do you/others actually want to get it. If these two factors go out of balance (in your example, it is cheaper to create money than to buy it -> it costs less than what people want to pay for it), you can arbitrage that difference and make money "for free" by creating coins and selling them. In fact, that is what several governments have done (because they are the only ones allowed to print money), search for what is called Seigniorage. In the Bitcoin case, where nobody has the power to mint extra coins, the arbitrage possibility is lost, which means that it must be more expensive (or at least the same) to produce a coin than to buy it.
That's why you don't see much people trying to print money and instead trade money for their services: it costs too much to produce (plus risk of getting caught).
Posted Nov 12, 2010 13:30 UTC (Fri)
by copsewood (subscriber, #199)
[Link] (1 responses)
These are not a group of potential prime movers I'd trust with defining the future policies and parameters of a monetary system more than the current bunch of jokers, whom we can vote out of office on occasion when we feel like it.
This particular experiment also seems to offer more a means of _consuming_ valuable resources than a means of _offering_ such as guarantee in exchange for currency offered in exchange for goods and services marketable in consideration for other currency options.
Distribute this one into millions of microcurrencies and more people can play at defining the parameters and acting as notaries within the context of more community localised networks. You also reduce the anonymity to something similar to current bank networks, which are politically tolerable from this point of view: anyone underwriting a system genuinely anonymous enough to fund terrorism or assassination will be taken out using military intervention if lesser sanctions fail. But if you are going to do this using millions of microcurrencies, you may as well use double entry accounting without arbitrary constraint on fiat monetary quantity, supported by issuer reputation, conventional crypto and smart cards.
Posted Nov 13, 2010 0:39 UTC (Sat)
by jgarzik (guest, #8364)
[Link]
With regards to anonymity, see http://www.bitcoin.org/wiki/doku.php?id=anonymity
While bitcoin addresses are randomly generated cryptographic signatures, not obviously associated with any one person, the entire block chain is publicly readable, and you can readily see transactions between any bitcoin address: http://theymos.ath.cx:64150/bbe
Thus, "anonymity" must be in quotes. Even if one follows the recommended practice of using a new bitcoin address for each transaction, statistical analysis can be performed on the public transaction data.
Posted Nov 11, 2010 11:06 UTC (Thu)
by spaetz (guest, #32870)
[Link]
Posted Nov 11, 2010 14:18 UTC (Thu)
by jackb (guest, #41909)
[Link] (1 responses)
Bitcoin value depends on the value of what people are willing to sell you for them.
Posted Nov 13, 2010 0:41 UTC (Sat)
by jgarzik (guest, #8364)
[Link]
As of this writing, 1 bitcoin is approximately USD $0.25.
Posted Nov 11, 2010 14:41 UTC (Thu)
by n8willis (subscriber, #43041)
[Link] (11 responses)
Also, if the mining mechanism is perceived as unfair by too many people, it isn't a problem that will go away when the new BTC are all minted, because the same hash-calculation-for-reward system persists after the "inflationary" period, just with transaction fees replacing new coinage as the reward.
Since it relies on voluntary mass participation by humans, getting the "fairness" balanced just right is a lot harder than getting the crypto right, you might say.
Nate
Posted Nov 11, 2010 15:32 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (9 responses)
Posted Nov 11, 2010 16:04 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link] (8 responses)
Worse, those who generate the most blocks within a single private network, with their peer connections most likely routed through a single server, will tend to get updated most quickly when new blocks are found. This lets them start work on the new chain sooner, and thus use their CPU time more effectively. Speeding up block generation would tend to give them even more of an edge in that regard.
Posted Nov 19, 2010 22:18 UTC (Fri)
by creighto (guest, #71377)
[Link] (7 responses)
In a presumed future with a market as large as PayPal(TM), the difficulty would presumedly be high enough to render such an attack technicly unfeasable in addition to economicly unfeasable.
Posted Nov 22, 2010 22:16 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link] (6 responses)
It is the size of the network which protects against "brute force" attacks, not the difficultly of each individual block.
Posted Nov 23, 2010 0:33 UTC (Tue)
by creighto (guest, #71377)
[Link] (5 responses)
Those two variables are on opposite sides of an equation. When the network grows, the difficulty automaticly increases to compensate and maintain a relatively consistant block interval.
Posted Nov 23, 2010 8:21 UTC (Tue)
by nybble41 (subscriber, #55106)
[Link] (4 responses)
Obviously you don't want the rate at which blocks are generated to increase sharply, since that would make it relatively easy to invalidate some or all of the work that went into creating the existing block chain. If it takes a year to get to block 1000, but only another week to get to block 2000, then you have a problem--a concerted effort could supplant the original block chain, or at least a significant suffix of it, with a new one of the attacker's choice, causing the system to break down (double-spending, etc.). For that to happen to the last day's transactions is one thing, but with a large rate of change a few day's effort could invalidate a much longer period of the chain history.
To avoid that the network has to regulate the rate at which new blocks are generated such that acceleration of that rate, if any, is extremely gradual; currently that means no average change at all, although there is some variation above and below the goal rate between difficulty adjustments.
What I'm saying, however, is that this goal rate doesn't have to be six blocks per hour to prevent so-called "brute force" attacks; provided the clients remain synchronized, it could just as easily be six blocks per *second*. I refer, of course, to a constant rate of six blocks per second since the network was formed, not a sudden 3600x drop in the difficulty from an existing six-blocks-per-hour chain. If there was to be a transition from one rate to the other it would have to be extremely gradual.
Posted Nov 23, 2010 23:01 UTC (Tue)
by creighto (guest, #71377)
[Link] (3 responses)
The clients could not stay synchronized anywhere near such a rate, and the rate of blocks does directly affect the growth of the total size of the blockchain. The target interval is an arbitrary decision, and one that could be changed with consensus in the future; but if it does change I would guess that it would be reduced from 6 blocks an hour to 4 or 3 per hour. The p2p network is currently very small, but in a future with Bitcoin as much of the online economy as PayPal; the network would likely be bogged down with latency at anything faster than 10 per minute.
Posted Nov 23, 2010 23:22 UTC (Tue)
by creighto (guest, #71377)
[Link]
Posted Nov 24, 2010 3:21 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
Posted Nov 24, 2010 20:00 UTC (Wed)
by creighto (guest, #71377)
[Link]
Posted Nov 19, 2010 22:08 UTC (Fri)
by creighto (guest, #71377)
[Link]
The vast majority of users will likely only run a 'lightweight' client, which can verify transactions made sent to itself by downloading only the relevant transactions via the network in real time, keeping only the block headers (80 bytes each) on local storage. The lightweight client neither needs the entire blockchain, nor all of the transactions, in order to function well. Another way to look at is that the blockchain is a massive, distributed ledger of the entire history of the system; and generation is the automatic equivalent of a notary public (or a bank) that substitutes for the trusted third party normally required in everyday credit based transactions. You don't need either a notary or a bank to by a hamburger at McD's with cash, the cashier only needs to look at the paper and judge that it's *very likely* that said paper is actually cash. The same is true with Bitcoin, if someone sends you bitcoins by creating a transaction and sending that to your client, the client can verify that the sender legitimately owned those coins at one time; and usually that is enough (depending on how well you trust the counterparty) but if it isn't then the blockchain will let you know with ever increasing confidence every ten minutes. With each new block, it becomes increasing unlikely that a 'double spend' or other fraud was committed against you as a seller, until that likelyhood crosses the "astronomicly unlikely" point and "matures" in the client. Bitcoins that are not yet mature can still be sent, but the receiver has a lower mathmatical certainty that they will mature for him, and so the client usually sends the most mature coins first. The maturity level of transactions/coins also positively affects the priority system for block inclusion (with regard to free transactions, a volutary fee can be added to a transaction to bump up the priority) , so there is an incentive for users to favor using the most mature coins that they possess.
Posted Nov 11, 2010 18:52 UTC (Thu)
by droundy (subscriber, #4559)
[Link] (7 responses)
Just think about the number of transactions per second we read about NASDAQ handling, and then consider how often you buy stock versus how often you buy... anything. And then consider that BTC is touted as being more useful for micropayments, since smaller values are allowed, which would mean that even *more* transactions are needed.
Posted Nov 11, 2010 19:05 UTC (Thu)
by n8willis (subscriber, #43041)
[Link]
I do know that clients relay what amount to transaction-id-hashes to each other to propagate messages, rather than full transaction logs, which is presumably one way they attempt to reduce overhead in the protocol.
The "network" wiki page is a pretty good starting point for digging in to this stuff, but like I said above, the overall picture of how the network works is kinda scattered out.
Nate
Posted Nov 12, 2010 0:28 UTC (Fri)
by jgarzik (guest, #8364)
[Link] (5 responses)
This limit can be raised in the future; it currently exists to avoid DoS.
As block size increases, transaction fees increase.
It is presumed that the system will scale up with dedicated P2P nodes processing blocks, and the vast majority of bitcoin users using a website or lightweight client that simply sends and receives transactions into the network.
Posted Nov 12, 2010 5:22 UTC (Fri)
by JohnLenz (guest, #42089)
[Link] (4 responses)
I don't think you understand how far you must scale. From here, it looks like Visa handled an average of 8,442 transactions per second in 2008 and built a new datacenter to handle up to 10,000 transactions per second. Also from the article, Visa handles only about 33% of all transactions. So using your numbers, 1 MB block gives about 7.71 transactions per second. Scaling from 7.71 transactions per second to 8,000 per second? So just to handle the volume visa saw in 2008, each block must be over one gigabyte? And this is only the US. By its nature, there is only a single bitcon currency for the whole world so 8,000 transactions per second is on the far low end.
Posted Nov 12, 2010 8:31 UTC (Fri)
by jgarzik (guest, #8364)
[Link] (2 responses)
A gigabyte every ten minutes is quite doable for modern machines and networks, and even more so in an imaginary future where bitcoin transaction rates equal Visa transaction rates.
At those rates, it's not hobbyists running the P2P network anymore; from the transaction fees alone, you're looking at competition among professional players with major investments in the network.
Posted Nov 12, 2010 21:30 UTC (Fri)
by droundy (subscriber, #4559)
[Link] (1 responses)
Posted Nov 13, 2010 0:34 UTC (Sat)
by jgarzik (guest, #8364)
[Link]
At Visa/Paypal transaction rates, most bitcoin clients will be leaf nodes, that send and receive transactions, but don't bother with the block chain.
Beefy ultrapeer nodes would be the ones storing transactions, building blocks, monitoring and verifying the block chain, etc. They are incentivized to do this with transaction fees, which non-generating leaf nodes would not receive.
Posted Nov 19, 2010 22:26 UTC (Fri)
by creighto (guest, #71377)
[Link]
Posted Nov 19, 2010 21:42 UTC (Fri)
by creighto (guest, #71377)
[Link]
This is inaccurate. Whichever of the two malicious transactions makes it into the majority block that is accepted as valid by the network is the one that "wins", and the other transaction is therefore an invalid transaction, forever to be ignored by the network because it depends upon prior transactions that have already been referenced. This is called the "double spend" fraud by the Bitcoin community. This is a well known attack vector, and one that is *very* difficult to pull off in practice for a number of reasons. Even if successful, this kind of attack is a fraud persecuted against one (or more) particular vendors, and affects only them in exactly the same way that attempts to spend counterfit paper money affects retail store outlets. Retail stores have those money markers to prevents such things, the Bitcoin protocal has similar checks that allow a (future) client to judge the odds of a double spending risk. However, there will always be potential ways to defraud people, and there is no way that any monetary system can remove all of those risks. The Bitcoin protocal policies were chosen to create an online currency that is as cashlike as is technically possible, and risks exist that are similar to such risks with holding cash.
"Let the buyer beware" is the rule of exchange in Bitcoin. If you can't trust the person that you are trading with, then you probably shouldn't be trading with him with anything. Would you send your credit card # to some random stranger on the Internet? If you would, then Bitcoin is the lower risk anyway, because at least your risk exposure is limited to what you told the client to send them.
As full disclosure, for those who couldn't figure it out already, I've been a member of the Bitcoin community and forum for some time.
"Several of the users that have written custom GPU-mining clients do not make their code publicly available, and thus generate significantly more Bitcoins than the average participant including one individual who is alleged to represent 25% of the block-solving power of the network at any one time."
This is also no longer accurate, as the member who this refers to has not increased his, notablely large, generation capacity while the network has expanded by at least 4 times since this claim was last made. It was likely an exageration when it was claimed to begin with, and it is impossible to know with any degree of certainty anyway.
Posted Nov 23, 2010 8:32 UTC (Tue)
by bsamwel (guest, #66171)
[Link] (1 responses)
What I would like to know is: what is the number of block solving clients that are needed to keep this system running, how does it scale? If only 50.000 clients could help 500M people pay securely with this kind of money, it's fine by me. If 500M people need to be block solving all day, what a waste!
Posted Nov 23, 2010 23:17 UTC (Tue)
by creighto (guest, #71377)
[Link]
As for the energy costs, that is a self balancing system in ways that are too complex to explain here. Much of the current generation is performed on GPUs in a much more energy efficient manner, but also much is performed by persons with a nominal extra cost for electric heat; such as the example of the lone geek living in Toronto with a small apartment that must be heated with electric resistive heat anyway. As the reward for generation drops, the number of people willing to generate will drop as well; keeping the total energy that the market is willing to consume to support the network balanced. It's not true that all transactions are free, nor will they always be free, and the energy consumption is a direct reflection of the willingness of the userbase to contribute to the clock-cycles to secure the system. Also, as the blockchain grows, so does the total proof-of-work that the blockchain represents; and the computing power required to secure the blockchain grows. Assuming that computing power remains stable (a silly assumption) the need for high difficulty levels to protect the blockchain gradually goes down. Not that I expect that computers will suddenly fail Moore's law, but relative to the computing power available the blockchain security becomes more efficient over time.
Bitcoin: Virtual money created by CPU cycles
> Bitcoins worth the value of the Bitcoins you receive?
Not sure why this one should fare better than similar proposals which have either failed or turned out as scams. Initial analysis suggests that should this experimental network ever scale to anything the size of an national economy, only owners of the most powerful and well connected data centres will have any good first chance of synchronising understanding and verification of the valid next block. That is not what I would call a 'peer to peer' network; this approach to cryptographic guarantee of anonymity seems to result in a currency system dancing to the tune played by the likes of Google, Facebook and the botnet herders.
Where to start ?
Where to start ?
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
How does this scale?
How does this scale?
PS - I guess it's also plausible that users would not regard it as mandatory that the *entire* network validate a transaction before they consider it a done deal; as time goes on you accumulate more and more "confirmation" messages for each transaction you've conducted. But it's technically valid as soon as a block that includes it is solved and becomes part of the block chain.
How does this scale?
How does this scale?
How does this scale?
How does this scale?
How does this scale?
How does this scale?
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles
Bitcoin: Virtual money created by CPU cycles