Randomizer wrote:Been looking over their forums/thinking about this a bit...
One thing that strikes me as odd, if GPUs are so much more powerful than CPUs, and thus bit coin miners are using them to mine, why isn't my computer using GPU-type architecture rather than a CPU? Wouldn't that give me more processing power for the buck? Or am I missing something here? :/
Not really, it's just that the process used to "mine" (sha256) is particularly well suited to GPU's.
How does the system keep track of who owns what? It says it does it by keeping track of transactions, but then individual transactions get pruned from the block tree or line or whatever after a while to save disk space, so eventually things like "Bob paid Sally on June 23rd 2012" would disappear from the chain.
No. A particular client may
prune the blockchain that they use locally, under the protocol. This is not presently done as far as I am aware, certainly not by the standard client. And it's a feature that permits independent clients to operate on devices with limited storage, such as smartphones. Under certain (limited) conditions, it reduces the trust that the user should have with accepting coins, but the full blockchain is likely to always exist somewhere
Does the system also keep a running tally of everyone's accounts?
That's also possible under the protocol, and the clients do this for any local users' accounts/keypairs, but this is not currently done on any macro level.
E.G. - Account aBcD owns X bitcoins, Account EFGh owns Y bitcoins, etc. and here's all the transactions that have happened since that info was last updated, check both to see if a given transaction is valid. Or how does it know? It has to have some way of keeping track, otherwise I could just say, "Yeah, I've got this (fake) bitcoin and it's totally worth 100 BTC, lemme sign that for you with my (valid) private key and you can give me the goods."
It does have a way of keeping track. The pruning is only done for compactness, and no transaction that has not already been "referenced" (i.e. spent) is ever pruned. Nor any transactions, spent or not, younger than a certain age. I don't believe the age is a set number, as different clients could have different levels of trust, but suggestions on the development forum wouldn't permit pruning of transactions younger than about 10K block deep, or roughly ten weeks old.
On the subject of tracking wealth - there's supposed to be a max of 21,000,000 bitcoins, divisible by 8 decimal points, so 2,100,000,000,000,000 units total (I'll call them "bits"). So, you have over 2 quadrillion bits to keep track of. If each bit was stored in an individual address/"account number", and only took one byte each to keep track of (obviously it'd take more), that would be over a petabyte of information. You would need a -lot- of hard drives to store that much info. It would not be possible to keep track of everyone's money as every working node has to individually hold all of this information, and even servers don't usually put a thousand hard drives in their computers.
This is part of the reason for the pruning, but the system also consistantly recombines transactions. For example, a person chooses to spend 50 bitcoins on something, but his coins were all sent to him in smaller transactions. The client, at present, will attempt to combine the oldest set of transactions that total to at least 50 bitcoins, potentially referencing dozens of transactions and then produce two transactions as it's output. One for the 50 bitcoin payment, and the other for the change left from the prior transactions. Once those referenced transactions are deep enough in the blockchain, they can then be pruned from the blockchain of any client that is setup to do so.
So, if someone wanted to, they could break up their bitcoins into the smallest possible units for the purpose of requiring more resources to run the program. Sure, it's unlikely for people to deliberately/accidentally break down all money in the system that far, but such a "worst case scenario" should still be planned for.
Not only has this attack been considered, it's been attempted. The current transaction fee table automaticly charges a tiny fee for any transaction smaller than .01 bitcoin, so this kind of attack remains possible for as long as the attacker still has bitcoins to burn and is still willing to continue to pay for the privilage of "spamming" the network. So in the end, it is a possible attack on the network, but no one seems to mind being spammed when their being paid for the aggravation. Of course, only the generators stand to gain from the transaction fees, and the regular users have trouble getting their transactions processed, but it all happens eventually.
I noticed in the forums, the question of attrition is said to "come up at least every other week." As such, perhaps it should be covered in the FAQ/a sticky thread made? But the solution proposed does not satisfy me - "Add extra zeros to the end of the bitcoin and you could run the whole economy on one coin!" For one thing, there is the memory issue I pointed out before - there's already potential for a couple petabytes of info to keep track of. Add another 0 and you multiply the potential requirements by 10. Another 0 and you multiply the potential by 10 again.
The question of attrition is one that is so small, and so far in the future, that if it really is a problem in 130 years when the system stops inflating, then I'm sure that it can be addressed. Keep in mind that the Federal Reserve Note, the oldest fiat reserve currency in continuous us on Earth, is not yet 130 years old.
But the other problem is, people were saying, "Alright, so what if you added an extra 0, the price of milk stays the same!" but if this division is necessary, the price of milk would -not- stay the same, it would decline to reflect the fact that there are fewer bitcoins in circulation and people could only offer so many to buy milk. Maybe not immediately, but eventually.
I would consider it a small issue, even if I live to see the day.
The thing is, what if not all those bitcoins not in circulation were truly "lost"? What if someone had meticulously kept a number safe? Perhaps they'd been passed down a few generations for just such an occasion? A man using his 50 bitcoin inheritance could completely overwhelm the "we run on one bitcoin!" economy.
With a minimum value of exchange, sure, a baker could offer 6 loaves of bread for a penny, but if you only want one you won't get any change back. A minimum value of exchange is important, because then everyone knows the lowest that prices can go. For this, there needs to be a way to reclaim lost coins (and to distinguish between "oops, I set my hard drive on fire" and "hey, those are -MY- pennies in the piggybank! I'll turn 'em in when I'm good and ready!").
I don't even understand what you are asking here.
One question that came up was collisions and how that would be very (astronomically) unlikely. But what if someone deliberately wanted to crank out private keys until they got a/all public keys that matched another/all users'? "Start with private key 00000000, get the corresponding public key. Increment the private key to 00000001, get the corresponding public key, repeat. Oh, hey, this private key works with this public key which happens to have some money on it! Woot!" How much computational power would it take to brute force this? And another question, how much hard drive space would a full pre-computed table take up?
Go ahead and try it. I doubt you get very far.
Are there plans to update the encryption when such an attack is deemed "computationally feasible"?
Yes, actually there is, but not just for this unlikely attack vector. The crypto used for each section of the system are modular, and can be swapped out for a more secure version of the same type of function in the event that the existing function is found to be faulty. This isn't easy to do, and would require a lot of people to agree to upgrade, but it can be done and is planned if neccessary.
Another attack would be to make bitcoins illegal in whatever country. Sure, that wouldn't stop individuals from trading, but businesses that don't want to get on the wrong side of the law won't be adding "pay with bitcoins!" to their stores any time soon.
Sadly, this is one issue that cannot be addressed at the codebase or network level.
Another mode of attack - process blocks, but don't actually process any transactions in them. If there is a minimum number of transactions required for a generated block to be accepted, fill it with transactions to and from yourself. If you manage to compute the block first, congratulations! You've just backlogged everyone else by an extra ten minutes!
This can be done, and probably is, but the transaction fees, however rare they are, act as an incentive for generators to process those transactions at least. There is nearly zero overhead for the generators to add transactions to the block, so there isn't really an economic advantage to not doing so.
How well does the system scale? If bitcoin managed to get the whole world on its network, how many transactions per second would there be, and would the network be able to cope? For comparison, how many transactions are there per second with banks and the like? Could bitcoin's own success destroy it? Especially when it doesn't just have to deal with passing money around, but with people obfuscating transactions by passing coins to themselves. It doesn't cost the bank any processor power or bandwidth for me to move a twenty from my wallet to my coin purse and back. With bitcoin it does.
It scales fairly well, but there is a top end limit. The system is designed that, should it ever become popular for everyday transactions, the main network (blockchain included) would function more of a backbone; processing major transactions between banks and the like; while websites such as Mybitcoin.com function as the user level transaction processing a la Paypal. The difference being is that if you get mad a Paypal, all you can do is get your money back and stop using them; whereas with Bitcoin I could move my funds to another such website or to my own client at my will.