My main fear with something like bitcoin is this: imagine a virus or worm that infects machines and then transfers all bitcoin found on that machine to an anonymous address. There is absolutely no recourse. Hell, it could be a bitcoin "client" that continues to display the correct amounts to the user without them realizing they're being fleeced.
I already wrote some proof of concept code that steals a user's balance if they're using the Windows client. You'd just have to distill it down to shellcode and include it as a payload in a 100% silent driveby browser exploit.
POC code for Linux/BSD would be trivial, too. I'm not sure about Mac, but there's probably a way to do it via automator or regular message passing.
As I've been saying for a while on the BTC forums, the wallets will be the main target, not the crypto.
Completely agree. Although your code wouldn't help make a worm. Because even though you could get the Bitcoin client's peer addresses you couldn't remotely exploit them.
I'm worried about the bitcoin client being in c++ rather than java because that seems to make a remote code execution vulnerability a lot more likely. And given a single remote code exec vuln it'd be easy to make a worm which destroys the entire network.
It'd probably be easier to build a BTC-related website, let it grow a bit, then empty the wallets of everyone visiting it. It'd probably also be easier to compromise an existing site and throw your code/exploit up. I wouldn't try building a worm, that's for sure.
Not a concern. Hackers encrypt their high balance wallet.dat then store it on dropbox/whatever. Spending money is kept in a bitcoin bank (say < 100 usd) which can be easily used and transfered.
Once your bank wallet is too big or too small you just decrypt one of your wallet.dat files and transfer a portion of the money back to your bank wallet. Recrypt the now changed wallet.dat and you are good to go.
Once/if normal people start using bitcoin I highly doubt that they would even bother with the client ("Encrypt my what? Wallet.dat? I could lose everything?"). They would probably just use a highly reputable bitcoin bank. It could stay anonymous because there could be "cash for bitcoin" like sites around cities and a transfer could be made into the bitcoin bank without anyone ever knowing.
As for a virus in the bitcoin client itself, that has been tried a couple times. Each time someone tries a pull request with malicious code the forums/irc light on fire. Also, people are highly wary of new people submitting pull requests.
They would probably just use a highly reputable bitcoin bank. It could stay anonymous because there could be "cash for bitcoin" like sites around cities and a transfer could be made into the bitcoin bank without anyone ever knowing.
If you assume a world where everyone is using something like bitcoin these banks are extremely tempting hacker targets. If Bank of America gets hacked and someone discovers that a hacker/rouge employee/software bug/whatever transferred money from account A to account B they can reverse it.
What if you woke up one morning and on the news the president was telling the country that overnight all of the savings in Citibank had been transferred to an unknown individual/entity by a group of disgruntled employees… They're in jail now but we don't know who now has the 2 trillion dollars that was transferred. Keep using bitcoin.
Even if the wealth is gained legally, it leads to a system with no accountability. Everything is under the table.
What happened to geeks valuing transparency in government/corporate governance? I think geeks see this as freedom but it will do nothing more than might makes right. The system benefits geeks today and thugs with guns tomorrow. It's the perfect system for secretly applying your will onto the world without accountability. Who's good at that today? The mafia, gangs, corrupt politicians, dictators…
Gah, I have to collect my thoughts on this. I'm getting off into crazyville but I feel like this is where it leads.
In reality these bitbanks would probably have time delayed "safes" that only unlock the actual bitcoins after a waiting period. Transferring money between the banks, and even to prepaid visas would probably be done with reversible bank credit from one account to another. So the rouge employee is a minor issue whose cost could be absorbed into the profits of the bank. True, this isn't "real" bitcoins, but the system's pillars would be built upon something stable and (sort of) anonymous.
As for the massive hack scenario, the same fears of large scale loss hold true if someone hacks Dropbox or Facebook/Gmail and everyones files or personal messages get leaked. I would rather lose $1000 or even $10k than have my
Dropbox & Gmail hacked. Even in the extraordinarily unlikely case where cracker hackers get into the bitcoin equivalent of Citibank three thinks should happen: 1. Automated systems that detect higher than normal activity and begin immediate shutdown until the cause is resolved. 2. (Barring 1, somehow) Free market deposit insurance. 3. (Barring 2, somehow) A reversal of the block chain to some stable point.
Yes 3. would require a massive amount of consensus and the relative value of bitcoin would go down against USD, but I don't even think that is likely.
The mafia & gangs exist due to a lack of freedom and they have very little trouble moving money today. You can carry out millions of dollars fairly easily in jewelry already.
As for bribing politicians, that is an angle I haven't thought of before. I'll think about it, but I'll grant that it is a very valid concern, although synonymous with bribing politicians with expensive jewelry or art or transfer of anonymous investment corporations (Nevada iirc) or Bearer Share Corporations.
The biggest weakness of bitcoin in my opinion are some implementation details. For one, the way the difficulty rate for the miners is determined I can construct a scenario where a clandestine intelligence agency or a medium wealthy individual could take over the transaction history. By flooding a time window with gpus they could force the difficulty rate for the next time window way, way above the cost of electricity. Then they would have almost no competition in the next round because anyone with a utility bill would stop mining, so they would be left free to corrupt the block chain. The difficulty rate should have been a continuous function of the current hashing power.
Anyways, good debate. I have code to write, though. I hear you on a number of points (specifically the c compiler one, wow that is nuts), but they aren't enough to stop my libertarian nerd glee :)
Utility costs going above the block-finding reward doesn't just happen in the flooding scenario, it also happens naturally as we approach 21M. It's already (supposed to be) handled by transaction fees. I don't think you're ever going to see most of the network shut down mining.
I agree with your concerns although I think they are pretty analogous to people stealing gold out of banks. There's no recourse from that and if enough big gold reserves vanished I'm sure the gold market would be screwed up.
Of course those physical breakins are probly much much harder to pull off than hacking an electronic bank.
You would have a hard time finding anyone who uses off-the-shelf cryptography so carefully that long-term resident code on their box couldn't capture all the relevant keys. Your comment seems wishful.
People do the same segregation, between long-term non-transactional accounts and short term spending accounts, with their bank accounts. But businesses still need to keep non-connected isolated quarantined machines to access the bank.
The comment you're responding to didn't argue that wallets couldn't be encrypted. He argued that in the (not unlikely) event that a malware incident on your machine was able to compromise your wallet, you'd have no recourse. And: he's right. You wouldn't.
…in the (not unlikely) event that a malware incident on your machine…
I believe it's even worse than that. The normal instinct as shown by this response is to centralize security into a "super secure" bank. I think that's exactly the wrong thing to do. I would put some on a linux box in my closet, some on my mac, some on my flash drive, some on my windows PC. People would lose money all the time in a system like this but it would be better than having a big fat juicy target in one location.
I would be nervous living in a country where we're one data mishap away from not knowing who rightfully owns what, especially given our collective track record there. If people are serious about bitcoin, they need to get serious about adding identity into it.
Does anyone else see this as a regression? This is like the Wild West of economies, where you'd have to keep some Bitcoins locked in a safe in your study, some buried in a secret location under the porch you only know about, some under the mattress...
Doesn't anyone else feel like Bitcoin is (re)introducing a huge number of problems that were the primary drivers of creating banks in the first place?
"Not a concern. Hackers encrypt their high balance wallet.dat then store it on dropbox/whatever."
Not a concern?
And if the trojan sniffed your keystrokes as you typed in your password and/or grabbed a copy of the key you used to encrypt your wallet?
Or what if it just put in a trojan copy of whatever app you used to encrypt your wallet, so that everything you did (from typing in the password, to feeding it a key) would be sent on to the thief?
They would probably just use a highly reputable bitcoin bank
Just because a company is "highly reputable" doesn't mean that they aren't technologically incompetant. Just look at the Sony PSN episode, or any data protection leak from any bank.
One of the best suggestions in there is simply to separate your checking and savings accounts so that a compromise of your spending money doesn't leave you without any coins.
There's also a link in there that says the upcoming clients will store the wallet locally encrypted and only decrypt in memory for transactions-- there are weaknesses to this (i.e. the bitcoin client trojan you mention), but it's better than what is done today to secure the file on disk.
The solution here would be a browser plugin (sandboxed) that presents like the bitcoin client in a tab but interacts with a cloud account (that is supposedly very well secured) to derive its information.
The plugin could even interact with websites within a framework, or pickup bitcoin hyperlinks like with an emailto:.
No, Bitcoin is decentralized. One possible path in the future might be to centralize it for a time, then decentralize again. The author claims that only the original creators could do this, but that's not necessarily true, either.
He brings up a valid concern, but the linkbait title doesn't do it any justice because everyone will be focused on the technical aspects where he's talking about socio-economic problems.
I make a stronger claim then that, which is that Bitcoin must perform a transfer in the future, and that if this transfer is to be non-disruptive, it must be done in a centralized fashion. I will admit I debated over the title for some time, but I decided I wanted to emphasize Bitcoin as a succession of protocols, not the current one, which is a hopelessly myopic perspective.
This post doesn't make sense to me. Why wouldn't the following be a solution:
1. Create a bitcoin client that includes a better cryptographic algorithm.
2. When this new client is asked to vote on the validity of bitcoins created with the old algorithm it votes "no", but allows it to be grandfathered in, as long as the new client is still in the minority.
3. Once the old clients are obsoleted, you can then no longer create bitcoins with the old hash method, but even the very last bitcoin created with the old method is considered 100% valid by all clients.
Sorry, I'm not bitcoin or cryptographic expert, so I might be using the wrong language here, but I hope my basic point is clear: Accepting a bitcoin block as valid is not the same as voting as to whether a bitcoin block should be deemed valid... or am I missing something?
The problem is that if the cryptography is broken, in regards to #3, you have no idea if a token created with the 'old method' is real or counterfeit.
In a decentralised service you would need to convert all old tokens into new tokens before the old cryptography was compromised, which requires work - you would be generating new coins, and would have an exchange rate. Or you could setup a centralised validation service for coins as the article suggests, before the cryptography was broken, to ensure people aren't creating fake money.
I am not sure what you mean by accepting a bitcoin vs voting for a bitcoin, can you clarify? "Voting" doesn't look like a method they normally use for validation...
This is very similar to the way the US Treasury handles physical currency updates. If I recall correctly, in the 1990s, Iraq still had a working money press that could print perfectly legitimate US dollars as fast as possible. PC printer technology had also advanced to the point where $20s and $100s were easily counterfeited.
The US Treasury had to go through a transition period where new money with new security features were printed and the old money was taken out of circulation. I assume BTC will have to go through a similar digital verification.
The way this would work in theory is that old BTC will be converted to new BTC on a 1 to 1 basis, but first each old BTC will need to be validated against the blockchain. You could just say that any BTC with over 1,000 confirmations is valid, since it is highly unlikely that so many confirmations could be falsified.
Another way to convert from old-BTC to new-BTC would be to use the miners to validate each conversion. For example, if a sufficient number of miners verifies that yes, indeed a certain BTC appears in the blockchain, then that one is considered valid and is inserted into the new blockchain, and removed from the old blockchain. This algorithm could actually pay a new-BTC reward for validating old-BTC to the miners that validate each transaction, thus ensuring a sufficient amount of CPU power is dedicated to this process.
It is difficult to launder huge volumes of $20's and $100's.
It is trivial to launder huge volumes of forged Bitcoins; they are as liquid and convenient as real Bitcoins of any denomination.
Similarly, while you have to read interesting long-form journalism to learn about Iraq and North Korea counterfeiting operations, the whole world would know if either country could trivially forge Nasdaq transactions.
To clarify this some more, if the hashing algorithm is sufficiently broken, then I can doctor an arbitrary transaction of bitcoins to where-ever I want. If the old bitcoins are that insecure, they will necessarily become worthless.
I see- I agree this wouldn't work if there was a _catastrophic_ break in the crypto algorithm... My post assumes that if the algorithm is broken, it would mean that questionable bitcoins could be created at a higher-than-expected rate, but that there would be time for people to backstop it by updating their clients. I would think that a less catastrophic issue (leading to only an order-of-magnitude improvement in hash solutions) is more likely, but I suppose a fully catastrophic break is also possible.
The actual Achilles Heel of Bitcoin is the sparse few exchanges that convert Bitcoin to hard cash. If these exchanges can not control price manipulation schemes among their traders then Bitcoin's value will quickly bubble and pop. What Bitcoin needs is to be accepted by an established trading exchange which would stabilize the real world price of Bitcoins.
Bitcoin is an Achilles Centipede; that may be one of its many heels.
Another: is its conflation of efficient transaction medium and store of value, as if the simple "scarcity" of cryptographic random numbers would allow it to hold value once people decide it's no longer a competitive way to conduct business.
You see this in message board debates all the time, where bitcoin supporters, having been talked down from the notion that particularly idiosyncratic bit patterns in SHA256 hashes can ever have intrinsic value, resort to talking up bitcoin's utility as an cheap and anonymous Paypal; then, when confronted by bitcoin's manifest liabilities as a transaction media (for instance, the fact that it's so thinly traded that its price can jump double digit percentage points during the time it takes to clear a transaction), they revert back to the intrinsic value of mathematical scarcity compared to the oogie-boogie Federal Reserve.
Raise your hand if you like moon cakes. (To the down-voters: I wonder how many people managed to read to that segment of the article. I think the moon cake black market in China is independently interesting case of a currency with an expiration date.)
"It is literally impossible to “change” the hashing algorithm in Bitcoin; any change would constitute a change in the protocol, and thus result in a completely new currency."
This was something that came to my mind some time ago regarding Bitcoin, but I wasn't sure if it was possible, or at least practical. What's to stop other interested parties from changing the protocol/hash and creating myriad competing virtual currencies? Metacoin, Hashcash, Bitcoin++, Digidollars, Ameribits, Eurobits, Digigold, Ingots - you get the point.
"Hi, my name is Fred, and this is my currency."
We live in a world with a wide range of currencies and exchanges, so I suppose there could just as well be an exchange that supports as many digital currencies as could ever be conceived. But couldn't that also mean that Bitcoin could be devalued through confusion and obfuscation, its present reputation notwithstanding?
Traditionally, you offer a limited time where the old currency can be exchanged for the new currency, and after that date, anyone holding the old currency is shit-out-of-luck.
Note that the same scenario may apply (in some places) when new banknotes or coins are rolled out. Here in Norway, they periodically redesign the coins (and give them new sizes), and you have a certain amount of time to exchange your old ones before they are no longer considered legal tender.
You can have several competing specifications, recognizing the old BTC balance and offering a new balance in a new spec. People (who can be) separate from the spec proposers may implement clients that connect both to the Bitcoin network and the alternates. Eventually, one (or maybe more) new protocols win out and trade move to the stronger protocols. BTC would be left as legacy and eventual discontinuation.
The author also "risks" constructing strawmen and then proceeds happily to do so. I was wary at first, but once the speculation started flying the article lost credibility IMO. It's a neat trick but I was less than impressed.
What will happen to bitcoin with the hashing algorithm it uses becomes obsolete? Who knows. It may not be the only game in town at that point anyway.
"Who knows"? Deciding what may happen in the future is why people write papers. If there's a particular thing wrong with the paper then why not answer that?
Would it help if I linked to various Bitcoin forum posts where I found descriptions of these proposed transition plans? I don't have a very good feel for the reputability within the Bitcoin community, and I feel that simple technical reasons will limit the range of possible proposals.
At the risk of constructing strawmen, I would like to now present my perception of the two most popularly voiced plans.
At which point I was expecting to read an unbiased over view of the popular proposals from the community and perhaps some links to the discussion threads.
And after presenting the "decentralized" version and colouring it with an analogy to chinese black markets, you say:
Is this a transition? Yes. Is it disruptive? Definitely yes. It is certainly not what you want a currency you’re using for every day transactions to be doing.
Which essentially tells me you only presented the decentralized argument to me so that you could burn it down for all to see.
I won't go so far to argue whether your position is wrong.
As a reader I just felt the article to be another Internet soap box. Links would be nice and saving the speculation until the end would have helped, IMO.
The author doesn't appear to distinguish between a decentralised client and a decentralised specification.
The authors of the official Bitcoin client have de-facto control over the specification, so the design of the Bitcoin protocol is effectively centralised. I don't think anyone sees this as a problem, because if people start disagreeing they can always fork the protocol.
If a flaw is discovered in Bitcoin that requires a protocol change, I doubt we'll see any fragmentation. People fork projects over a wide range of reasons, but rarely over essential security patches.
This misrepresents the tight interlock between client and specification.
Suppose that there is a flaw discovered in Bitcoin that requires a protocol change. In a classic software system, the worst you'd have to worry about is a backwards incompatible protocol change; Bitcoin is designed with very little wriggle room in this respect. But furthermore, with Bitcoin, you have to worry about a change which existing Bitcoin clients will reject: for example, if you wanted to increase the reward given to miners.
You can fork the protocol, but you can't fork the economy. This is true in normal projects, and doubly true for Bitcoin.
I'm not sure I understand your point. Yes, in order for a Bitcoin fork to succeed, you'd have to convince the majority of clients to use the new protocol. However, once you gained a majority, the Bitcoins generated by the old protocol would fall in value relative to the Bitcoins generated with the new protocol. If your Bitcoins are worth $100 using the new protocol, but only $50 using the old protocol, there's a strong financial incentive to start using the new client so you can sell your bitcoins at a higher rate and to a larger audience.
Yes, it's centralised (to a degree), but when people talk about decentralised protocols, they usually mean that the protocol itself is decentralised. There's still usually an official or de-facto standard maintained by a relatively small group of people.
Your argument that Bitcoin is not decentralised could easily be applied to any P2P protocol. I don't think there's any P2P system around, except perhaps natural language, which has a decentralised specification.
In the United States, you cannot lawfully be paid a salary in "bitcoins". Nor can you negotiate a contract that claims that you're a contractor and not an employee if your role is substantially that of an employee (meaning: the entity paying you controls the means, scheduling, and financing of your work over a prolonged period).
You can of course enter into an arrangement with a company, do work for the company, receive "bitcoins" from the company, and both go on your merry way. But the company "paying" you has exposed itself to extreme liability with the IRS; it is probably on the hook not only for the employers half of dollar-denominated self-employment tax, but for the employee's half as well, plus penalties, interest, and legal fees.
There are at least two things in every employment case, and at least one additional thing in the company principal case, that will keep wages anchored to dollars no matter what form of unicorn dollar we come up with next:
* There is a dollar-denominated minimum wage
* There is dollar-denominated payroll tax and, for contractors, dollar-denominated self-employment tax that scales in dollar-denominated amounts whether you're paid in moon cakes or rare freshwater fish.
* And, if you're a company principal of a non-passthrough entity, there is an IRS requirement that you be paid a wage that corresponds to the fair market value of your role, and anything you do to not pay yourself a reasonable-looking dollar-denominated wage stands a good chance of getting you audited (this rule being one of the primary ways business owners attempt to avoid paying taxes).
It's only been fairly recently that the Department of Labor has issued opinions about foreign nationals being paid in foreign currency based on the current exchange rate available in the vicinity of the employer; that is, there are very specific cases in which you can pay someone both Euros and Dollars. Making geeky assumptions that, because some PHP program somewhere generates some number people call an "exchange rate" that means Bitcoins get you around the FLSA minimum wage... dubious and risky.
To answer my own post: I think everyone has misunderstood my point. Bitcoin valuation is unstable due to constant deflation (at best, you're only losing them to people dying or systems crashing or the basic fact that more and more actually valuable things are created, say a fusion engine, oh and the fact that as more and more people are born, you have fewer and fewer bitcoins spread amongst them). Given that the future is unknowable and it's unlikely that I'm going to submit to having my employer renegotiate my contract day to day, how am I going to be paid a salary in bitcoins?
To make it less about me also: How instead would you say to your employer (just accept this as part of the hypothetical question, you work for someone in a fundamentally permanent salaried employ), this is how I want my salary in bitcoins to be set. Or if you are completely incapable of imagining working for someone else, how would you frame a salaried employment for an employee in bitcoins?
The contractor (or employee) would negotiate the appropriate contract with the customer (or employer). Typically these days such contracts specify that all payments will be made in an instrument such as USD or EUR, but the contract could just as easily specify BTC.
Alternatively, the contract could specify that payments will be made in BTC, but the payment amount will depend on an exchange rate with some other instrument such as USD or EUR. In that case the customer is merely providing the exchange function as part of the contract.
The transaction can happen. I think the problem is in converting your bitcoins to USD or EUR since they are not used in real life.
A PayPal alternative for BitCoin (think CoinPal), will be a good start for non-geeks. However, the currency needs to have some stability so that people can trust it for their real money.
I'm not really sure what you mean. If company X allows customers to pay for goods/services with bitcoins then they would be able to pay the wages of their employees using the bitcoins.
In the UK I believe it's possible to agree a salary/payment at an amount of recognized currency, such as GBP or USD, and then you perform all your tax and related calculations based on that. How the payment is actually transferred is, potentially, up to the people involved.
I believe that I can contract my services at, say, 100 GBP per hour, bill for one hour, and then accept payment in bitcoin, stating that there is an agreed rate of exchange. If the stated underlying rates are not regarded as "unusual" by the HMRC then most likely the arrangement would be permitted to stand.
There are laws concerning "payment in kind" and I think this would fall under that. Note, I'm not an accountant or lawyer, but I've seen barter arrangements not dissimilar to this accepted as valid by HMRC.
In the US, you can arrange payment "in kind" for lodging, food, and "other facilities", but they are accounted for in dollar-denominated values and their fair market value can be determined by the government --- and likely will be, as fair-market value for in-kind compensation is a hotbutton issue for people who want to e.g. screw their housekeepers out of wages.
FLSA 3(m), also read the section in the FLSA handbook about "scrip" and "tokens" (which I understand bitcoin isn't --- scrip, which cannot lawfully be used as a wage substitute, only as an accounting mechanism for dollar-denominated wages) is at least backed by the full faith and credit of a company.
Couldn't the same argument be made of any protocol? Not all browser implement HTTP in the same way, IPv6 isn't compatible with IPv4, but all agree to switch, HTML is governed by a central body but a lot of the influence comes from the community.
