It would be neat if someone had a page (like that handy calculator at http://www.alloscomp.com/bitcoin/calculator.php) that projects what the next difficulty adjustment will be. projected difficulty adjustment multiplier = blocks_since_last_adjustment / 2016 ------------------------------------ time_since_last_adjustment / 14_days For instance, if it already got half way to the next adjustment in only 3.5 days instead of 7, we would expect difficulty to double: (1008/2016) / (3.5/14) = 0.5/0.25 = 2.0 Also, it could show the predicted time when the next adjustment will occur, and tell when the last adjustment was and how much it changed. |
|
|
|
|
That's amazing...
So are you saying you use 128-bit registers to SIMD four 32-bit data at once? I've wondered about that for a long time, but I didn't think it would be possible due to addition carrying into the neighbour's value.
|
|
|
|
So that last command should simply be
sudo apt-get install libboost1.37-dev
Except that wouldn't work for boost 1.40+ (on Ubuntu 10.04), where you need to get libboost-all-dev. Seems they changed everything around in Boost recently, "-mt" and all that, makes it hard. BTW, I tried Boost 1.34 but it didn't have the boost.interprocess stuff. Mac OSX version is available now. See bitcoin.org or the SourceForge link. |
|
|
|
I can only imagine the pain you went through to get these builds because I'm trying to build the program on a Ubuntu 9.04 box and so far I can't seem to find all the dependencies to compile no matter how much I keep installing packages and compiling source, LOL.
I can't understand why you're having so much pain. I just followed the instructions in build-unix.txt. I made a couple little corrections for Boost 1.37, which I'll put on SVN the next time I update it, noted below: Dependencies ------------ sudo apt-get install build-essential sudo apt-get install libgtk2.0-dev sudo apt-get install libssl-dev sudo apt-get install libdb4.7-dev sudo apt-get install libdb4.7++-dev sudo apt-get install libboost-all-dev (or libboost1.37-dev) wxWidgets --------- cd /usr/local tar -xzvf wxWidgets-2.9.0.tar.gz cd /usr/local/wxWidgets-2.9.0 mkdir buildgtk cd buildgtk ../configure --with-gtk --enable-debug --disable-shared --enable-monolithic make sudo su make install ldconfig added a comment in makefile.unix: # for boost 1.37, add -mt to the boost libraries LIBS= \ -Wl,-Bstatic \ -l boost_system \ -l boost_filesystem \ -l boost_program_options \ -l boost_thread \ -l db_cxx \ -l crypto \ -Wl,-Bdynamic \ -l gthread-2.0 |
|
|
|
|
What are you needing to use listtransactions for?
The reason I didn't implement listtransactions is I want to make sure web programmers don't use it. It would be very easy to latch onto that for watching for received payments. There is no reliable way to do it that way and make sure nothing can slip through the cracks. Until we have solid example code using getreceivedbyaddress and getreceivedbylabel to point to and say "use this! use this! don't use listtransactions!", I don't think we should implement listtransactions.
When we do implement listtransactions, maybe one way to fight that is to make it all text. It should not break down the fields into e.g. comment, confirmations, credit, debit. It could be one pretty formatted string like "0/unconfirmed 0:0:0 date comment debit 4 credit 0" or something so it's hard for programmers to do the wrong thing and process it. It's only for viewing the status of your server. I guess that would be kinda annoying for web interfaces that would rather format it into html columns though.
|
|
|
|
|
I don't get how it let you send if it was not matured. Your balance would have been lower than the amount. It would have said balance 0.01, right? If I try that it says "you don't have enough money" or "Insufficient funds" from the command line.
How many blocks did it say it had left to mature when you sent?
There's a chance it might still go through.
Have you copied or moved your wallet.dat in any way?
|
|
|
|
On Debian testing 32-bit, I get a few build errors, all resembling: script.cpp:114: error: ‘OP_NOP1’ was not declared in this scope I got these when attempting to "make bitcoind" without "make clean" or "make" first. It looks like the bitcoind build instructions don't compile the headers first, but they also don't delete the headers.h.gch, so the old headers are used if present. If anyone else gets this error, the simplest solution is to "make clean" and retry the build. We don't really need pre-compiled header. It only makes it compile slightly faster. I think I'll just get rid of it. Even still, you'd still need to remember to "make -f makefile.unix clean" or delete headers.h.gch one more time to get rid of the leftover file. Damn that GLIBC_2.11. I thought I'd been careful not to accept any of the updates. |
|
|
|
|
Yeah, acutely aware that I should have stayed on 9.04 or 9.10. It's a lot more work to downgrade than upgrade and I've been squeezed for time. Ubuntu is the most popular distro, so I'm staying with that.
|
|
|
|
|
If the transaction didn't go out immediately at first, like if you weren't connected at the time, it may take up to 2 hours to resend it. Long term, it does keep relentlessly sending it.
I'll shorten that length of time in a future version.
You do need to have downloaded the complete block chain (currently 71040 blocks) before you'll see any confirms. Same with the recipient.
|
|
|
|
|
Actually, it works well to just PM me. I'm the one who's going to be fixing it. If you find a security flaw, I would definitely like to hear from you privately to fix it before it goes public.
|
|
|
|
|
"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)" isn't a new problem that started with 0.3.6 is it? This was built on the same OS installations as 0.3.0.
Unfortunately I upgraded to Ubuntu 10.04 before 0.3.0. I will not upgrade anymore. I don't know when I might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself.
|
|
|
|
|
0.3.6 Linux build is back to the old makefile.unix. It static links libjpeg so that shouldn't be a problem.
Is that working better?
If you got 22DbRunRecoveryException and you've used someone else's build before, you may need to delete (or move the files somewhere else) database/log.000000*
Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.
|
|
|
|
|
SVN is updated with version 0.3.6.
Uploading Windows build of 0.3.6 to Sourceforge now, then will rebuild linux.
|
|
|
|
|
Haven't had time to update the SVN yet. Wait for 0.3.6, I'm building it now. You can shut down your node in the meantime.
|
|
|
|
Please upgrade to 0.3.6 ASAP! We fixed an implementation bug where it was possible that bogus transactions could be displayed as accepted. Do not accept Bitcoin transactions as payment until you upgrade to version 0.3.6! If you can't upgrade to 0.3.6 right away, it's best to shut down your Bitcoin node until you do. Also in 0.3.6, faster hashing: - midstate cache optimisation thanks to tcatm - Crypto++ ASM SHA-256 thanks to BlackEye Total generating speedup 2.4x faster. Download: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.6/Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6. |
|
|
|
|
WTF? How did we get on that? AFAIK, the only e-mail is if you tell the forum to do notifications, and I guess the wiki registration. I'd consider turning off the forum notification e-mails, I don't know why we have that.
|
|
|
|
The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate. Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.
See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less. If you don't believe me or don't get it, I don't have time to try to convince you, sorry. http://bitcointalk.org/index.php?topic=423.msg3819#msg3819 |
|
|
|
You were looking at the wrong code. Here's the code that applies: bool CBlock::CheckBlock() const
{
...
// Check timestamp
if (nTime > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
...
bool CBlock::AcceptBlock()
{
...
// Check timestamp against prev
if (nTime <= pindexPrev->GetMedianTimePast())
return error("AcceptBlock() : block's timestamp is too early");
The timestamp is limited to up to 2 hours in the future. It can be earlier than the previous block, but it must be greater than the median of the last 11 blocks. The reason for doing it that way is so the time can get corrected in the next block if the previous block had the time too far in the future, like what happened. |
|
|
|
|
Was that the only thing I broke in the OSX build?! Does it actually work after just that one change?
I had to do that for makefile.vc also. It compiled, but SHA-256 didn't work correctly; it returned the same incorrect hash each time.
We'll disable it now, and if anyone figures out how to fix it, we can re-enable it then. It's still 1.7x faster from the midstate optimisation.
The Crypto++ ASM SHA-256 works with GCC on Linux and Windows (MinGW).
I uploaded this makefile.osx change to SVN. (let me know if that compiles now)
|
|
|
|
|
It was able to reproduce this. The database doesn't like the relative path.
"bitcoind -datadir=./subdir getinfo" works against a running daemon, but trying to start the daemon as "bitcoind -datadir=./subdir" gets that exception.
I guess we should resolve the full path before passing it to the database.
It looks like you were the first one to ever use -datadir with a relative path.
|
|
|
|
|
Show Posts
