한국   대만   중국   일본 
Bitcoin: Virtual money created by CPU cycles [LWN.net]
|
|

Bitcoin: Virtual money created by CPU cycles

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing

November 10, 2010

This article was contributed by Nathan Willis

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.

[Bitcoin GUI]

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


( Log in to post comments)

Bitcoin: Virtual money created by CPU cycles

Posted Nov 11, 2010 2:38 UTC (Thu) by fsateler (subscriber, #65497) [ Link ]

> but the question remains: are the CPU cycles you spend "mining" for
> Bitcoins worth the value of the Bitcoins you receive?

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).

Where to start ?

Posted Nov 12, 2010 13:30 UTC (Fri) by copsewood (subscriber, #199) [ Link ]

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.

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.

Where to start ?

Posted Nov 13, 2010 0:39 UTC (Sat) by jgarzik (guest, #8364) [ Link ]

At the size of a national economy, you're right, bitcoin P2P network would be managed by Big Players (albeit algorithm-sanctioned participants, not government-sanctioned participants).

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.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 11, 2010 11:06 UTC (Thu) by spaetz (guest, #32870) [ Link ]

While certainly open to criticism, most people seem to focus on the creation aspect (which is simply a way to bootstrap all 21m coins). I would expect that most people don't "make" their own bitcoins but rather by them on the currency exchanges, the same way that people don't mint the coins they spend via paypal now.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 11, 2010 14:18 UTC (Thu) by jackb (guest, #41909) [ Link ]

Unless you can consume the currency yourself (maybe you are using grains of rice as currency) the value of each unit of currency basically defined by the total value of the goods and services that can be purchased by the currency divided by the number of currency units in circulation.

Bitcoin value depends on the value of what people are willing to sell you for them.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 13, 2010 0:41 UTC (Sat) by jgarzik (guest, #8364) [ Link ]

Yes. And that is true for all markets and currencies, not just bitcoin.

As of this writing, 1 bitcoin is approximately USD $0.25.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 11, 2010 14:41 UTC (Thu) by n8willis (subscriber, #43041) [ Link ]

The trouble is that the mining process is *not * "simply" a way to bootstrap distributing the currency, it's the mechanism that validates all transactions. If a few users manage to game that system in a way that allows them to unfairly corner too much of the Bitcoin money supply, that will discourage others from participating, which in turn weakens the network as a whole.

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

Bitcoin: Virtual money created by CPU cycles

Posted Nov 11, 2010 15:32 UTC (Thu) by ballombe (subscriber, #9523) [ Link ]

Why I am not sure to understand is the point of making blocks so expensive (in real money) to compute. Maybe it should be possible to raise threshold once the first phase is done.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 11, 2010 16:04 UTC (Thu) by nybble41 (subscriber, #55106) [ Link ]

I don't think there is any reason to make block *expensive*, per se, but if the threshold is too low then blocks will be generated in rapid succession, with negative effects on synchronization between peers. To perform useful work the client must know about the most recent block in the chain, since a reference to the previous block is among the criteria for accepting a new one. Currently one block is generated every 10 minutes (ideally). Increase that by much more than a factor of two or three and many of the clients may end up wasting most or all of their efforts on outdated block chains.

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.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 19, 2010 22:18 UTC (Fri) by creighto (guest, #71377) [ Link ]

Yes, there is a reason to make block generation cryptologically "expensive". The difficulty level increases with the growth of the network, in addition to keeping new distribution fairly even, to prevent a brute force attack upon the blockchain. The total proof-of-work of the blockchain is massive, and would require a surreal level of computational ability to "fake" prior transactions, even if other safeguards didn't exist. This is the point, as such an attack on the blockchain would undermine the faith in the currency system. Even at this early stage, it would take nation-state level resources to overtake the collective power of the network, but it is still possible if an attacker is willing to commit enough resources to the goal. It would still take much more than the total market value of Bitcoins to succeed at such an attack.

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.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 22, 2010 22:16 UTC (Mon) by nybble41 (subscriber, #55106) [ Link ]

None of which is affected in the slightest, to be best of my knowledge, by the overall rate of block generation. It shouldn't matter whether we get 6 blocks per hour (as now) or 1,000 blocks per hour, so long as all the clients remain synchronized, the distribution of successful blocks is even, and the rate of block generation is kept approximately linear over time. The total CPU-time consumed creating a given amount of the block chain (in real time, not blocks) is the same either way.

It is the size of the network which protects against "brute force" attacks, not the difficultly of each individual block.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 23, 2010 0:33 UTC (Tue) by creighto (guest, #71377) [ Link ]

"It is the size of the network which protects against "brute force" attacks, not the difficultly of each individual block."

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.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 23, 2010 8:21 UTC (Tue) by nybble41 (subscriber, #55106) [ Link ]

I understand, and I think we actually do agree on this if we could just put it into the right terms. My use of "difficulty" was wrong; that is a term with a very specific meaning in Bitcoin, but I was using it in a generic sense to refer to the time it takes to generate a block (the target rate), not the number of hashes or upper limit for acceptable solutions (which are derived from that target rate and the actual rate).

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.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 23, 2010 23:01 UTC (Tue) by creighto (guest, #71377) [ Link ]

"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."

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.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 23, 2010 23:22 UTC (Tue) by creighto (guest, #71377) [ Link ]

Sorry, that last line should read "10 per hour"

Bitcoin: Virtual money created by CPU cycles

Posted Nov 24, 2010 3:21 UTC (Wed) by nybble41 (subscriber, #55106) [ Link ]

So we do agree, then. It is only the practice (synchronization and block-chain size), and not any issue with the theory of operation, which leads to low rate of block generation. If synchronization and the size of the block-chain were not significant factors then the rate at which blocks are generated could be arbitrarily high without impacting the security of the system.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 24, 2010 20:00 UTC (Wed) by creighto (guest, #71377) [ Link ]

Generally speaking, yes. There might be other technical issues that I'm not aware of, but we do agree.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 19, 2010 22:08 UTC (Fri) by creighto (guest, #71377) [ Link ]

Generation is expected to become a natural balance in the long run, with generation occuring at just below a break even point as major players take over majority processing due to self interest in the security of the system. Basicly, Bitcoin versions of banks will invest in datacenters instead of massive safes, guards and lawyers. The average user would be unlikely to generate, although he always will be able to do so if he so chooses. The single young adult geek living in crackerbox efficiency apartment in Toronto who has only baseboard electric heating loses nothing by trying, and this forever prevents a permanet monopoly upon the network, as other players can choose to jump into the game anytime they feel motivated to do so.

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.

How does this scale?

Posted Nov 11, 2010 18:52 UTC (Thu) by droundy (subscriber, #4559) [ Link ]

What I fail to understand from this article is how this scales with number of clients and number of transactions. Since *every* new transaction worldwide has to go into each new block, and blocks are purely serial, it's hard to imagine how this could scale to anything close to "real money".

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.

How does this scale?

Posted Nov 11, 2010 19:05 UTC (Thu) by n8willis (subscriber, #43041) [ Link ]

Believe me, I would have addressed that if there was an explanation from the Bitcoin project about how it plans to handle scaling. The documentation is pretty spread out on the wiki, and even after reading the forums, the potential for a scaling problem *seems* to be just another one of the areas in which the system would benefit from a thorough third-party review from domain experts.

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
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?

Posted Nov 12, 2010 0:28 UTC (Fri) by jgarzik (guest, #8364) [ Link ]

Currently the block size limit is 1MB, which limits us to 463 transactions/minute. See http://www.bitcoin.org/smf/index.php?topic=1314.0 and http://www.bitcoin.org/smf/index.php?topic=1347.msg15366#...

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.

How does this scale?

Posted Nov 12, 2010 5:22 UTC (Fri) by JohnLenz (guest, #42089) [ Link ]

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.

How does this scale?

Posted Nov 12, 2010 8:31 UTC (Fri) by jgarzik (guest, #8364) [ Link ]

The bitcoin community is well aware of Visa and Paypal transaction rates.

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.

How does this scale?

Posted Nov 12, 2010 21:30 UTC (Fri) by droundy (subscriber, #4559) [ Link ]

I'm a bit skeptical. You're talking about 1.7M per second that needs to be sent to every client on the network, right? Since as I understand, each client needs to examine all the blocks to verify the integrity of the chain. And can clients really afford to compute the hash of a couple of megabytes per second? Or would most clients just trust someone else to verify the integrity of the bitcoin system?

How does this scale?

Posted Nov 13, 2010 0:34 UTC (Sat) by jgarzik (guest, #8364) [ Link ]

Drawing an analogy to the Gnutella network...

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.

How does this scale?

Posted Nov 19, 2010 22:26 UTC (Fri) by creighto (guest, #71377) [ Link ]

If the Bitcoin network ever reaches a level even close to that of Visa, then there will be numerable finacial institutions with a clear, vested interest in the security of the system; who are very likely to run dedicated servers (if not entire server farms) to keep the system secure and competing institutions honest. It will still be possible for an individual to dedicate his own resources to set up such a server, but most users will not need to participate.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 19, 2010 21:42 UTC (Fri) by creighto (guest, #71377) [ Link ]

"Thus the duplicate transaction will eventually be merged back into the same block chain as the original, and the insufficient funds will be noticed"

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.

Bitcoin: Virtual money created by CPU cycles

Posted Nov 23, 2010 8:32 UTC (Tue) by bsamwel (guest, #66171) [ Link ]

Even though the idea sounds interesting, what about the environmental implications? I mean, SETI searches are far fetched but at least they're good for *something*, this seems like (indirectly) burning coal for money. I don't know how many people are going to be doing this, but if a million people were using two cores a day to do this... what does that use? Let's use a conservative estimate of 50W. 50W * 1M = 50 MW of power down the drain, or 10% of the yield of one of a typical coal power plant. Add another 20% if somebody releases an easy-to-install client that uses GPU power.

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!

Bitcoin: Virtual money created by CPU cycles

Posted Nov 23, 2010 23:17 UTC (Tue) by creighto (guest, #71377) [ Link ]

Block generation is voluntary, and not expected to be done by the average user. The current client is an early (working) reference client, and the blockchain is bulky and expected to grow larger in the future. The system allows for a "lightweight" client that can verify transactions that are sent to it with a fair degree of certain on it's own without needing the entire blockchain and without the ability to generatate new blocks. The network is expected to stratify into various clients with different goals. Mybitcoin.com is a working example of this, as even a lightweight client isn't neccessary for anyone with cheap and continuous Internet access on their cell phone.

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.


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds