As an expert you should be aware that security and reliability is not the same thing. Also, if you look at the full table, the bottom two providers with a lot higher outage than everybody else run FreeBSD. If you calculate an average, FreeBSD will be much worse than the other solutions. Basically you can pretty much get any result you want from this list.
Reliability in strongly connected to Security. If you need to patch, reboot, or manage an intrusion then your reliability goes down. It also means that there is less security maintenance (even though freebsd update process is more obscure). The table show us that if you want to be the most reliable, you need to choose unix. Or you can count privilege escalation: 61 bugs in the last 7 years for linux, 3 for freebsd. Or you can count vulnerabilities, even thought being freebsd smaller, this is a biased comparison. Or you can do very rough estimation: Google "Hacked by"+ linux: 2.3 millions results Google "Hacked by"+ Freebsd: 230.000 results (one fold less!!!) Anyhow let's put this way: My opinion is that FreeBSD is the most secure, reliable and scalable OS. You think that Linux is more secure than FreeBSD. Got a makefile for your *BSD bitcoind build you'd like to share? Would help the community with more/different OS builds out there. |
|
|
|
It is wildly obvious that there was no single guy with a cool half million coins in his account.
It wasn't long ago that everyone was gawping at some 425k coins being moved, presumably offline by the MtGox lot. Then there are 50,000 users they have picked up in the last month. (I was about 11,000 and I signed up on June 1st, there are 60,000 odd on the list now!). They offline most of their funds and just keep a float, hence the maximum withdrawal limit.
All the coins that people see trading are all just numbers in a database. The hacker clearly had much more control than is being let on, I would imagine he ran a SQL script of some sort to dump all of the dbCoins into one account and then put in a sell for next to nothing.
MtGox cannot afford to honour all of the coins. That is all of the coins they have, and everyone else who is daft enough to leave their coins on a public exchange run by beginners. If they honour your claim, there is no more MtGox and everyone and their mother will be up in arms, litigating, leering and generally ousting them from the community they have helped to build.
The bottom line is that you are losing the coins no matter how much you complain. You say you should keep them for the good of the community but if you've got half of the freely traded bitcoins then the market really is gone. Tough luck.
This. It is clear now that MtGox has not been trading bitcoins but a representation of bitcoin, storing the real bitcoin off-line from the trading accounts (the one big centralised 500k account). More centralisation, more fail. It is like the fiat credit crises freeze all over again, the bitcoins weren't really there and when the hackers showed up there was nothing to go around and fill the gaps, even if they took nothing, just shuffled things around and messed it all up. Lesson learned, move on, decentralise. Get bitcoins in your hand or you got nothing but promises. EDIT: By storing the MtGox float in one account then they have become a counterparty to all trades by proxy, i.e. a market maker. Not what is claimed up front. |
|
|
|
I just uploaded pdf and KeyNote versions of the talk I gave at the CIA last Tuesday: https://s3.amazonaws.com/gavinandresen-bitcoin/GavinAndresenCIATalk.pdf https://s3.amazonaws.com/gavinandresen-bitcoin/GavinAndresen_Bitcoin.keyI took questions in the middle, before I dove into the technical details. I was asked about whether or not I thought price instability would be a problem ("yes, I'll talk about that later") and how/why I got involved. Later, at the panel discussion, I was asked a question that showed I need to do a better job of distinguishing bitcoin addresses and IP addresses. And I was asked if there were moral issues, since bitcoin can be used by criminals ("I'm working on bitcoin because I think the potential benefits to the world are much, much greater than the costs.") The other speakers were from PayPal, Facebook Payments, M-Pesa, Heartland Payment Systems, and the Federal Reserve, so it was worth going just for the connections. Bitcoin is definitely the new kid on the block, and I presented it as such; not "bitcoin will take over the world" but "bitcoin is a very interesting experiment that could be world-changing if it works out." And now... there is plenty of work to be done, so I'm going to stop reminiscing about the good old days last week.... Gavin, thnx for posting this material. What are the limitations on people using it for other presentations? |
|
|
|
|
satoshi can't post here anymore as much as he would want to .... he has only ever posted/connected with forum via Tor nodes
... and the forum has now banned posting from Tor, or ....?
|
|
|
|
Is it feasible for the hash power of the bitcoin network to be hijacked for code cracking?
If the code cracking problem solution was a mapping to the block solution space it could be as simple as inserting a 'magic' transaction into the block that maps the two solutions together.
Probably easier performed by a large pool operator that distributes work and controls the included transactions in the sought after block solution, for example ... or if all diff. 1 solutions are collected then other auxiliary problems that lie in the same mapping space can be solved simultaneously also.
No. Even if an attacker really did want to find a bunch of double hashes of specific 680 bit blocks, each result he got back would have a 1 in 4 billion chance of being the one he wanted. Your reply was prompt and quite emphatic so I'll take that you must have done all the math to back that "no" up previously somewhere. Care to share? Particularly be interested to see how you discounted mappings into other problem spaces so easily. |
|
|
|
Does BitMarket.eu (because it doesn't have money deposits) count?  Not sure ... are you suggesting we request lulzSec to run a 'test' on Bitmarket.eu? What is BitMarket.eu's privacy and security policies on storing customer records, transaction records, etc? If an attacker was to infiltrate and publish records would it lead to compromised security situation or embarassment of clients using it? |
|
|
|
|
sounds like the parasites showed up for their cut finally ... oh, well it was fun to be productive while it lasted.
|
|
|
|
|
Is it feasible for the hash power of the bitcoin network to be hijacked for code cracking?
If the code cracking problem solution was a mapping to the block solution space it could be as simple as inserting a 'magic' transaction into the block that maps the two solutions together.
Probably easier performed by a large pool operator that distributes work and controls the included transactions in the sought after block solution, for example ... or if all diff. 1 solutions are collected then other auxiliary problems that lie in the same mapping space can be solved simultaneously also.
|
|
|
|
Hey! This thread got featured on TechCrunch!
Cool, might get more than measly 22 btc bounty pledges ... I guess no one really wants a secure exchange after all.  |
|
|
|
One large such example is an attempt to split the blockchain. I fear that until someone actually tries this, there may be more serious issues lurking which we can't forsee. How do you know with such certainty that this "test" has not already taken place? If you can find a suitably sized machine/network (~6Thash/s) we could test it ... but the days of a feasible >50% attack are behind us with the current technology ... ... there have been some pretty impressive ramp-ups and collapses in network hashrate that suggest such "tests" have already taken place in the past. |
|
|
|
What have we all learnt from the Mt Gox incident?
Continue on ...
Never leave home without an umbrella or a condom in your wallet ..... ? Sounds MtGox was as much an accident waiting to happen as allinvain's doomed mining operation. Also learned never be an early adopter with risky crypto-currenices. The next, best exchange will be awesome ... onwards and upwards. |
|
|
|
You clearly have a very broken understanding of what lulzsec is. They are, in fact, pretty much the exact opposite of what you're looking for.
Really? So put down zero bounty pledge from you then? Everybody has their price. |
|
|
|
they have some interest in keeping Bitcoin somewhat useful.
I really don't think they do. My money would be on that they're at least wealthy enough to be doing what they're doing, and the fact that people are giving them an anonymous e-cash reward for something they do out of the pure hilarity of it is almost certainly just icing on the cake. Why do people take hackers like Anonymous, LulzSec, etc, and then turn them into some imaginary white knight? Today's pirates will be tomorrow's queen's guards. |
|
|
|
|
In light of on-going exchange security issues (this goes back to the beginning for MTGOX if you read the archives) I'm going to start a bounty for development of a secure, private exchange for bitcoin. If someone else wants to have a go then lulzSec will be requested to white-hat attack it as the first test.
i) exchange (multiple currencies incl. BTC)
ii) secure, (impenetrable in reasonable time (20 years) to lulzSec)
iii) commercially private, (blinded transactions or similar divorcing account holders from BTC addresses)
I pledge 20 BTC.
|
|
|
|
Question for GPG knowledgeable; GPG symmetric encryption of the wallet.dat with Blowfish algo, i.e. $gpg --cipher-algo BLOWFISH -c wallet.dat is how much different than just using bcrypt? (Besides that gpg doesn't wipe the raw file off the disk as bcrypt does.) Any program that uses that algorithm properly should be secure, but you have to look at the details. The encryption algorithms work with binary keys that must be random to ensure security. If you encrypt a file, you usually do it with a password. A password is not a secure key in that sense, so the algorithm also has to derive a binary key from the password where each bit has a probability of 0.5. Example:- you have a file and want to encrypt it with AES256 - AES256 needs a 256 bit random key - you choose a strong password of 12 ascii characters Problem: - your password is only 12 * 8 = 96 bits long - the most significant bit of each byte is 0, because it's ASCII - because of that, you should not use your password as AES key directly There are different solutions now, and they really matter. That's why I would prefer GPG: It has been around for a long time, it is well tested, and the authors are experts who know the state of the art methods to derive keys from passwords. I have looked at 7z and they seem to use a good key derivation method, too. That was the point I was skeptical about. It could be that compression tool programmers don't care so much or are just not that well informed about state of the art techniques in the crypto community. So basically you don't know if/what "bcrypt" does anything different than "gpg --cipher-algo BLOWFISH"? |
|
|
|
Question for GPG knowledgeable; GPG symmetric encryption of the wallet.dat with Blowfish algo, i.e. $gpg --cipher-algo BLOWFISH -c wallet.dat is how much different than just using bcrypt? (Besides that gpg doesn't wipe the raw file off the disk as bcrypt does.) |
|
|
|
Ha! So the new meme is; "Oh. so you've got "DELAWARE BANK ACCOUNT" ... nudge, nudge, wink, wink. ... what hypocrits, after trashing Swiss banking privacy laws that are 250 years old and worked just fine, as designed, for protecting customers from predator banks, the US has got the biggest tax shelter on the planet next door to Washington and NY ... US is seriously messed-up in the head. |
|
|
|
|
Show Posts
