|
Maybe it's the UAC stuff - like perhaps the %APPDATA%/Bitcoin dir was created while it was running as administrator but now it's running normally? Maybe you could try running it as administrator to see if it's related to that.
|
|
|
|
|
The difficulty doubled since all the slashdot users showed up, so expect it to take significantly longer. New 8 core workstation, probably several coins a day, but 3-4 year old computer, probably one every couple days. Each block is worth 50 BTC right now.
|
|
|
|
|
Couldn't I just run 500 instances of the proposed capped client? This is more about trading than generating - the generation is just to make it so the supply is limited.
|
|
|
|
Here is a similar script written for bash that I use, in case someone else finds it useful. It will also start bitcoind for me in case it is terminated or if the computer is rebooted. (replace /home/solar with the dir where you keep your home directory: $HOME) #!/bin/bash
NICE=/usr/bin/nice
BITCOIN=/home/solar/bitcoin/bitcoind
ADDR=149iLTM499LvvktTSbub77dJYvZ7YVGtXo
NODE=192.75.207.66
date
${BITCOIN} getbalance 2>&1 | while read balance;
do
if [ "${balance}" == "0.000000000000000" ];
then
echo "zero balance";
elif [ "${balance}" == "error: couldn't connect to server" ];
then
echo "server not running, starting...";
${NICE} -n 19 ${BITCOIN} -daemon -addnode=${NODE}
else
echo "sending ${balance} BTC to ${ADDR}"
${BITCOIN} sendtoaddress ${ADDR} ${balance};
fi
done
I invoke it from crontab like this 0 * * * * /home/solar/bitcoin/sendbalance.sh >> /home/solar/bitcoin/sendbalance.log 2>&1
|
|
|
|
|
This seems like a commonly reported problem now - something to do with the block downloading being really slow. It may be related to the excessive amount of disk I/O that is generated during the initial download. The database file is flushed to disk every time a block is added so this is being really slow for some people. I think we can probably fix this up now that we know about it.. I for one didn't do much testing without having all the blocks, so it never occurred to me to try this under different systems.
|
|
|
|
|
The 32 bit binaries work on both 32 and 64 bit windows.
|
|
|
|
Currently the code is heavily little endian so it is not just a recompile to support PPC unfortunately. I wanted to try working on a big endian patch but I couldn't really find a good enough reason to  |
|
|
|
"difficulty" : 45.38582234101263 It jumped from 23 in a couple days. I think this pretty much puts an end to generating a block a day with a personal computer.. but you can still get lucky. Now you'll need to build a cluster or hijack a college computer lab for it to be worth doing I expect the trading value will increase significantly over the next few weeks as the supply slows down; should be interesting. |
|
|
|
|
It sounds like the slow block downloading is a problem for some people but not others, regardless of the platform.. I will try to look into it more, thanks for the report.
|
|
|
|
|
Would be interesting to see if you get better results without it - someone else reported trouble with that until they added an exception for the %APPDATA%/Bitcoin directory.
|
|
|
|
|
Basically anything that's generated while the node doesn't have all the blocks just ends up being rejected because it would fall in the middle of the block chain not at the end (but your node thought it was at the end because it didn't know there were a lot more blocks). The blocks are small but it takes a while for your computer to validate each one so that's why the initial download takes a while. I'm not exactly sure why it's taking so long for some people, maybe it's because the database is flushed to disk constantly and some kind of antivirus is scanning every file write, but it takes about 10 minutes for me to get it all back if I remove my data directory.
|
|
|
|
|
Those with more computing resources will generate a larger portion of bitcoins over time but it is definitely not a maintainable thing as the algorithm adjusts difficulty in response to how fast the generation gets and it can only get slower thus limiting supply even if a lot of compute power is added.
|
|
|
|
|
You will not be able to generate if you're not connected. Generation will stop until at least one connection is made and the most up to date block is received - it is a block chain after all so you can't insert links in the middle, you always are adding to the end.
|
|
|
|
Looks like your wxWidgets and STL - you should compile your own wxWidgets from the 2.9 release. Use something like this to configure it and adjust the reference paths in your makefile.unix mkdir buildgtk
cd buildgtk
../configure --prefix=/home/my_user/bitcoin/deps \
--with-gtk \
--disable-shared \
--disable-debug_flag \
--enable-stl \
--enable-utf8 \
--with-libjpeg=builtin \
--with-libpng=builtin \
--withregex=builtin \
--with-libtiff=builtin \
--with-zlib=builtin \
--withexpat=builtin
|
|
|
|
|
Yea SSDs rock, I finally bought one a few months ago and it's a huge difference. It doesn't really matter if you buy the super high end one or a regular mainstream one, they all are better than a rotating disc.
There is an unfounded fear about them wearing out from writing but this is true for magnetic platter drives too and it will still outlast your computer even if you format it every day.
|
|
|
|
|
The blocks are just random data - the only purpose of the hashing and block generation is to limit supply and provide a way to arbitrate double spending.
|
|
|
|
|
You could try using tor maybe and see if that works better, though it will increase your latency even more.
|
|
|
|
|
Show Posts
