 Show Posts
|
|
Pages: [1]
|
I've been running the released 0.6.0.6-beta Windows version for a few days without issue. This morning I see that it had crashed. AcceptToMemoryPoolUnchecked(): size 165
AcceptToMemoryPool(): accepted 6782e85f04
askfor tx 6aa3f5bd2139496e20ca 0
sending getdata: tx 6aa3f5bd2139496e20ca
askfor tx 6aa3f5bd2139496e20ca 1333775791000000
AcceptToMemoryPoolUnchecked(): size 166
AcceptToMemoryPool(): accepted 6aa3f5bd21
askfor tx 69c0e4718003450f04d7 0
sending getdata: tx 69c0e4718003450f04d7
askfor tx 69c0e4718003450f04d7 1333775793000000
AcceptToMemoryPoolUnchecked(): size 167
AcceptToMemoryPool(): accepted 69c0e47180
Added 1 addresses from 216.245.210.212: 45 tried, 12819 new
Added 1 addresses from 208.118.235.153: 45 tried, 12820 new
************************
EXCEPTION: St9bad_alloc
std::bad_alloc
C:\path\to\bitcoin\bitcoin-qt.exe in ThreadDumpAddress()
|
|
|
|
|
ROT13 does indeed suck for encryption.
|
|
|
|
A quick question. Could you show some pseudocode of how you handle the bets? Does the acceptor plays any role in the odds?
After creation of a new addresses pair (your address + acceptor address) site generates random secret, shows sha256(secret) to you and waits for your bet. After bet is accepted and game played new random secret generated immediately and site waits bet again. I haven't played this yet, and I'm curious how this hash verification works. If I understand correctly, you display the sha256 of some unique data, AKA "secret" before the player places his bet. Then the player bets whatever amount they like up to 15 BTC, and is shown the ring that was hit, along with the "secret" used. While it is easy to verify the secret matches the hash, I don't understand is how the "secret" relates to which ring is hit, as that would be the most important part to verify that the game is fair. |
|
|
|
But it is not an impossibility. Therefore there is some probability, however small, that it could happen. As the number of clients increases, so do the odds of this happening. See the Birthday problem article for more info. |
|
|
|
|
I haven't checked, but I assume a single Bitcoin client doesn't try to hash the same value more than once. So if I hash a value and generate an unsuccessful hash, the client won't try to hash that value again. However, independent clients have no such knowledge of what values other clients have already hashed. Therefore 1 computer running at 1000 hashes a second will find a successful hash more often than 10 computers running at 100 hashes a second because those 10 computers might be trying to hash the same value that will generate an unsuccessful hash.
|
|
|
|
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 think you should be able to pare it down to at most 5 files from Crypto++, config.h, cpu.h, cpu.cpp, sha.h, and sha.cpp. Take a look at the zip file I posted on the other thread. It's just excluding some headers that aren't needed and I think I had to move 1 or 2 functions as well, ByteSwap being one if I remember. |
|
|
|
You need to change the assembly instructions that require aligned input to unaligned - http://bitcointalk.org/index.php?topic=453.msg5774#msg5774, or make the blocks that are being hashed aligned. I haven't tried yet, but this assembly code combined with the state caching modification should make this blazing fast. |
|
|
|
|
No need to be hostile. I do have a build environment set up, but I am completely unable to compile your changes without your source code. This just sends up a big red flag for me as you've obviously modified the source for some of your builds and are unwilling to provide those changes for peer review. I think this goes against the spirit of open source. Modified binary only releases don't help progress the software and create an unnecessary dependency on an individual to provide those binaries.
|
|
|
|
|
I don't see the source code included with any of your builds. It would be great to be able to independently verify and compile the sources.
|
|
|
|
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. http://www.filedropper.com/bitcoin-033 |
|
|
|
|
+1 vote for CMake. The syntax is easy to understand and it can create makefiles for a multitude of compilers.
|
|
|
|
Yes, my post clearly says I used the latest BDB which will update the database format, and you should backup your database beforehand. I just used the latest production release from the Oracle website, and I didn't see any version requirement in the documentation about compiling Bitcoin. If you look at the BDB release notes, there were plenty of bugs squashed since whatever 4.7.x release Bitcoin is currently using. What was the rationale of using an outdated version for the official release? editHere's a release statically linked against BDB 4.7.25, so there will be no issues with database versions. http://www.filedropper.com/bitcoin-032_4 |
|
|
|
The project file is attached. You'll need to remove the txt extension and change the paths to your libraries, and compile the Release build of course, not the Debug one. If you are using the Express edition to compile, make sure to read this thread on msdn. |
|
|
|
|
A 32 bit build running on a 32 bit system with the new algorithm is definitely faster than the base algorithm. I've ran it on 3 different systems and all showed improvement.
|
|
|
|
Further examination of the source makes it clear that the hashing is done in blocks of 64 bytes. I was able to hack the SHA256 functions from PolarSSL and got it to do the block hashing just like the current code, with about a 10% increase in speed. I verified the hashes produced are the same. I took the plunge and got all the dependencies together and compiled Bitcoin myself to try to get the new hashing in place. It's odd that you say that a MSVC build decreases the hashing performance, as I've found it increases it. I'm using Visual Studio 2008 Standard on a 32bit dual core machine, so maybe that has something to do with it. I went from ~1000khash/sec with the build from the Bitcoin website, to ~1350khash/sec by just compiling the source with Visual Studio 2008, to ~15000khash/sec with Visual Studio 2008 using the PolarSSL hashing functions. edit - latest binary 2010-07-22You can get my build here : http://www.filedropper.com/bitcoin-032_3You'll need the Visual Studio 2008 redistributable to run this, so if it crashes immediately or complains about an incorrect configuration you need to install this. It includes the modified sources. I used the latest bdb, which seems to update the database format, so you can't go back to the old client because it can't open the newer database. I suggest you save your database before you try this build if you want to revert back later. |
|
|
|
|
How many bytes does bitcoin typically hash each time?
edit
It appears, if I'm looking at the source correctly, that bitcoin does 2 hashes and a bunch of other stuff and only counts it as 1 hash. Which means polarssl probably isn't faster then.
|
|
|
|
You could try the SHA2 implementation from : http://polarssl.org/With a simple test in Visual Studio 2008 of a busy loop executing the hash function it was able to hash at 1.5x the rate that bitcoin does. |
|
|
|
|
