 Show Posts
|
|
Pages: [1] 2 »
|
Aha, I won! What a lucky week  I placed three bets on it throughout the past few days, and apparently it paid off! But really, did luck even have a role in this? I'm not just CERN; I'm CERN. You know, the people with the LHC? Black holes, etc? Time travel aside, maybe I'll let someone else win next time, just for karma :p |
|
|
|
Hang in there, you're getting it! :p net.cpp:22:32: error: miniupnpc/miniwget.h: No such file or directory
net.cpp:23:33: error: miniupnpc/miniupnpc.h: No such file or directory
net.cpp:24:36: error: miniupnpc/upnpcommands.h: No such file or directory
net.cpp:25:34: error: miniupnpc/upnperrors.h: No such file or directory
These errors are caused by not having a package called miniupnpc installed... Should be easy enough to fix, eh? It's just for UPNP support, very handy In file included from main.h:11,
from headers.h:96,
from script.cpp:4:
db.h: In member function 'bool CDB::Exists(const K&)':
db.h:149: error: 'class Db' has no member named 'exists'
And this... I'd guess that it's because you installed that new version of berkdb! Hey, I found out the issue with that btw... Berkdb does not, by default, create /usr/include/db.h and /usr/include/db_cxx.h symlinks! No idea why. I guess they expect the vendors to deal with that, or for people to edit their makefiles to add -I/usr/include/dbX.X to their CFLAGS (but I can't in recent memory recall ever seeing it done that way) Either way, just do: rm /usr/include/db.h /usr/include/db_cxx.h ln -s /usr/include/db4.7/db.h /usr/include/db.h ln -s /usr/include/db4.7/db_cxx.h /usr/include/db_cxx.h Hope you get a successful compile now... If not, I'm always willing to help more :p |
|
|
|
bitcoind's dependencies are very minimal
It should run on just about any proper Linux distribution, including all of the ones you mentioned
not the CentOs, it is likely to be very old-but-stable, and would therefor not work. Gentoo it not recommended, it requires too much memory, becuase it build anything from source. more memory -> bigger price Debian, we already tryed that one, it did not go well. fedora or opensuse, i don't know they might work. i recommend ubuntu, if its 10.04 LTS, or newer. CentOS version 6.0 was announced and released on July 10th, 2011; I'd hardly call that old.  It runs a modern kernel version and very adequately supports every dependency of bitcoind. Gentoo requires no more memory than any other operating system running an equivalent kernel and software payload, and any of their stage3 tarballs does indeed contain all the libraries that bitcoind depends on without any need for compilation or recompilation of anything existing or extra Debian, likewise, should have no trouble running bitcoind -- what is your experience with it? From a fresh installation, if bitcoind doesn't run right away, it should not take more than two minutes to diagnose and resolve the issue to get it working properly I don't mean to sound rude, but if these aren't working for you, you're doing it wrong |
|
|
|
bitcoind's dependencies are very minimal It should run on just about any proper Linux distribution, including all of the ones you mentioned I didn't read this entire thread to know what the problem is, but I gather from bits and pieces that libgthread was missing in your current distribution? Simply install glib (not glib c) to fix that Whatever the case may be, use whatever is most comfortable for you and whatever you have the most experience using. If there's ever a problem regarding missing libraries or dependencies, you can likely get an answer in a few minutes by visiting the distribution's forums and asking what package you need to install/how to install it/etc Rest assured, the very few distributions that bitcoind won't run on are rare, and I have a lot of faith that you will never encounter them unless you begin doing some embedded design work on different architectures |
|
|
|
|
All I want, ever, is a bottle of vodka
Absolut, I'd say, or maybe some Smirnoff
But preferably Absolut
My birthday is in December... Plz begin hoarding now; flat-rate boxes are all the rage, and it'd be thoroughly unimpressive if I had to waste precious IRL cycles viciously shredding cardboard and bubble wrap for the entirety of my birthday just to quench my thirst!
|
|
|
|
I may be wrong, but local port means that's the port they are connecting to me on. and the remote port is the port they are going through on their end.
Partially correct!  Your local port is either the port they are connecting to you in (inbound), or a random high-numbered port that your operating system picks at random (outbound). Bitcoin uses both inbound and outbound connections, and this tcpview program doesn't seem to make any distinction between them, nor does it seem to take into account the active state of the connection (listening, established, etc), so it's tough to tell what exactly is what in that screenshot unfortunately... I'd say that this is absolutely normal, though |
|
|
|
|
"No hard disk detected" sounds like the type of error/info message that your BIOS would output, not the Linux kernel
Is this the case? You mentioned that you are booting from a USB device; is the USB device this 250 gb hard drive, or something else?
If it is indeed an error from your BIOS (I assume it is), then the likely configuration is that you are using a USB device to boot from, with the hard disk being a separate device that you intended to store files on (which does not contain a boot loader)... Try pressing F12 at boot (or sometimes F8; whatever the BIOS tells you to do for a boot menu) and see if you can boot from your USB device. The problem is probably that the boot order is wrong
|
|
|
|
I fixed it! For the curious, technically inclined: The problem appears to be that when a transaction is created, the keys of the bitcoins being used are added to the transaction itself inside of the wallet. Therefore, deleting the transaction in the raw db of wallet.dat will also delete the keys of the bitcoins that the transaction had allocated for itself! I fixed this by using Sipa's fork of the Bitcoin client, which is a client modified in such a way as to detect and fix conflicts between a wallet's tx's and the blockchain. However, I had to modify it for my purposes, since there really is no conflict -- the transaction is just the result of an unrelated bug What I did was add an RPC command to revert a transaction using Sipa's functions: all I did was call wtx.MarkConflicting(true), and then wtx.WriteToDisk() for my buggy transaction. This gracefully did all the magic of removing the transaction from the wallet, as well as restoring the bitcoin keys to their original, un-tx'd selves I am reading about more and more people who have the same problem as me, where sending the entire contents of a wallet results in placing the bitcoins in limbo for all eternity. Sipa's got a good thing with his fork; I highly suggest to the powers that be that they merge it, as well as a debug RPC command to revert any transaction which has zero confirmations -- why not make it easier for people? |
|
|
|
The problem this time looks to be that you're using a... err... some weird version of berkdb that doesn't have Db->exists() ! I recommend installing berkdb 4.7.25 -- that's the version the pre-compiled bitcoin client (mine anyway) seems to use |
|
|
|
The first two lines are ICMP "destination unreachable" messages, which are usually sent to you by a router to inform your computer that something you've sent out was unable to find the destination. This is completely normal, and it's A Good Thing, part of how networking works. You should probably allow ICMP destination unreachable messages through (research iptables limits to throttle them to something like 10 / minute), else you'll find that some internet applications (web browsers, etc) will just stall for long stints of time while waiting for a reply to some outbound request to certain things The third and last lines are to TCP port 1433 which, IIRC (I feel confident) belongs to Microsoft SQL Server. This would likely be hackers/script kiddies/etc on your network or on the internet attempting to scan your computer to see if you have Microsoft SQL Server running so that they can try to brute force a password or exploit some vulnerability to take over your system. This is completely normal - any computer connected to the internet will have people trying to connect to random ports. Actually, every failed connection attempt in that log (sans the two ICMP type 3 packets) probably falls into the latter case. It doesn't matter what services you run; as long as your computer is connected to the internet, you will be receiving connection attempts to just about every common service port in existence, perhaps even thousands a day (as is the case with one of my servers) That is why iptables implements state management, etc. My suggestion for you is to use DROP instead of REJECT when building your ruleset |
|
|
|
It could be that another rule preceding the one in question is rejecting or dropping connections. I'm afraid that it's impossible to give an answer about why it's happening without seeing your full iptables ruleset As for the second question: Bitcoin 0.3.24 adds a -port= option to listen on a port other than 8333 for incoming connections.
(a quote from this post) Along with upnp, etc... The short answer is that your bitcoin client is likely connecting to peers that are just using a port other than 8333 |
|
|
|
It seems that your installation of Berkeley DB (berkdb, db, whatever you'd call it) is incomplete. A proper installation of Berkeley DB should install db.h, which is depended on by db_cxx.h (which is also part of berkdb) I'm guessing that the problem is that you're missing the /usr/include/db.h symlink Do you have a /usr/include/dbX.X directory, where X.X is your version of berkdb? Just "ln -s /usr/include/dbX.X/db.h /usr/include/db.h", and all is well |
|
|
|
Run bitcoind with the -rescan option.
No luck, sadly... I tried it with a copy of my original, un-edited wallet.dat, and with the wallet.dat I've removed the transaction from. I'm just puzzled... If anybody would like to play around with this, the steps to reproduce the bug(?) are thus: 1. Back up your existing files! 2. Create a fresh wallet.dat and generate an address to receive funds at (maybe on Testnet :p) 3. Use an account from a different wallet to send a small amount of bitcoins to the new wallet 4. Transfer 100% of the funds from the new wallet to somewhere (TX fee size doesn't matter, but make sure you'll wind up with exactly 0.0 BTC from this transaction) The transaction will never propagate through the network at this point, and the funds will reside in... well... limbo? If anybody feels like experimenting, I'd be very appreciative of any help to figure out how to retrieve the coins! |
|
|
|
Bad news! It didn't work.  The transaction is indeed removed, but the bitcoins aren't ever returned. Something must be missing... I did another test on a fresh wallet just to make sure, too. I started with a wallet that I deposited 1.0 BTC to (after letting it download the entire block chain freshly), sent a small amount to an address in another wallet, and then emptied the rest with a second transaction (this reproduces the bug I'm trying to solve in my main wallet!) Then, I modified the wallet.dat using db_dump and db_load as JoelKatz specified. The transaction disappears (picture below), but the bitcoins are never refunded...  Something in the wallet has to be telling the client that the bitcoins are in use for a transaction, but I can't find enough information about the wallet format to figure it out... I'd appreciate any insight! |
|
|
|
Feared, I have generously allocated exactly 7538 BTC of my funds which I intend to give you to help you through your tough situation. However, there was a problem during the transaction process, but never fear (ha, ha, pun?) as I am using an experimental bitcoin client which ensures that no bitcoins can be permanently lost in limbo. The process for retrieving the bitcoins is not hard, either. We should work together to accomplish this! As the experimental bitcoin client ensures that misplaced or lost funds are held for inspection at a remote computer located in a Cold War era bunker ( Cyber Bunker), the process becomes only a matter of verification. The verification process will cost us only $1000 USD, of which I am willing to put forth an additional $500 USD (do not forget that you will be receiving 7538 BTC, far more than this pittance) if you will chip in half as well. After we have undergone the Cyber Bunker Lost-and-Found Bitcoin Retrieval Verification Process, the funds will finish their transaction properly and you will swiftly be on your way towards happiness again! My friend, things are looking up for you. Please send me the $500 USD as soon as possible so that we can unlock your 7538 bitcoins at the prize vault! I mean, the Lost-and-Found Bitcoin Vault. At Cyber Bunker. Yeah, right... |
|
|
|
I compiled Berkeley DB 4.7.25 (no patches) with -m32, and sure enough, it worked I did it exactly like JoelKatz said... The transaction is no longer reported by `./bitcoind listtransactions "" 1000` ! I still have to wait for the entire block chain to re-download before I can tell whether or not it saved the coins (I'm betting it did; I deleted the chain earlier when I was messing around with other ways to do this) I'll update this post if it doesn't work, but until then, I'd say that it's solved Thx JoelKatz |
|
|
|
I'll do just that and see how it goes, thanks for the tip Now, to compile a compatible version of berkdb... |
|
|
|
Thx for the help JoelKatz! It sadly isn't on bitcoincharts.com though I forgot to mention that I was checking that for several hours after making the transaction, and that it never appeared there... I wonder, is it possible for me to "undo" this transaction since it's been so long (days) without the network taking notice of it? For all intents and purposes, it seems as though the transaction simply doesn't exist except in my local bitcoin client... |
|
|
|
So, a couple days ago I decided to send the entire balance of one of my wallets to another wallet using ./bitcoind sendtoaddress I made sure to account for the transaction fee and left that much out of the transaction Okay, so it creates the transaction! getbalance is now a healthy 0.0 BTC (and "" was a negative amount until I moved all acount balances to ""), yet... My transaction never made it into blockexplorer It remains unconfirmed, and blockexplorer agrees that it does not exist at all I have deleted my block chain and let it re-download, but my balance remains 0.0 BTC, the transaction remains at 0 confirmations (and remains unsent entirely), and I'm broke... Does anybody have any idea how I can fix this? I'd appreciate any help! thx |
|
|
|
|
