|
OK, thanks. I'd also like to know if it runs fine as long as you don't turn on Generate. You'd think as long as it doesn't actually execute any SSE2 instructions, it would still load. At least Pentium 3's could run it without generating.
|
|
|
|
I was able to integrate the SHA256 functionality from Crypto++ 5.6.0 into Bitcoin. This is the fastest SHA256 yet using the SSE2 assembly code. Since Bitcoin was sending unaligned data to the block hash function, I had to change the MOVDQA instruction to MOVDQU.
I think using the SHA256 functionality from Crypto++ 5.6.0 is the way forward right now.
I added a subset of the Crypto++ 5.6.0 library to the SVN. I stripped it down to just SHA and 11 general dependency files. There shouldn't be any other crypto in there other than SHA. I aligned the data fields and it worked. The ASM SHA-256 is about 48% faster. The combined speedup is about 2.5x faster than version 0.3.3. I guess it's using SSE2. It automatically sets its build configuration at compile time based on the compiler environment. It looks like it has some SSE2 detection at runtime, but it's hard to tell if it actually uses it to fall back if it's not available. I want the release builds to have SSE2. SSE2 has been around since the first Pentium 4. A Pentium 3 or older would be so slow, you'd be wasting your electricity trying to generate on it anyway. This is SVN rev 114. |
|
|
|
|
New difficulty factor 244.213223092
+35%
I updated the first post.
date, difficulty factor, % change
2009 1.00
30/12/2009 1.18 +18%
11/01/2010 1.31 +11%
25/01/2010 1.34 +2%
04/02/2010 1.82 +36%
14/02/2010 2.53 +39%
24/02/2010 3.78 +49%
08/03/2010 4.53 +20%
21/03/2010 4.57 +9%
01/04/2010 6.09 +33%
12/04/2010 7.82 +28%
21/04/2010 11.46 +47%
04/05/2010 12.85 +12%
19/05/2010 11.85 -8%
29/05/2010 16.62 +40%
11/06/2010 17.38 +5%
24/06/2010 19.41 +12%
06/07/2010 23.50 +21%
13/07/2010 45.38 +93%
16/07/2010 181.54 +300%
27/07/2010 244.21 +35%
|
|
|
|
I added the cached SHA256 state idea to the SVN, rev 113. The speedup is about 70%. I credited it to tcatm based on your post in the x64 thread. I can compile the Crypto++ 5.6.0 ASM SHA code with MinGW but as soon as it runs it crashes. It says its for MASM (Microsoft's assembler) and the sample command line they give looks like Visual C++. Does it only work with the MSVC and Intel compilers? |
|
|
|
Credit to tcatm for the caching part of the SHA context - this offers absolutely brilliant performance. Additionally, the Intel compiler really comes into its own here as its parallelisation abilities give a massive performance boost over Visual Studio.
Performance: 4700khash/s on 4 cores, I think that speaks for itself.
I've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.
Is that still starting from Crypto++? Lets get this into the main sourcecode. |
|
|
|
|
I replaced the last of the few wxBase dependencies in bitcoind.
bitcoind now compiles without wxWidgets or wxBase in SVN rev 112.
main(int argc, char* argv[]) is added to init.cpp. CMyApp and the Startup folder stuff are moved to ui.cpp. ui.cpp and uibase.cpp aren't linked by bitcoind.
The makefiles have -DGUI to control whether the GUI is used.
I test compiled MinGW, VC and Ubuntu. I don't know if I broke the Mac OSX build, someone will need to check that.
|
|
|
|
|
Sorry, actually it's ECDSA (Elliptic Curve Digital Signature Algorithm) not RSA. I shouldn't have said "prime numbers". ECDSA doesn't take much time to generate a keypair.
|
|
|
|
Great catch! Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function
SVN rev 111 |
|
|
|
i got some problems here too trying to get this run on PHP. so far i had no luck, neither the wiki-sample (jsonRPCClient trying to fopen( http://username:password@localhost:8332/)), nor my curl-sample (using setopt CURLOPT_HTTPAUTH, CURLAUTH_BASIC) seem to work. That's strange, didn't someone just say that was supposed to work? (what library was he using?) Post if you figure out what wrong. I hope it's not going to put up this much of a fight for all PHP users. Looks like we've got the Fortran scenario already. |
|
|
|
I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind produces authorization headers that look like this: ...
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk
It inserts a newline every 64 characters, which obviously breaks the Authorization header, so commands like "bitcoin getinfo" fail. The server still works fine with properly behaving clients. This can be solved by removing the newlines (and maybe '\r's) from result at the end of the Base64Encode function: result.erase(std::remove(result.begin(), result.end(), '\n'), result.end());
result.erase(std::remove(result.begin(), result.end(), '\r'), result.end());
+1 to you for having such a long password that you found this bug. Uploaded to SVN as rev 110. |
|
|
|
Here is a paper that claims to find SHA-1 collisions in 2^52 crypto operations. And optimally secure hash would take 2^80 operations. 2^52 time is still large, but it is getting into cluster and botnet range.
2^80 is if you can use a birthday attack. You can't use a birthday attack for this, so the difficulty is the full 2^160 bits. Although, if you were trying to crack any one of 1 million (2^20) transactions, you could do a partial birthday attack 2^160/2^20 = 2^140. Bitcoin Addresses are the only place where 160-bit hash is used. Everything else is SHA-256. They're calculated as: bitcoinaddress = RIPEMD-160(SHA-256(publickey)) Correct me if I'm wrong (please, and I'll gladly eat crow) but I think it would be hard to use an analytical attack on RIPEMD-160 in this case. An analytical attack prescribes a certain range or pattern of inputs to try that will greatly increase your chance of finding a collision. Here, you don't have that kind of control over RIPEMD-160's input, because the input is the output of SHA-256. If an analytical attack helps you find an input to RIPEMD-160 that produces a collision, what are you going to do with it? You still have to get SHA-256 to output that value, so you would still have to break SHA-256 too. For brute force, RIPEMD-160(SHA-256(x)) is no stronger than RIPEMD-160 alone. But for analytical attack, it seems like you must analytical attack both RIPEMD-160 and SHA-256. If I'm wrong, then the strength is the same as RIPEMD-160 and the SHA-256 only serves as one round of key strengthening. |
|
|
|
If I figure out that Public Key 123456 generates Hash ABCD
and
Public Key 654321 also generates Hash ABCD
I'm still left without the Private Key.
But from what you are saying, all I need is Public Key 654321 and I can spend coin pretending to be Public Key 123456.
You would still have to sign it with public key 654321. You need to find a collision using a public key for which you know the private key. When you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key. Red's point is that it's easy to quickly generate insecure public keys which you could break and find the private key after you find a collision. He points out that if the public key was required to be a secure one, one which must have required significant work to find the prime numbers, that would increase the strength above that of the hash function alone. Someone trying to brute force would have to take time generating a key for each attempt. |
|
|
|
|
Red, thanks for telling me privately first! Please go ahead and post it (and relieve the suspense for everyone!)
His point is that transactions paid to a Bitcoin Address are only as secure as the hash function. To make Bitcoin Addresses short, they are a hash of the public key, not the public key itself. An attacker would only have to break the hash function, not ECDSA.
|
|
|
|
|
It's best if you tell it to me privately so it can be fixed first.
I just e-mailed you my e-mail address. (or you could PM me here)
|
|
|
|
|
Please upgrade to 0.3.3! Important security improvements were made in 0.3.2 and 0.3.3.
New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes
|
|
|
|
|
Please do these tests on the test network. That's what it's for. Thanks.
|
|
|
|
|
FLATDATA was a workaround to serialize a fixed field length array. There was a cleaner way to make it understand how to serialize arrays directly, but MSVC6 couldn't do it and I wanted to keep compatibility with MSVC6 at that time. We don't support MSVC6 anymore because we use something in Boost that doesn't. We lost support for it after 0.2.0. Maybe someday I'll swap in the clean way that just knows how to serialize fixed length arrays without wrapping them in FLATDATA.
|
|
|
|
|
Show Posts
