I ran into this problem when I was originally working with jhPrimeminer on a headless linux box.  The problem seems to be with wine: if you run a console application in the background and attempt to capture the output, the wineconsole process eats 50% of the CPU.

The only solutions I've come up with are 1) nohup the miner and never see the output or 2) output directly to screen and never disconnect.  :\


On an unrelated note, the reason you see so many extra characters in the log files (and the reason they're so hard to grep) are because of all the control characters.

Out of curiosity, how does one set up a seed node?

Misc stability/compatibility tweaks.

Now includes fail2ban by default to prevent brute-force login attempts.

More compatibility tweaks and a few stability tweaks.

fail2ban included by default to prevent brute-forcing an SSH login.

Good catch, I've updated the script.  That's what I get for copy/pasting.

I'm not certain about the node list.  I haven't updated it since the initial script build.  It may no longer be needed, but to my understanding Quarkcoin always takes a while to find peers.

I support this idea.  Although, to my knowledge all that will affect is the roundPrimorial which you can crank up by jacking with roundSievePercentage.

lowendbox looks pretty nice.  Thank you for that.

I also took a closer look at server4you.  The vServer section is a bit more appealing, but I'm turned off by the sudden price shift based on billing period.  For 6 months is $20/month, but if you only want just one month, that'll be $45.   

Yeah, but nobody is going to run Intel Xeon processors in a desktop.  They're horrendously expensive for their return.
I paid ~$80 for my AMD Phenom II X5 955 and it churns out ~0.80 chains/day.
I paid about $100 per 1.00 chains/day, whereas Amazon paid $1200 per 1.00 chains/day.

You don't need server grade hardware for poor man's number crunching.

Another minor update.  I've noticed that some hosting providers (DigitalOcean) occasionally result in a Kernel Panic on boot.

I've modified the script to auto-reboot in case of a kernel panic so mining can continue as usual.
Secondly, the swapfile will only build one time (it'll skip it if it detects a swapfile).

Updates are now as simple as re-running the whole script.

Another minor update.  I've noticed that some hosting providers (DigitalOcean) occasionally result in a Kernel Panic on boot.

I've modified the script to auto-reboot in case of a kernel panic so mining can continue as usual.
Secondly, the swapfile will only build once.  Updates are as simple as re-running the whole script.

What's the ballpark "chains/day" stat on that?

---

Nevermind, I wouldn't even consider them.  This is in the footer of the page:

One of the small DigitalOcean droplets gets 0.16 chains/day and costs $5/mo.
$5/mo = $0.167 / day
$0.167 / 0.16 = $1.05 / (chain/day)

Linode gets about 0.95 chains/day and costs $20/mo.
$20/mo = $0.667 / day
$0.667 / 0.95 = $0.70 / (chain/day)

FortaTrust *shiver* gets about 0.75 chains/day and costs $15/mo.
$15/mo = $0.50 / day
$0.50 / 0.75 = $0.667 / (chain/day)

I'm going to have to go with no.  http://ideone.com/0hpVxd

The problem is that the fact that the bit's values are consistent to their location.
For example, the outermost bytes only mix with the outermost bytes and the innermost bytes only mix with the innermost bytes.
The only time that doesn't occur is when the "+1" happens to cause a carry to happen.

You can see from the example that the lower input values yield very easy to "reverse" numbers.  If you know the input number was small, simply take the back half of the hash, and reverse the bit order.
With larger input values, the pattern isn't as apparent, but you can still tell that it's there.


My other major concern is how the algorithm would handle messages with length greater than 64 bits.  Most hash algorithms use a compression function for this, but from the code below, there doesn't seem to be one.  If your

Lastly, even if this algorithm had iteration and a compression function, the fact that the output length is only 64 bits is quite troubling.  Even if you had compression and iteration functions, any input message longer than 64 bits would also have a "collision" message that's less than 64 bits.  The digest length alone makes it 2^64 times less secure than MD5.


Sorry mate. 

If it's meant to help the victims of crime, why not call it JusticeCoin or something?

I think I'd start of by introducing the concept of "coin mining" by actually using mining as an analogy.

You and a whole bunch of other folks go into a mine armed with a pickaxe and you start chipping at the rocks.
It's really hard work, but every once in a while you'll find a chunk of gold!  When you do find a chunk of gold, you hold it up and announce to all the other miners that you've found something of value.  Everybody writes down in their ledger that you own that specific chunk of gold along with where you found it.
You can take this gold and trade it for cash, or you can find stores that accept the gold directly and barter it for goods.  You can even break off a chunk of the nugget and give it to another person.

As one section of the mine becomes depleted, you move further down the mine.  There's still gold chunks buried in there somewhere, they're just spaced further and further apart, so you'll spend more time digging at the walls to find anything.
After a long time, all the big chunks of gold have been found, but there's still gold buried in there, they're just not quite as big nuggets as they used to be.

Here you have the option of describing a mining pool: instead of each person getting to keep the whole nugget for themselves, a group of miners band together and form a pact.  Whenever one of them finds a chunk of gold, they'll split the gold nugget amongst all the people in the pact.  Each person gets a share of the nugget equal to how much rock they've mined leading up to it.


Now all you have to do is explain that the work you're doing to mine gold isn't by swinging a pickaxe, it's by looking for numbers with very specific properties.
Depending on which mine you're digging in, the requirements of the numbers are different.  In some mines, they want really big lengths of prime numbers.  In other mines they want numbers that, when mathematically crunched, are less than a certain value.  It all depends on which mine you're digging in.

---

edit: Apparently I killed the conversation.  Great.

Hey!  Glad to see a primecoin guide being written.

I wrote one a while back and I've made a few tweaks to some of the default scripts mikaelh made.
Feel free to borrow any of the code from it.  

---

edit: Here's a direct link to the script for easy access.

edit2: I might steal your idea of cpulimit if that's alright.  Some VPS don't like people maxxing out CPU usage, so having a means of throttling it may be a good thing.

edit3: Just a note, you probably don't need to set genproclimit if you're going to use cpulimit.  If you're using 3 of 4 cores, you'll never have it go above 75% usage.

So this is the 3rd thread that's just the first two threads all over again?

Also, your memes are bad and you should feel bad.

You mean price per block?  On Amazon's AWS with a cc2.8xlarge, it comes out to ~$6 / block.  That assumes you have average luck.

Well, if you paid for a sports car, you kind of expect to be able to treat it like one.
Otherwise, you'd rent a station wagon.

I think something that would be a limiting factor is block validation.

The work to solve a block must be difficult but easy to verify.  With SHA256 and scrypt, you can simply check the result.  With primecoin, you run probable primality tests.  With arbitrary digits of Pi, it takes almost as long to verify as it does to generate.

See this post: http://stackoverflow.com/a/14283481/477563