Bitcoin without pools would be even harder to break. Pools are a threat, DDoSing pools is helping bitcoin against that threat.
Aren't you going a little too far? I don't support DDoS. But its just nothing we have to worry about. Even if mining pools are DDoSed, the people who actually have the mining hardware will be interested in continuing mining (because else their hardware is wasted). Even if the number of miners drops significantly, Bitcoin will be able to operate -- you just have to wait a certain time (depending on how much the hashrate drops) longer for confirmations. After difficulty recalculation, everything is like it should be again. |
|
|
|
No, b1Ackb0x3!1 was hashed with the modern method. You can just look at the dump.
OK, thank you. Then I don't understand the point you were making with "Some passwords weren't hashed with a modern method. But the one above was." Could you amplify? Some passwords weren't hashed with a modern method. But the one above (which refers to b1Ackb0x3!1) was. |
|
|
|
Some passwords weren't hashed with a modern method. But the one above was.
If you are saying that my tropz49 password was not cracked because it was hashed with a modern method, and b1Ackb0x3!1 was cracked because it was hashed with an old-fashioned method, then would that mean that — in your opinion — I8Lik#PuDD!ng8§ would be secure if hashed with a modern method but not with that old-fashioned method? No, b1Ackb0x3!1 was hashed with the modern method. You can just look at the dump. |
|
|
|
In Ubuntu 6.10 and later versions this option is enabled by default
Bitcoin is build on 10.04 LTS, so it looks like we are using it. That's great, so everybody who uses the binary from bitcoin.org is already having it. |
|
|
|
Somebody had a similar password on MtGox and was cracked: Man, I seriously underestimated the power of GPU password crackers! I had an 11-character password which I thought was pretty good--b1Ackb0x3!1, and that was cracked. I'm pretty sure I didn't succumb to any phishing attempts. Good thing I use 20+ characters for passphrases.  You are assuming that b1Ackb0x3!1 was cracked by a brute force approach. My pathetic Mt Gox password consisted of solely five lower case letters and two numbers, seven characters total, and it wasn't cracked. Has anyone given a good explanation of why certain Mt Gox passwords were cracked and others weren't? Some passwords weren't hashed with a modern method. But the one above was. |
|
|
|
...take a phrase ie ilikepudding as an example add some caps IlikePuDDing add some numbers I8LikePuDDing8 Add some special symbols I8Lik#PuDD!ng8 Throw in an alt code or 2 §╒ª◘ I8Lik#PuDD!ng8§ If you do all that you will be legit  That's not secure. That would work for an online login, because it can limit the number of trials an attacker can make. You should not use such for encryption of wallets! A password like I8Lik#PuDD!ng8§ is not secure? You have got to be kidding. Steve Gibson's calculator at https://www.grc.com/%5Chaystack.htm gives the time to exhaustively search this password's space assuming one hundred billion guesses per second at 1.49 billion centuries. How is a password like this not secure? Steve Gibson's site says: It is NOT a “Password Strength Meter.” Somebody had a similar password on MtGox and was cracked: Man, I seriously underestimated the power of GPU password crackers! I had an 11-character password which I thought was pretty good--b1Ackb0x3!1, and that was cracked. I'm pretty sure I didn't succumb to any phishing attempts. Good thing I use 20+ characters for passphrases. |
|
|
|
Criticize bitcoin: troll Speculate in the wrong way: troll Opinion against the status quo? You bet that's a troll  you guys. If you really think it's a troll DON'T FUCKING POST and let it fall off the page. I don't think he is a troll, I think he is a serious economist. I think serious economists produce bullshit only. |
|
|
|
|
ROTFL
Again somebody he puts economist in front of his name and thinks that it means something positive.
Was there ever any economist who actually knew about economic processes? Even the weather man is better -- and he does not claim to have perfect knowledge about future weather, because it's impossible in principle.
Go away. Do theology or something, those people at least want to be lied at.
|
|
|
|
|
Bitcoin without pools would be even harder to break. Pools are a threat, DDoSing pools is helping bitcoin against that threat.
|
|
|
|
You don't put a wallet on a hosting machine - ever. That's the most stupid thing I have ever heard, there is absolutely no need for that and there is no way to do that in a trustworthy way.
Duuuuh, okay then... how do you do it? How does one run a gambling game for example where there's hundreds of incoming/outgoing payments on a daily basis? ...or to put it another way, where is the server for mt gox or tradehill physically located? In a professional datacentre somewhere or in someone's basement? I don't know exactly how the state of current software implementations is. I am talking about what the bitcoin protocoll makes possible. I think most of the current bitcoin businesses are total trash. Gambling sites are a special case, they can transfer their profit to an offline wallet and don't have to care about the security of the jackpot. If somebody steals it, why should the gambling operator care? |
|
|
|
For those merchants that are keeping a wallet.dat on a hosted server, how do you get around (or not care about) the trust issue of hosting company employees getting your wallet.dat?
Is there any way to set it up so that the host can't actually get to it?
(eg. by keeping the wallet.dat on your home PC and somehow connecting your websites to it via JSON? ...in that case, the host could still see your JSON password and do a 'sendfrom')
My only step so far has been to get my bitcoin directory on their 'exclude' list for their automated backups... so at least the wallet.dat shouldn't be getting copied elsewhere.
Anyone with physical access to a drive can get any data they want from it. The only way would be to encrypt it, but this wouldn't work for active transactions. I think you need your own server. Home PCs do not have guaranteed up-time, and they would be bad for reliable business transactions, in any case. Doesn't matter to monitor incoming payments. |
|
|
|
|
You don't put a wallet on a hosting machine - ever. That's the most stupid thing I have ever heard, there is absolutely no need for that and there is no way to do that in a trustworthy way.
|
|
|
|
These installs seem to be getting more complex. I'll stick with 0.3.21.  WTF? Does it still ask you for ridiculous fees? When I got into bitcoin, a major selling point was "no fees". I guess the greed got to them. There never was the need to pay fees for bitcoin transactions. It was only that this specific client did not accept weird transactions from peers without fees to prevent spam. With Bitcoin you are free to use whatever client you want - and changed as you like. |
|
|
|
A secure cryptographic hash can be truncated and still retain most of its strength, but this is not necessarily true for unhashed public keys. Possibly you'll lose more bits of strength than you would expect. It's safer to use a hash, which is designed for this.
OP_CAT is also disabled in script, while OP_HASH160 and OP_HASH256 are not.
What could you lose, it is just the public key. If two are identical, the first in block chain counts. There is absolutely no collisions then. ...and I am not suggesting truncating the key. I suggest the public key IS the address. We just refer to them (address) not by 30 char hash, but unambiguously by their "first bits" (shortest unambiguous prefix compared against all previous keys in the block chain). There should be no restriction on key length. Recommend 256 today or 384 tomorrow. Firstbits seems broken right now: 7/6/2011
We were notified of an address that was in the block chain, but not in our database. This is a serious problem because it could cause us to give out incorrect firstbits addresses to Bitcoin addresses which are similar to the missing address.
We have taken the site offline until we fix and verify our database, this may take 2 days. We are very sorry for the inconvenience. The best thing about the firstbits rule is that anyone can implement a site or app that follows the same rule to make consistant firstbits conversions. Unfortunately, there is no other service to refer you to yet.
It is unlikely that any incorrect firstbits have been given before we took the site down, but please double check your addresses when we are back online. |
|
|
|
Does it affect performance much?
If not, please submit a pull request, everything that makes bitcoind more safe against future exploits is good.
I could not see any performance differences, but I wanted to hear some more opinions. I didn't commit that yet because I don't know how such a change would affect people who want to use a compiler other than GCC. Will there be something like a ./configure script in the future? I think the flag must be set at the point where you know what compiler is used. |
|
|
|
These installs seem to be getting more complex. I'll stick with 0.3.21. WTF? Does it still ask you for ridiculous fees? |
|
|
|
I recommend to include the option -fstack-protector to the UNIX makefile. Many distributions (including Ubuntu) use it by default, but some others may not. Why does it make sense?On the one hand the Bitcoin client is supposed to be online and connected with many peers. On the other hand it handles data that must be kept secret at all costs. Thus the client processes messages from unknown peers all the time. If there is a bug in processing, there could be buffer overflows. Those could be exploited to take over the client. There are three common measurements at the moment against such attacks: - NX bit: a CPU feature that prevents data from being interpreted as code - address randomization: the Linux kernel gives each process different stack addresses every time - GCC stack protector: buffers on stack are surrounded by test data which makes it hard to overflow a buffer without being detected While the first two are configured by hardware and OS, the third one is configured at compile time. -fstack-protector
Emit extra code to check for buffer overflows, such as stack
smashing attacks. This is done by adding a guard variable to
functions with vulnerable objects. This includes functions that
call alloca, and functions with buffers larger than 8 bytes. The
guards are initialized when a function is entered and then checked
when the function exits. If a guard check fails, an error message
is printed and the program exits.
NOTE: In Ubuntu 6.10 and later versions this option is enabled by
default for C, C++, ObjC, ObjC++, if none of -fno-stack-protector,
-nostdlib, nor -ffreestanding are found. Of course every measurement of this kind affects Performance. But this affects only functions that have buffers of more than 8 bytes. And if you have built it on Ubuntu until now, you have had it activated anyway without knowing. |
|
|
|
A secure cryptographic hash can be truncated and still retain most of its strength, but this is not necessarily true for unhashed public keys. Possibly you'll lose more bits of strength than you would expect. It's safer to use a hash, which is designed for this.
OP_CAT is also disabled in script, while OP_HASH160 and OP_HASH256 are not.
What could you lose, it is just the public key. If two are identical, the first in block chain counts. There is absolutely no collisions then. |
|
|
|
|
first item looks very stupid
|
|
|
|
It's so funny how most people are fking clueless when it comes to math.
The 50% threshold is a STATISTICAL threshold and has no real meaning since an attacker could already with say 40% of the entire hashing power have enough of a statistical chance to realistically try to attack the integrity of the blockchain. When a pool has 50% or more it just means it easier to do then if it had 40% but nothing really changed.
Remember, it still takes 6 confirmations until a transaction is deemed valid, so even if someone has 50% of hashing power they still only have 1.5625% chance of getting 6 blocks in a row!
If a pool had 40% that number only goes down to: 0.4096% which is only about 4 times less likely to happen but already a very real threat.
As you can see, it's not a big deal, because the only thing that having so much power allows you to potentially do is confirm fraudulent transactions which becomes increasingly harder to do with increasingly more confirmations. It was already possible when deepbit had 30% or 40% or 45%, the only difference was the difficulty of pulling it off.
That's all in the regular process. If deepbit decides to split off, they generate faster. And there the 50 % are magical, because it means it has more than the network it left. That explains my advice: Don't worry, but watch carefully. We have to detect whether there is a block generating power mining in secret. |
|
|
|
|
Show Posts
