You can not update the Kernel in a VPS! Because the Kernel is shared with the main machine. VPS's are not VDS's.
Haha, good to know...! |
|
|
|
|
My response: it's completely true. I find myself googling the same thing a dozen times because I don't bother to remember it, and I know it is just an easy click and type away.
|
|
|
|
I'd be fine with Debian if it actually worked with the latest bitcoind.  Maybe they have Debian 6.0 available, not sure. That's one thing I'll be checking out. |
|
|
|
How risky do you guys consider it to be for me to download the executable form the first post and run it on my machine?
It is trivial for someone to make a slightly-modified executable that appeared in all respects to work correctly but such that given the account name, they could deduce the private key. That said, I think it's highly unlikely that anyone has bothered. You can actually check for such a thing. Unless someone specifically thought that someone would test for this, the most obvious way to do that would leave a tell. Create a specific vanity key, say "1Dag". Then create that same vanity key again. And then do it one more time. If any of your keys are the same, you have a sabotaged binary. If not, then you either don't have a sabotaged binary or the sabotage is very subtle. (The obvious way to sabotage it would be to use a defined pattern of keys rather than a random one.) Oh, I don't doubt there's ways to subtly hide all sorts of malicious activities. I'm just talking from the standpoint of samr7's reputation here. I trust him, based on the work that he has released, the manner in which he released it, and the respect with which he conducts himself on this forum. Perhaps I am too trusting of people, but I get no indication of a bad apple. And since he's the one releasing the source code and builds, I also trust those builds. |
|
|
|
How risky do you guys consider it to be for me to download the executable form the first post and run it on my machine?
Considering the work that samr7 has put into optimizing the code (and seeing those optimizations actually help), I would say zero risk. |
|
|
|
SgtSpike, It is possible I missed something but can you tell me why do you need to run bitcoin in your rented headless box.
It'll be for a new website I am developing. I'll be running XAMPP and bitcoind. |
|
|
|
Debian GNU/Linux 5.0 \n \l So the issue boils down to this: Someone else compiled it for bitcoin.org on a flavor of linux with newer libraries, and since my version of linux has older libraries, I can't run it. I'll look at compiling it myself then, that seems to be the only route to go. Is there a way to update from 5.0 to 6.0 without losing my files and configs? Yes, you can upgrade. Here are instructions: http://www.debian.org/releases/squeeze/i386/release-notes/ch-upgrading.en.htmlWell, been following those instructions for the past two hours, and when it finally came to the kernel + udev install, then a reboot, SSH didn't come back up.  Guess I'll ask my VPS provider to reset it and start over. Or maybe look at what other OS's they have available... |
|
|
|
|
Thanks for the explanation. Guess I'll try to compile 0.3.24 then...
|
|
|
|
Debian GNU/Linux 5.0 \n \l So the issue boils down to this: Someone else compiled it for bitcoin.org on a flavor of linux with newer libraries, and since my version of linux has older libraries, I can't run it. I'll look at compiling it myself then, that seems to be the only route to go. Is there a way to update from 5.0 to 6.0 without losing my files and configs? |
|
|
|
Errr, not sure what version. Will have to check that next time I SSH in. I'll check that doc - thanks! For now, I am running 0.3.22 that someone compiled for a headless CentOS install.
Please, please, please if you are running anything older than 0.3.24, just turn it off. There were some bugs when sending blocks which result in severe network segmentation and just generally isnt good for the network. Can you elaborate? |
|
|
|
What would cause it to fail? If there's not enough coins with more than 6 confirmations? Or if those coins would cause too high of a transaction fee?
It only fails if there's not enough BTC. SelectCoins doesn't care about fees or transaction size (though it probably should). So the basic process is: if total coins with more than 6 conf > the amount to be sent, then find combination of addresses that results in the least amount of change. else if total coins with more than 1 conf > the amount to be sent, then find combination of addresses that results in the least amount of change. else if total coins with more than 1 conf or 0 conf if sent to self > the amount to be sent, then find combination of addresses that results in the least amount of change. else don't send coins because you don't have enough! Someone correct me if I am wrong. Thanks for the explanation though everyone who contributed! |
|
|
|
Sorry to bump an old thread, but I am getting the same errors in Debian with 0.3.24. Is there any fix for this? Any commands I can run to download and install the appropriate libraries?
What version of debian? But, yes checkout doc/build-unix.txt for instructions on building Bitcoin from source (on debian). Errr, not sure what version. Will have to check that next time I SSH in. I'll check that doc - thanks! For now, I am running 0.3.22 that someone compiled for a headless CentOS install. |
|
|
|
|
We need a map with all of the physical goods/services seller locations that accept bitcoin. It would be nice to visualize what businesses near me accept it, if any. Or make a point to stop by one if I'm on a road trip.
|
|
|
|
Am I the only one here that thinks OP is missing the entire point? That it has nothing to do with open source or what he is writing, that the people using his code (including himself) are the ones open to attack through malicious strings from malicious people, solely due to his lack of proper sanitizing in HIS own code? Am I taking crazy pills? Why is he missing the point?
He's properly sanitized his code. The only way it could potentially be de-sanitized is if an idiot coder added some new variables that weren't sanitized. While I can see Xephan's point regarding sanitizing the code via prepared statements to protect against people downloading his code and modifying it, I won't hold it against BCEmporium for not implementing it. As long as you're not a complete moron coder, you'll be sure to sanitize the inputs, so it doesn't matter anyway. And if someone really does want to protect against the moron coders out there, they can feel free to change the code once it is open sourced. BCE - keep on coding the project, and forget the naysayers. They can modify it how they like - you just build it how you like. I appreciate that you've tackled such a project and plan to release it open source.  |
|
|
|
Well, I managed to find a working version of 0.3.22 to run. It was meant for centOS, but seems to work on debian without a problem. I have yet to test RPC calls though. The version I am using was downloaded from this post: http://forum.bitcoin.org/index.php?topic=685.msg371171#msg371171Why is it such a problem to run bitcoind on Debian and so many other headless linux OS's? From what I have read, it seems like the dependencies are not something you can upgrade - it's part of the core OS. It seems silly to have such dependencies that exclude so many linux OS's from running bitcoin... I could be wrong, and if I am, I would very much appreciate someone pointing out how it might be possible to run one of the later versions of bitcoind on debian. |
|
|
|
|
Sorry to bump an old thread, but I am getting the same errors in Debian with 0.3.24. Is there any fix for this? Any commands I can run to download and install the appropriate libraries?
|
|
|
|
You could try installing the package "ia32-libs-gtk", which contains a 32 bit version of libgthread (just a warning: it includes some GTK+ stuff too).
Interesting... now I'm getting the same error as the 64-bit version of bitcoind when trying to run the 32-bit version. I suppose that's a good thing, now that I have one error out of the way... Just need to figure out this one. I'll do some more googling, but if anyone has any suggestions, feel free to give me a shout. ./bitcoind: /usr/lib32/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./bitcoind)
./bitcoind: /lib32/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoind)
|
|
|
|
|
I need to send a confidential piece of data to another person electronically. What is the best method of doing so, with zero chance of anyone else intercepting/interpreting/storing the data sent? I would send it via email, but email logs could potentially reveal it in the future. I would send it via a chat program, but not sure whether the central server for the chat service might be storing the data.
|
|
|
|
Got XAMPP working on the server, so that makes me happy.  Ok, so I'm still up against this error trying to run bitcoind: ./bitcoind: error while loading shared libraries: libgthread-2.0.so.0: cannot open shared object file: No such file or directory I've uninstalled the libgthread2.0-0 package using "sudo apt-get remove libglib2.0-0" and reinstalled it using "sudo apt-get install libgthread2.0-0". Still getting the same error. Now, I've read a few people suggesting symlinks. From what I understand, a symlink is basically an alias or pointer for another file? Is there a possibility that the library file is misnamed, and I can point libgthread-2.0.so.0 to the proper file via a symlink? |
|
|
|
|
1K8F2dzKzvxixkMQhb8dq7LBCuKxCPFgW8
|
|
|
|
|
Show Posts
