Search content
Sort by

Showing 5 of 5 results by micahs
Post
Topic
Board Beginners & Help
Re: Newbie Setting up a Server at home
by
micahs
on 08/12/2012, 09:22:46 UTC
I doubt that any used server will get a block during your lifetime.
x2 AMD Opteron 6200 wont?
I apologize. I didn't read your post very carefully, and was thinking BTC, not litecoin. And I didn't realize that litecoin blocks are still easy enough for CPUs.

Quote from: Evan
I am going the Ubuntu this weekend wish me luck
Good luck Smiley Try LiveCDs first. If you don't like Ubuntu's Unity desktop, either Xubuntu or Mint Cinnamon will give you essentially the same OS, but with a much lighter desktop (especially Xubuntu).

One other thing. If you plan to use the OS for more than a couple years, pick 12.04 (long term release) rather than 12.10.
Post
Topic
Board Beginners & Help
Re: Anyone know of an easy way to convert BTC to USD, not using paypal?
by
micahs
on 08/12/2012, 04:44:27 UTC
Cash deposit at bank of America
That's USD to BTC via TrustCash and BitInstant, I believe.
Post
Topic
Board Beginners & Help
Re: Newbie Setting up a Server at home
by
micahs
on 08/12/2012, 04:39:14 UTC
I would like it over the LAN, for now, with maybe an option FTP later on the WAN, so I can move files between work and home,
For sftp, you just need to install sshd.
Post
Topic
Board Beginners & Help
Re: Newbie Setting up a Server at home
by
micahs
on 08/12/2012, 04:35:10 UTC
All i want to do is run it as a file server for my media
You don't really need a "server OS" for that. You can just share folders to LAN, using Samba for Windows clients.

If you want a GUI, you might as well install Ubuntu desktop. By default, there is no root login (just sudo) and no ports are open.

If the machine has more than 4GB RAM, use the 64-bit version. If you want software RAID and/or whole-disk encryption with LUKS, use the alternate CD. If you don't like the Unity desktop, you can use Xubuntu or Mint instead.

Quote from: Evan
and maybe run a little bit of hashing for litecoin on it,
I doubt that any used server will get a block during your lifetime.
Post
Topic
Board Beginners & Help
Topic OP
Please help -- Some of my clients are stalling at block 209,841
by
micahs
on 08/12/2012, 03:04:56 UTC
They're all in Linux. Most of the stalled ones are 0.7.1.0-geb49457-beta (now default in Ubuntu repository). But some with that version are up to date (currently block 211,325).

For some of the stalled ones, I've tried the fix of deleting blkindex.dat, moving blk0001.dat and blk0002.dat to ~/, and running "./bitcoin-qt -loadblock=~/blk0001.dat -loadblock=~/blk0002.dat". But that just got me back to block 209,841.

I tried -rescan on one, and got that its wallet.dat was corrupted. So I lost a few Bitcoins.

At this point, it seems that my best bet is sending everything from the stalled clients elsewhere. Yes?

Thank you.

Edit: I just transferred balances out, nuked client and folder, and reinstalled. I'm still curious about what happened, though.

Edit2: Well, that didn't work! So far, two affected VMs with fresh bitcoin-qt installs have stalled at block 209,841 again.

Here's what I did:

sudo apt-get purge bitcoin-qt
sudo apt-get autoremove
rm -r .bitcoin
sudo apt-get update
sudo apt-get install bitcoin-qt

I did not retain/restore (AFAIK) anything from old bitcoin-qt installs. How can fresh bitcoin-qt installs inherit state from prior installs? Does the Bitcoin network somehow track machine name, IP address or identifying information from clients?

Edit3: I do know that clients go by IP address Smiley

Could the problem be that affected VMs have shared VPN exit IP addresses? Can that confuse peers about which client has which blocks? Can I fix that by manually changing client port number?

edit4: I've retried nuking and reinstalling bitcoin-qt on affected VMs, connecting through different VPN chains (exit IPs). But the clients still stalled at block 209,841.

So I'm just creating new VMs, transferring user data, and doing fresh bitcoin-qt installs. That seems to work. I would be totally gobsmacked if it didn't.

It's possible that my affected VMs contained bitcoin-qt "state-preservation" data outside ~/.bitcoin, which somehow tells peers to stop at block 209,841. Otherwise, it must be that peers are tracking the affected VMs, and stalling them at block 209,841.

Why would that have happened? What information is being used? How is it done?