Bitcoin: Virtual money created by CPU cycles

Posted Nov 11, 2010 14:41 UTC (Thu) by n8willis (subscriber, #43041)
Parent article: Bitcoin: Virtual money created by CPU cycles

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] (9 responses)

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] (8 responses)

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] (7 responses)

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] (6 responses)

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] (5 responses)

"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] (4 responses)

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] (3 responses)

"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] (1 responses)

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.