Hmm. You call it voluntary. But whatever the police said caused most businesses, schools, and government agencies to close. Except the donut shops, of course. Those, the police kept open.
You say they are not likely to do it again except in equally extreme situations. I say we rolled out the red carpet to the world's terrorists and foreign governments, showing what a panicky bunch of children we are. I say anyone with a violent agenda in the entire world is likely to do this again whenever they wish to send one or two armed men to our shores (or even recruit from the innumerable, mediocre candidates available domestically), and that will be at times of their choosing.
Namecoin (a distributed name system based on Bitcoin) had a problem a few years ago that demonstrated an example to this. Majority mining power just disappeared from the network, and it took miners months to produce 2016 blocks after that, ultimately rendering the network useless (until they found a way to mine both currencies in parallel with 100% efficiency on both, which is very interesting in itself).
I think I start to see what you mean. You're saying that I'd need to win against the rest of the internet's difficulty in order to make a valid block. And that no block is valid unless it follows the difficulty function, which is historically validated down the chain.
Interesting. I'd read about the difficulty heuristic but hadn't thoroughly understood it or realized the implications. In fact you have come up with an entirely new and fairly huge problem for bitcoin that I hadn't considered. Since the difficulty function is not real-time, bitcoin could suffer the same problem that namecoin suffered. It could, in fact, kill the entire thing far more acutely. All you need is a sufficient fluctuation in CPU volume. Right?
So you should be quite afraid of DoS attacks - but far more of changing market conditions. If something causes people to start to leave the network a little too quickly, and it slows down, causing a further exodus, then you have a runaway condition, and the entire thing is doomed for a "temporary" period long enough to kill it, effectively. No?
Bitcoin's fault tolerance is remotely similar to Freenet.
I think you can see my point about the ease of segmentation - and that it is irrelevant to the attack that the block chain can be reconstructed from a single leak, since there would be no leaks in a likely attack. And, agreed - quite academic in light of the issue you raise about faking blocks.
I don't think this conflicts with what I said. You need to break the chain of transactions in order to render the history useless.
Transactions are a chain. In the case of bitcoin, you have perfect and transparent recordkeeping of this chain as a precondition to the system working. Once a link is made, for any reason, you can never break it. You can have many wallets, but at scale you can't keep them separate. At any scale, you still need to have your various accounts exchanging funds sooner or later (and so will any laundry). You can try to create huge volumes of noise, break transactions and amounts up, and make many intermediate fake accounts, but none of those games are particularly resistant to analysis. Hence the example I linked to earlier.
We haven't even started to talk about the guts of P2P routing yet. From Freenet to Gnutella, the ideals of distributed computation never once met the realities. What happens when nodes in Bitcoin's mesh misbehave in different ways? Make too many connections? Route data in valid but esoteric ways? Spam bad data at neighbors, and blame it on other neighbors? And so forth...? The P2P substrate is actually a terribly difficult design problem that is usually inseparable from the higher-level goals of the network, and I've heard relatively little about how the protocol itself works.
I had a longer response that was just eaten by the browser. Now unfortunately I have to be brief:
You can't roll back transactions or double spend without producing blocks, and producing valid blocks don't get easier by isolating the victim from the network. If you agree that brute force attacks on proof of work isn't impractical, this isn't very viable either (i.e. people will realize there's something wrong when confirmation takes hours to days instead of minutes).
It has to be easier if you isolate someone from the network. Imagine if all the computers but yours disappeared tomorrow. Are you saying your computer could not now win a race of 1? Or that there is any difference between a communications cutoff and lack of existence?
I don't get what you mean here. Even if a little information is leaked between the segments, the network will be whole again. Of course you have to have a reasonable leak. For instance, you could send the data on a flash drive and I wouldn't consider it a valid leak because of the latency.
If I am intercepting your communications, it is less complex to intercept everything rather than some things. Confirmations will be quite speedy, since they will come from me as well.
For the rest, I would suggest reviewing the Anonymity page bitcoin themselves puts up.
The Weaknesses page puts it succinctly: "Tracing a coin's history can be used to connect identities to addresses."
Scammers and legitimate entrepreneurs make these same arguments, and try as hard as they can to sound the same. Of course if you worked a little at something and it seemed vaguely original to you, you are the lifeblood of capitalism and no amount of reward seems too much. If it went south later and screwed everyone downstream, who could have ever foreseen it? Just be careful your arguments would sound convincing to a jury when all the downstream people come calling.
As a side note I am quite sure the mining difficulty explosion was expected. The entire design expects it, and the papers explain this clearly. It's necessary for the system to work.
We actually are very hesitant for the law to protect people from their investment decisions, rightly so, and I think it would take our society quite a while to come up with any kind of response, let alone protections surrounding, these decentralized financial systems. I believe, don't get me wrong, that they have an important future. But in the meantime, buyer beware.
I think the Kaminsky analysis coupled the astoundingly rich rewards for early adopters - which dwarf most comparable things in the world of commerce (you could make what is now worth $90 at a very high rate with a cheap CPU, and they did this for many years before mining got tough), with the extremely poor chances faced by later adopters who arrive before the sell-offs, scandals, and centralization necessary for scale, to reach the "Ponzi-like properties" statement. I suspect the insider's horde, mined when the difficulty was low and the payoff was rich, is worth more today than $75m, or at least I should hope it would be, for their sake?
Put differently, if you can create a fake currency, convince enough people it's real for it to be worth something, and then dump your holdings of it before it all crashes down?
Yeah, that's shady, bordering on criminal. Of course, the people who lose their shirts are the sucker investors, who are supposed to be parted from their money if they're fools, but there are limits to that philosophy embodied in common law. If Bitcoin's creators and insiders falsely represented their system as part of the scheme, they could go to prison (and they have been careful not to, though mixed messages are an old scam long recognized in law, and you cannot be entirely covered by disclaimers about how experimental and likely to fail bitcoin is if you also say some less careful things too).
All that said, I imagine this was a well-intentioned experiment from the start, though I can't know. It's just one of the interesting risks you run, in that position.
Actually I replied to gox and have many concerns remaining at this point. He is making good arguments, though.
I think he's particularly off base on the anonymity issue.
If you can link to Bruce Schneier endorsing bitcoin's security, I would love to read it. You can't though, because he hasn't.
Kaminsky shredded it as well - links to his deck from 2011 are all over this discussion, but I can provide one if you like. In conclusion he said it had "Ponz-like properties" - though he refused to charge it as such directly, yet. His words, not mine.
Your comment about white hats turning black - I think you are suggesting that people who found flaws in bitcoin might keep them to themselves, and use them to profit rather than disclose them? I agree with you - though that rather cuts against bitcoin's credibility than for it.
Please keep in mind that convincing me isn't less difficult than convincing the whole network. You still need to produce hashes lower than the target, and even if I am only connected to you and perfectly believe you, every block you need to produce needs the same amount of work as the rest of the network.
I don't see how that follows yet. Rolling back transactions or double spending is more than enough to sink everything. I merely need to fool you for long enough to engage in another transaction - perhaps including converting the currency out of bitcoins. Bitcoin's own vulnerability FAQ (which openly discloses several fatal looking flaws I hadn't thought of besides this one) indicates segmentation is not a practical attack because "any leakage" will carry the whole network state. Which I don't understand at all - because in many scenarios it is more work to create segmentation with leakage than without?
The attack presumes I can control your communications with the rest of the world - indeed, for most internet users this is the status quo via several entities, such as their ISP and their repressive government (leaving aside the various other ways it can happen). A split sounds like a good term - splinter, probably more accurate. In such a case, the difficulty of the attack must be reducible, or how can the rest of the world, which we are not communicating with (for long enough for me to defraud you) still be a factor in the CPU spend for the attack? Shannon will wake from his grave to hear the explanation.
Once I have my stolen cash, I'm perfectly happy for the splinter to heal - in fact, I want it to, so I can steal from you again later.
Bitcoin is not anonymous
In discussions I am having here today, this is still news to others, I'm afraid. In fact I think it is hardly redundant. For instance, I would like to address your assertion that, If you wish to remain anonymous, trusted 3rd parties have any relevance.
First of all, the concept is enormously troubling on its face - enough so that no one seriously advising others about anonymity should speak of it. But let us say there are really 3rd parties you would like to trust, and you have a desire to perform anonymous transactions.
I think we need to make it clear what we are talking about here: Bitcoin is the least anonymous, most transparent currency ever invented. Nothing else in existence is more law-enforcement-friendly.
Your trusted third party scenario is my dream if I am an FBI agent. As an intermediary for someone else, you buy something with account Y. Associating your real identity with your cryptographic identity is policework - let us admit that it can and will be done. From there on out I can see every transaction you have ever made with Y. You may make multiple identities - so much the better. With surveillance of your net connection (which even in the US I can do without a warrant) I will learn any identity you use to conduct business. That's leaving aside that, soon, wallet Y will be empty and wallet X will be full. What will you do then? It is impossible to indefinitely segment your payables from your receivables, for reasons found in elementary accounting.
You have all the same problems as a traditional money launderer and many new ones that no money launderer has ever had before.
Anyone who wishes to perform anonymous transactions (the right of every hard cash holder since the invention of money) should run screaming from Bitcoin.
Because the transaction data you need isn't in the chain.
If I cannot tell who owns what, then I can double-spend. If I can tell, then I can see transaction data. No amount of complex dressing can hide this simple wound.
In fact the chain is exactly the transaction data I need, unless I have totally misunderstood the chain, and so did the many security researchers that have been creating transaction graphs from it, i.e. http://eprint.iacr.org/2012/584
I do not buy that there has been adequate review of the system - at least, that is not what I see when I look at the public discussion.
A billion-dollar bounty? Who will pay me a billion dollars? I would like a link on that specious claim, please. Do you imagine anyone could recoup the capitalization of an entire market by finding a flaw in the market?
I agree brute force attacks would be impractical - this is really what the entire design preoccupies itself with.
If I had to guess, it would be the use of communication interrupts and/or denial of service attacks, or man-in-the-middle attacks (more practical for a high-tech police state like China), to dramatically reduce the computational power needed to mount an attack. For instance, I can steal your coins if I can convince you of an incorrect chain being the longest. It is not necessary for me to keep up with the world's CPU power - merely to prevent you (and enough others) from accurately seeing the world at the right times. Then I have created splits which would be quite disruptive. As the network scales, so would the disruption. When enough people are losing their money, the lack of confidence spreads like a virus, and that is how you destroy a currency/bank/nation/etc.
This simple "communication starvation" attack seems elementary and effective to me that I feel like I must be missing something. But what? I don't buy the "paranoia" argument - that it hasn't happened yet is simply because a state or network-level actor hasn't yet gotten involved. Were the system to succeed, such involvement seems inevitable to me. Prior to the dramatic success of bitcoin (which perhaps we are on track for?), the lack of such problems also makes sense.
Regarding anonymity, I'm afraid I don't follow how this currency isn't an NSA/FBI wet dream yet. Even the traditional banking system is not this transparent. If I can prevent double-spending, I can see what you did with your bitcoins, regardless of how many addresses you use. If I can hide my identity by changing addresses, then money can magically move from one identity to another without a transaction, and I can double-spend. How could it be possible for it to be any other way? And since the chain must necessarily be public, the entire world must (or at least should) have the same information - about every transaction.
If tumblers can launder money, all they can do is take on criminal liability in this highly transparent system - so it is unclear why anyone would want to be a tumbler in that world, but perhaps you can argue that people will host them in "areas with poor law enforcement." However, if double-spending prevention is successful, and there is a clear transaction chain, why it is not entirely straightforward (if merely computationally intensive) to unravel all tumbling activity using the chain? That would make tumblers a dangerous bit of theater.
I'm saying every transaction in the network is likely completely transparent, and no games with tumblers and one-time addresses will help you. I'm saying it is likely the NSA and FBI's wet dream for people to use this currency. Even the banking system is less transparent.
I don't believe you. If I can prevent double-spending, I can see what you did with your bitcoins, regardless of how many addresses you use. If I can hide my identity by changing addresses, then money can magically move from one identity to another without a transaction, and I can double-spend.
If tumblers can launder money, all they can do is take on criminal liability in this highly transparent system. Even so it is likely possible to unravel the entire tumble using the chain.
...and, by the way, the argument about bubbles holds for currencies, stocks, bonds, commodities, real property, or anything you can exchange. So saying "it isn't stock" misses the point being made.
The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes, or so it is hoped. But pervasive communications are also assumed so that chain length can be measured, for the CPU-power argument to be possible to begin with. Consider how many key elements in the protocol require extensive communication, for instance to determine chain length. Between botnets, transparent proxies, ASICs, domestic and foreign powers with extensive eavesdropping, intercept, and computational resources... who by the way might be rather put out at having their currencies threatened... do you really want to trust any hard earned cash to this system? Or... if it is easy to make or get bitcoins without hard work, how much can they really be worth?
Meanwhile, is it anonymous, or has this massively transparent electronic P2P currency been designed to keep a particularly difficult to erase record of every transaction completed with it? From the paper:
Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.
...aaaaaaand, the section ends. So good luck, silk-road purchasers.
I have some experience with both cryptography and decentralized systems of this kind. Which doesn't make me an expert. But I know enough to ask questions. I have had grave concerns about the validity of their design since I first read about it on slashdot some years back. It seemed to me the case had not been made that bitcoin was not vulnerable to rapid destruction of value, due to attacks on fundamental flaws in its design.
The thing that really surprised me was that people decided to try to use it anyway. But I guess our desires often cloud our judgment. As much as I would love a decentralized digital currency, I do not believe it yet exists. I wouldn't invest 90 cents in bitcoin.
Many currencies can appear to be stable until they're not.
I don't agree that you should get legalistic about what is and isn't in your contract. If you're writing software, answering questions about it and helping others understand it is part of the basic standards and practices of the profession. If you're a contractor, training up internal resources to take over your project is totally ordinary.
They've been a client for years. Take good care of them. If they want to move the role full-time, in-house, that's a good growth step for them.
If you're the kind of contractor who's hostile to that, and looking for ways to resist and debating what's in your contract, or being unprofessional when it comes to transitioning your role, expect not to be welcomed back, and don't look for them to give a glowing reference.
If you act like a pro, and take good care of them, then you're helping your reputation and chances for future work.
Re:Review Ruby for the perl enthusiast please
on
Ruby 2.0.0 Released
·
· Score: 1
"Data safety" has nothing to do with "easy".
It can be interpreted that way, because eliminating the GIL and allowing threading makes it "hard" for your data to be "safe" from races.
The idea of making MRI even slower is hilarious. But I'm sure you could do it by introducing even more locking behavior. Ditching MRI for one of the other, newer RVMs sounds like a fine idea.:)
Re:Review Ruby for the perl enthusiast please
on
Ruby 2.0.0 Released
·
· Score: 1
Could be.
I did heard it directly from a pretty credible source, someone famous in the Ruby community that I will not embarrass by drawing into this thread, so feel free to say, from no one. Is it written anywhere? I haven't found it in 30 seconds, so I give up.:) What I did find was implication:
"Data safety" - meaning, Ruby is not a threading language, threading is hard, leave it to something else to do something that hard, while Ruby stays "safe" and "easy." In other words, we have a GIL because it's good to have a GIL. Which tells you all you need to know about what it will be like to scale a language written by this person. Then of course there's all the discussions about how hard it would be to remove - and removing it without a rewrite is certainly hard, I am sure.
Re:Review Ruby for the perl enthusiast please
on
Ruby 2.0.0 Released
·
· Score: 1
Let's see. What did I say?
Although some very clever Ruby runtime implementers have come along to pick up the slack left by the language's founder (who still pretends the global interpreter lock is a virtue, or so I am told)...
In other words, Ruby's scalability concerns come from a designer with so little care for performance as to sell the GIL as a virtue - scarcely any smarter than this Anonymous Coward.:) By now others have written superior Ruby interpreters, in part because of how bad Matz's is. To this exact point, I linked to a blog post, by the author of JRuby, a Ruby environment which incidentally has no GIL, discussing many serious performance challenges which can never be easily addressed, because they are tied to fundamental language design decisions.
The reason we are still discussing the GIL at all - a solved problem for both Python and Ruby if you are willing to switch runtimes from the "default" - is that initially we heard "If you think scaling can only be done with threads..." - which... just listen to yourself, man.
Do I make any specific recommendation the reader use Python? Not only not, but I am actually not even suggesting avoiding Ruby - merely saying, check it out for yourself, and see it not as some mediocre hack's jealously guarded fetish, but objectively, in the context of other languages. I think "you are unlikely to experience much net gain" vs. Perl or Python, but YMMV. On some projects you actually know scale will never be an issue.
Seen objectively, Ruby has many interesting features, but many are present in other languages. It has some serious problems, some of which are tied inherently to these very features (and therefore cut across languages), but others which are unique to Ruby. Python's problems are a whole separate conversation - not just its own distinct performance issues (at least attacked more vigorously, for longer, and by a larger community), but getting bitten by tabs vs. spaces?:)
Alas, the AC will have to work a bit harder to know his tools and follow the conversation.:)
Re:Review Ruby for the perl enthusiast please
on
Ruby 2.0.0 Released
·
· Score: 2
I cited a comprehensive survey. You just talked about github. Yes, a particular open-source repository (Github) is popular among Ruby developers. The fact that you confuse this with language popularity is another hint about your critical thinking skills.
There is indeed economic merit in choosing developer productivity over runtime performance. However, there is no need to choose one or the other. Many other languages exist that are fine competitors to Ruby in terms of developer productivity, and most will not run as slowly. If you ignore them, your career will suffer.
I have invested many years in Ruby at this point, and I hope you can see that I am not unaware of its benefits. This is how I came to be in the position to scale Ruby applications, though of course, rather than have the droll exercise of being blindly accused of being "bad at it," I will refer you to the innumerable published experiences of famous Ruby developers who had to abandon the language due to scale issues. For theory, I will refer you to the excellent work of Charles Nutter, author of JRuby, currently among the best performing Ruby VMs, and far beyond Matz's work.
I have backed up every statement I've made, though if you feel that having a global interpreter lock is some kind of virtue, and does not reduce the scalability case of your language, you are stating something so extraordinary and beyond the pale of any conventional wisdom or common sense, it is upon you to prove it - to the astonishment of all, I assure you.
If you are getting by with forks and multi-tiered archtectures and high-open file limits and Passenger, I salute you. But if you really are this insecure and uninformed about Ruby, I suggest you learn another language - Groovy perhaps, or Python - or push yourself and learn Objective C or C++. Alternately, consider work on addressing the flaws in Ruby - your help is certainly needed, and you might give your beloved platform better hope for the future.
Re:Review Ruby for the perl enthusiast please
on
Ruby 2.0.0 Released
·
· Score: 3, Insightful
Or just don't worry about flattering the ego of people so insecure and unskilled that they require you to pretend that Ruby is a widely used, mature, stable language.
You want the advice of someone who learns languages effortlessly, and therefore has no insecurity about anyone else's preferences or prejudices. Anyone who needs you to "control your tone" about a language "because it puts food on their children's table" - I fear for those children. And for anyone who gets advice from their parents, who apparently had to struggle a bit too much to pull themselves up to that competency and, fearing criticism of their precious, hard-won skill, give the impression of hanging on by their fingernails.
Ruby is indeed still at risk of being described as a toy language, and it is not nearly as commonly used as, say Perl, Python, Visual Basic, or even C#, let alone Objective C, C/C++ or Java, (as evidenced here)...and the community is similarly small. Witness the hilarity around the recent Rubygems compromise to see the price of small size and lack of maturity. The language is still young, and messily and poorly specified, relying on a horrifyingly slow, rats-nest reference implementation for its definition, rather than a comprehensive design.
There is great cleverness in Ruby. It represents a ruthless preference for developer productivity over performance. An interesting experiment, but unfortunately it was done "by feel" rather than with any hard data about speed or defect rates given different design decisions. So, while some things about it are wonderful, other things only appear to be wonderful. On the whole you are unlikely to experience much net gain over Perl or Python, though you may enjoy the novelty of it. It's a fun language. By all means, try, and see for yourself. Just beware that you foreclose the ability to scale your work easily if you use Ruby.
Although some very clever Ruby runtime implementers have come along to pick up the slack left by the language's founder (who still pretends the global interpreter lock is a virtue, or so I am told), many language features cause meaningful and irretrievable performance impacts that will never be ameliorated by runtime magic. It doesn't matter for many applications, but just something to keep in mind.
Slashdot Mirror
They let an armed suspect escape in a car, in an urban area.
When was the last time you ever heard of someone making a successful getaway, in a car, from an urban police force?
Hmm. You call it voluntary. But whatever the police said caused most businesses, schools, and government agencies to close. Except the donut shops, of course. Those, the police kept open.
http://www.popehat.com/2013/04/20/security-theater-martial-law-and-a-tale-that-trumps-every-cop-and-donut-joke-youve-ever-heard/
You say they are not likely to do it again except in equally extreme situations. I say we rolled out the red carpet to the world's terrorists and foreign governments, showing what a panicky bunch of children we are. I say anyone with a violent agenda in the entire world is likely to do this again whenever they wish to send one or two armed men to our shores (or even recruit from the innumerable, mediocre candidates available domestically), and that will be at times of their choosing.
Namecoin (a distributed name system based on Bitcoin) had a problem a few years ago that demonstrated an example to this. Majority mining power just disappeared from the network, and it took miners months to produce 2016 blocks after that, ultimately rendering the network useless (until they found a way to mine both currencies in parallel with 100% efficiency on both, which is very interesting in itself).
I think I start to see what you mean. You're saying that I'd need to win against the rest of the internet's difficulty in order to make a valid block. And that no block is valid unless it follows the difficulty function, which is historically validated down the chain.
Interesting. I'd read about the difficulty heuristic but hadn't thoroughly understood it or realized the implications. In fact you have come up with an entirely new and fairly huge problem for bitcoin that I hadn't considered. Since the difficulty function is not real-time, bitcoin could suffer the same problem that namecoin suffered. It could, in fact, kill the entire thing far more acutely. All you need is a sufficient fluctuation in CPU volume. Right?
So you should be quite afraid of DoS attacks - but far more of changing market conditions. If something causes people to start to leave the network a little too quickly, and it slows down, causing a further exodus, then you have a runaway condition, and the entire thing is doomed for a "temporary" period long enough to kill it, effectively. No?
Bitcoin's fault tolerance is remotely similar to Freenet.
I think you can see my point about the ease of segmentation - and that it is irrelevant to the attack that the block chain can be reconstructed from a single leak, since there would be no leaks in a likely attack. And, agreed - quite academic in light of the issue you raise about faking blocks.
I don't think this conflicts with what I said. You need to break the chain of transactions in order to render the history useless.
Transactions are a chain. In the case of bitcoin, you have perfect and transparent recordkeeping of this chain as a precondition to the system working. Once a link is made, for any reason, you can never break it. You can have many wallets, but at scale you can't keep them separate. At any scale, you still need to have your various accounts exchanging funds sooner or later (and so will any laundry). You can try to create huge volumes of noise, break transactions and amounts up, and make many intermediate fake accounts, but none of those games are particularly resistant to analysis. Hence the example I linked to earlier.
We haven't even started to talk about the guts of P2P routing yet. From Freenet to Gnutella, the ideals of distributed computation never once met the realities. What happens when nodes in Bitcoin's mesh misbehave in different ways? Make too many connections? Route data in valid but esoteric ways? Spam bad data at neighbors, and blame it on other neighbors? And so forth...? The P2P substrate is actually a terribly difficult design problem that is usually inseparable from the higher-level goals of the network, and I've heard relatively little about how the protocol itself works.
Here's the main thread: http://slashdot.org/comments.pl?sid=3595715&cid=43313163
I had a longer response that was just eaten by the browser. Now unfortunately I have to be brief:
You can't roll back transactions or double spend without producing blocks, and producing valid blocks don't get easier by isolating the victim from the network. If you agree that brute force attacks on proof of work isn't impractical, this isn't very viable either (i.e. people will realize there's something wrong when confirmation takes hours to days instead of minutes).
It has to be easier if you isolate someone from the network. Imagine if all the computers but yours disappeared tomorrow. Are you saying your computer could not now win a race of 1? Or that there is any difference between a communications cutoff and lack of existence?
I don't get what you mean here. Even if a little information is leaked between the segments, the network will be whole again. Of course you have to have a reasonable leak. For instance, you could send the data on a flash drive and I wouldn't consider it a valid leak because of the latency.
If I am intercepting your communications, it is less complex to intercept everything rather than some things. Confirmations will be quite speedy, since they will come from me as well.
For the rest, I would suggest reviewing the Anonymity page bitcoin themselves puts up.
The Weaknesses page puts it succinctly: "Tracing a coin's history can be used to connect identities to addresses."
Here's Kaminsky: http://www.slideshare.net/dakami/bitcoin-8776098
Scammers and legitimate entrepreneurs make these same arguments, and try as hard as they can to sound the same. Of course if you worked a little at something and it seemed vaguely original to you, you are the lifeblood of capitalism and no amount of reward seems too much. If it went south later and screwed everyone downstream, who could have ever foreseen it? Just be careful your arguments would sound convincing to a jury when all the downstream people come calling.
As a side note I am quite sure the mining difficulty explosion was expected. The entire design expects it, and the papers explain this clearly. It's necessary for the system to work.
We actually are very hesitant for the law to protect people from their investment decisions, rightly so, and I think it would take our society quite a while to come up with any kind of response, let alone protections surrounding, these decentralized financial systems. I believe, don't get me wrong, that they have an important future. But in the meantime, buyer beware.
I think the Kaminsky analysis coupled the astoundingly rich rewards for early adopters - which dwarf most comparable things in the world of commerce (you could make what is now worth $90 at a very high rate with a cheap CPU, and they did this for many years before mining got tough), with the extremely poor chances faced by later adopters who arrive before the sell-offs, scandals, and centralization necessary for scale, to reach the "Ponzi-like properties" statement. I suspect the insider's horde, mined when the difficulty was low and the payoff was rich, is worth more today than $75m, or at least I should hope it would be, for their sake?
Put differently, if you can create a fake currency, convince enough people it's real for it to be worth something, and then dump your holdings of it before it all crashes down?
Yeah, that's shady, bordering on criminal. Of course, the people who lose their shirts are the sucker investors, who are supposed to be parted from their money if they're fools, but there are limits to that philosophy embodied in common law. If Bitcoin's creators and insiders falsely represented their system as part of the scheme, they could go to prison (and they have been careful not to, though mixed messages are an old scam long recognized in law, and you cannot be entirely covered by disclaimers about how experimental and likely to fail bitcoin is if you also say some less careful things too).
All that said, I imagine this was a well-intentioned experiment from the start, though I can't know. It's just one of the interesting risks you run, in that position.
Actually I replied to gox and have many concerns remaining at this point. He is making good arguments, though.
I think he's particularly off base on the anonymity issue.
If you can link to Bruce Schneier endorsing bitcoin's security, I would love to read it. You can't though, because he hasn't.
Kaminsky shredded it as well - links to his deck from 2011 are all over this discussion, but I can provide one if you like. In conclusion he said it had "Ponz-like properties" - though he refused to charge it as such directly, yet. His words, not mine.
Your comment about white hats turning black - I think you are suggesting that people who found flaws in bitcoin might keep them to themselves, and use them to profit rather than disclose them? I agree with you - though that rather cuts against bitcoin's credibility than for it.
Please keep in mind that convincing me isn't less difficult than convincing the whole network. You still need to produce hashes lower than the target, and even if I am only connected to you and perfectly believe you, every block you need to produce needs the same amount of work as the rest of the network.
I don't see how that follows yet. Rolling back transactions or double spending is more than enough to sink everything. I merely need to fool you for long enough to engage in another transaction - perhaps including converting the currency out of bitcoins. Bitcoin's own vulnerability FAQ (which openly discloses several fatal looking flaws I hadn't thought of besides this one) indicates segmentation is not a practical attack because "any leakage" will carry the whole network state. Which I don't understand at all - because in many scenarios it is more work to create segmentation with leakage than without?
The attack presumes I can control your communications with the rest of the world - indeed, for most internet users this is the status quo via several entities, such as their ISP and their repressive government (leaving aside the various other ways it can happen). A split sounds like a good term - splinter, probably more accurate. In such a case, the difficulty of the attack must be reducible, or how can the rest of the world, which we are not communicating with (for long enough for me to defraud you) still be a factor in the CPU spend for the attack? Shannon will wake from his grave to hear the explanation.
Once I have my stolen cash, I'm perfectly happy for the splinter to heal - in fact, I want it to, so I can steal from you again later.
Bitcoin is not anonymous
In discussions I am having here today, this is still news to others, I'm afraid. In fact I think it is hardly redundant. For instance, I would like to address your assertion that, If you wish to remain anonymous, trusted 3rd parties have any relevance.
First of all, the concept is enormously troubling on its face - enough so that no one seriously advising others about anonymity should speak of it. But let us say there are really 3rd parties you would like to trust, and you have a desire to perform anonymous transactions.
I think we need to make it clear what we are talking about here: Bitcoin is the least anonymous, most transparent currency ever invented. Nothing else in existence is more law-enforcement-friendly.
Your trusted third party scenario is my dream if I am an FBI agent. As an intermediary for someone else, you buy something with account Y. Associating your real identity with your cryptographic identity is policework - let us admit that it can and will be done. From there on out I can see every transaction you have ever made with Y. You may make multiple identities - so much the better. With surveillance of your net connection (which even in the US I can do without a warrant) I will learn any identity you use to conduct business. That's leaving aside that, soon, wallet Y will be empty and wallet X will be full. What will you do then? It is impossible to indefinitely segment your payables from your receivables, for reasons found in elementary accounting.
You have all the same problems as a traditional money launderer and many new ones that no money launderer has ever had before.
Anyone who wishes to perform anonymous transactions (the right of every hard cash holder since the invention of money) should run screaming from Bitcoin.
Because the transaction data you need isn't in the chain.
If I cannot tell who owns what, then I can double-spend. If I can tell, then I can see transaction data. No amount of complex dressing can hide this simple wound.
In fact the chain is exactly the transaction data I need, unless I have totally misunderstood the chain, and so did the many security researchers that have been creating transaction graphs from it, i.e. http://eprint.iacr.org/2012/584
I do not buy that there has been adequate review of the system - at least, that is not what I see when I look at the public discussion.
A billion-dollar bounty? Who will pay me a billion dollars? I would like a link on that specious claim, please. Do you imagine anyone could recoup the capitalization of an entire market by finding a flaw in the market?
I'll point at my more specific concerns here:
http://slashdot.org/comments.pl?sid=3595715&cid=43317603
I don't think the lack-of-inflation argument is bitcoin's problem.
I agree brute force attacks would be impractical - this is really what the entire design preoccupies itself with.
If I had to guess, it would be the use of communication interrupts and/or denial of service attacks, or man-in-the-middle attacks (more practical for a high-tech police state like China), to dramatically reduce the computational power needed to mount an attack. For instance, I can steal your coins if I can convince you of an incorrect chain being the longest. It is not necessary for me to keep up with the world's CPU power - merely to prevent you (and enough others) from accurately seeing the world at the right times. Then I have created splits which would be quite disruptive. As the network scales, so would the disruption. When enough people are losing their money, the lack of confidence spreads like a virus, and that is how you destroy a currency/bank/nation/etc.
This simple "communication starvation" attack seems elementary and effective to me that I feel like I must be missing something. But what? I don't buy the "paranoia" argument - that it hasn't happened yet is simply because a state or network-level actor hasn't yet gotten involved. Were the system to succeed, such involvement seems inevitable to me. Prior to the dramatic success of bitcoin (which perhaps we are on track for?), the lack of such problems also makes sense.
Regarding anonymity, I'm afraid I don't follow how this currency isn't an NSA/FBI wet dream yet. Even the traditional banking system is not this transparent. If I can prevent double-spending, I can see what you did with your bitcoins, regardless of how many addresses you use. If I can hide my identity by changing addresses, then money can magically move from one identity to another without a transaction, and I can double-spend. How could it be possible for it to be any other way? And since the chain must necessarily be public, the entire world must (or at least should) have the same information - about every transaction.
If tumblers can launder money, all they can do is take on criminal liability in this highly transparent system - so it is unclear why anyone would want to be a tumbler in that world, but perhaps you can argue that people will host them in "areas with poor law enforcement." However, if double-spending prevention is successful, and there is a clear transaction chain, why it is not entirely straightforward (if merely computationally intensive) to unravel all tumbling activity using the chain? That would make tumblers a dangerous bit of theater.
I'm saying every transaction in the network is likely completely transparent, and no games with tumblers and one-time addresses will help you. I'm saying it is likely the NSA and FBI's wet dream for people to use this currency. Even the banking system is less transparent.
I don't believe you. If I can prevent double-spending, I can see what you did with your bitcoins, regardless of how many addresses you use. If I can hide my identity by changing addresses, then money can magically move from one identity to another without a transaction, and I can double-spend.
If tumblers can launder money, all they can do is take on criminal liability in this highly transparent system. Even so it is likely possible to unravel the entire tumble using the chain.
http://news.slashdot.org/comments.pl?sid=3595715&cid=43313163
What makes you think people who learn about flaws usually publish them?
Only a minority of people who learn about security exploits in software publish. And those aren't as direct an equivalent to cash.
...and, by the way, the argument about bubbles holds for currencies, stocks, bonds, commodities, real property, or anything you can exchange. So saying "it isn't stock" misses the point being made.
I read the Nakamoto paper. Here are my concerns.
The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes, or so it is hoped. But pervasive communications are also assumed so that chain length can be measured, for the CPU-power argument to be possible to begin with. Consider how many key elements in the protocol require extensive communication, for instance to determine chain length. Between botnets, transparent proxies, ASICs, domestic and foreign powers with extensive eavesdropping, intercept, and computational resources... who by the way might be rather put out at having their currencies threatened... do you really want to trust any hard earned cash to this system? Or... if it is easy to make or get bitcoins without hard work, how much can they really be worth?
Meanwhile, is it anonymous, or has this massively transparent electronic P2P currency been designed to keep a particularly difficult to erase record of every transaction completed with it? From the paper:
Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.
...aaaaaaand, the section ends. So good luck, silk-road purchasers.
Enron's stock went up too. You might want to think about the fundamentals of what you're buying.
I have some experience with both cryptography and decentralized systems of this kind. Which doesn't make me an expert. But I know enough to ask questions. I have had grave concerns about the validity of their design since I first read about it on slashdot some years back. It seemed to me the case had not been made that bitcoin was not vulnerable to rapid destruction of value, due to attacks on fundamental flaws in its design.
The thing that really surprised me was that people decided to try to use it anyway. But I guess our desires often cloud our judgment. As much as I would love a decentralized digital currency, I do not believe it yet exists. I wouldn't invest 90 cents in bitcoin.
Many currencies can appear to be stable until they're not.
I don't agree that you should get legalistic about what is and isn't in your contract. If you're writing software, answering questions about it and helping others understand it is part of the basic standards and practices of the profession. If you're a contractor, training up internal resources to take over your project is totally ordinary.
They've been a client for years. Take good care of them. If they want to move the role full-time, in-house, that's a good growth step for them.
If you're the kind of contractor who's hostile to that, and looking for ways to resist and debating what's in your contract, or being unprofessional when it comes to transitioning your role, expect not to be welcomed back, and don't look for them to give a glowing reference.
If you act like a pro, and take good care of them, then you're helping your reputation and chances for future work.
"Data safety" has nothing to do with "easy".
It can be interpreted that way, because eliminating the GIL and allowing threading makes it "hard" for your data to be "safe" from races.
The idea of making MRI even slower is hilarious. But I'm sure you could do it by introducing even more locking behavior. Ditching MRI for one of the other, newer RVMs sounds like a fine idea. :)
Could be.
I did heard it directly from a pretty credible source, someone famous in the Ruby community that I will not embarrass by drawing into this thread, so feel free to say, from no one. Is it written anywhere? I haven't found it in 30 seconds, so I give up. :) What I did find was implication:
http://merbist.com/2011/10/03/about-concurrency-and-the-gil/
http://tonyarcieri.com/2012-the-year-rubyists-learned-to-stop-worrying-and-love-the-threads
"Data safety" - meaning, Ruby is not a threading language, threading is hard, leave it to something else to do something that hard, while Ruby stays "safe" and "easy." In other words, we have a GIL because it's good to have a GIL. Which tells you all you need to know about what it will be like to scale a language written by this person. Then of course there's all the discussions about how hard it would be to remove - and removing it without a rewrite is certainly hard, I am sure.
Let's see. What did I say?
Although some very clever Ruby runtime implementers have come along to pick up the slack left by the language's founder (who still pretends the global interpreter lock is a virtue, or so I am told)...
In other words, Ruby's scalability concerns come from a designer with so little care for performance as to sell the GIL as a virtue - scarcely any smarter than this Anonymous Coward. :) By now others have written superior Ruby interpreters, in part because of how bad Matz's is. To this exact point, I linked to a blog post, by the author of JRuby, a Ruby environment which incidentally has no GIL, discussing many serious performance challenges which can never be easily addressed, because they are tied to fundamental language design decisions.
The reason we are still discussing the GIL at all - a solved problem for both Python and Ruby if you are willing to switch runtimes from the "default" - is that initially we heard "If you think scaling can only be done with threads..." - which... just listen to yourself, man.
Do I make any specific recommendation the reader use Python? Not only not, but I am actually not even suggesting avoiding Ruby - merely saying, check it out for yourself, and see it not as some mediocre hack's jealously guarded fetish, but objectively, in the context of other languages. I think "you are unlikely to experience much net gain" vs. Perl or Python, but YMMV. On some projects you actually know scale will never be an issue.
Seen objectively, Ruby has many interesting features, but many are present in other languages. It has some serious problems, some of which are tied inherently to these very features (and therefore cut across languages), but others which are unique to Ruby. Python's problems are a whole separate conversation - not just its own distinct performance issues (at least attacked more vigorously, for longer, and by a larger community), but getting bitten by tabs vs. spaces? :)
Alas, the AC will have to work a bit harder to know his tools and follow the conversation. :)
I cited a comprehensive survey. You just talked about github. Yes, a particular open-source repository (Github) is popular among Ruby developers. The fact that you confuse this with language popularity is another hint about your critical thinking skills.
There is indeed economic merit in choosing developer productivity over runtime performance. However, there is no need to choose one or the other. Many other languages exist that are fine competitors to Ruby in terms of developer productivity, and most will not run as slowly. If you ignore them, your career will suffer.
I have invested many years in Ruby at this point, and I hope you can see that I am not unaware of its benefits. This is how I came to be in the position to scale Ruby applications, though of course, rather than have the droll exercise of being blindly accused of being "bad at it," I will refer you to the innumerable published experiences of famous Ruby developers who had to abandon the language due to scale issues. For theory, I will refer you to the excellent work of Charles Nutter, author of JRuby, currently among the best performing Ruby VMs, and far beyond Matz's work.
I have backed up every statement I've made, though if you feel that having a global interpreter lock is some kind of virtue, and does not reduce the scalability case of your language, you are stating something so extraordinary and beyond the pale of any conventional wisdom or common sense, it is upon you to prove it - to the astonishment of all, I assure you.
If you are getting by with forks and multi-tiered archtectures and high-open file limits and Passenger, I salute you. But if you really are this insecure and uninformed about Ruby, I suggest you learn another language - Groovy perhaps, or Python - or push yourself and learn Objective C or C++. Alternately, consider work on addressing the flaws in Ruby - your help is certainly needed, and you might give your beloved platform better hope for the future.
Or just don't worry about flattering the ego of people so insecure and unskilled that they require you to pretend that Ruby is a widely used, mature, stable language.
You want the advice of someone who learns languages effortlessly, and therefore has no insecurity about anyone else's preferences or prejudices. Anyone who needs you to "control your tone" about a language "because it puts food on their children's table" - I fear for those children. And for anyone who gets advice from their parents, who apparently had to struggle a bit too much to pull themselves up to that competency and, fearing criticism of their precious, hard-won skill, give the impression of hanging on by their fingernails.
Ruby is indeed still at risk of being described as a toy language, and it is not nearly as commonly used as, say Perl, Python, Visual Basic, or even C#, let alone Objective C, C/C++ or Java, (as evidenced here) ...and the community is similarly small. Witness the hilarity around the recent Rubygems compromise to see the price of small size and lack of maturity. The language is still young, and messily and poorly specified, relying on a horrifyingly slow, rats-nest reference implementation for its definition, rather than a comprehensive design.
There is great cleverness in Ruby. It represents a ruthless preference for developer productivity over performance. An interesting experiment, but unfortunately it was done "by feel" rather than with any hard data about speed or defect rates given different design decisions. So, while some things about it are wonderful, other things only appear to be wonderful. On the whole you are unlikely to experience much net gain over Perl or Python, though you may enjoy the novelty of it. It's a fun language. By all means, try, and see for yourself. Just beware that you foreclose the ability to scale your work easily if you use Ruby.
Although some very clever Ruby runtime implementers have come along to pick up the slack left by the language's founder (who still pretends the global interpreter lock is a virtue, or so I am told), many language features cause meaningful and irretrievable performance impacts that will never be ameliorated by runtime magic. It doesn't matter for many applications, but just something to keep in mind.