A native build is always prefereable to ensure you're taking advantage of all the optimizations supported
by your CPU.

Describe the problem you're having. Does it fail to compile, or fail to run after compiling? Post any error
messages.

It's not like solo mining, you don't have to be mining when a block is found. If you stop mining before a block is found you will get
credit for your share whenever the next block is found. However your percentage share will drop over time as the total shares grow
while yours remains static.

One concern is a multi-coin pool where you don't have control of which coin is mined. It would be nice if some of the more
popular coins could have their own pool.

At the moment there are two levels of profit switching: among coins sharing the same algo, and among algos. users have control over
algo switching but not coin switching within an algo's pool.

It would be nice if users could choose which coin in a specific algo's pool to mine. I'm not aware of any auto-exchange pools that
offer this. The yaamp platform offers both the tools to let users do their own profit switching, as well as the auto-exchange to
avoid requiring a wallet for each coin. It would be just a matter of giving the more popular coins their own mining port.

Yup. If you flip a coin 100 times and it comes up heads what are the odds it will come up heads the 101st time? 50-50.
Unless the coin is loaded.

Now you're name calling, that's something haters do. You're still making unsubstantiated claims of botnets, speaking for other
people, and now you claim I'm not interested in discussion. I have been very consistent is asking you
to justify your claims with data and reasoned arguments so support your assertions. You are the one who didn't want to discuss it,
you just keep repeating the same baseless claims over and over.

I was happy the way things were, and assumed you had integrity with your strong language about the specifications being
"cast in stone". That was your word, and you broke it.

I am amused that everything you accuse me of reflects more on you. I am less amused that I can't get out of this mess for
a year. Yes I'm pissed and I show it, but I have valid reasons.

Now your using lame cliches. Do you call everyone who disagrees with you a hater? That's pretty childish.
I'm presenting facts, I don't know how you can interpret that as hate.

What does the cost of CPUs have to do with the network hashrate? There were the equivalent of 1500 total
before the fork. Do you really think that's indicative of a botnet? How few legitimate miners do you think
you had? Hint: more than you do now.

I've also noticed that TD lockup time has increased due to the reduced block generation rate. Some of my TDs now
mature two days later than stated when I bought them. No more interest though so a drop in effective interest rate.

Are you willfully blind to what you've done? Everything I warned you about has come to pass and all you can do is
call me a hater. Try looking in the mirror. You hate dumpers, pools and anyone who disagrees with you.

For the record I didn't sell a single hodl before the fork was announced, they were all locked up. A big mistake in
hindsight.

LOL. Quote 100 lines and add 1.

It reminds me of an accidental email bomb at my previous employer.

1. Someone inadvertantly sent an email to everyone in the company directory. Bad, 40,000 emails with the entire company
directory in every copy.

2. A few clueless do-gooders replied to all, copying the original email and its mailing list, telling the sender
not to mail bomb the entire company. Worse, a few hundred thousand emails, each with two copies of the company directory.

3. A bunch of other clueless doo-gooders replied to all complaining about doo-gooders copying the original email, not realizing
the mailing list they were sending to was many times larger than the body they deleted. Another couple hundred thousand
emails, each with a copy of the company directory.

The mail system became unresponsive in less than 5 minutes. By then I had more than 20 replies to the original email.
The mail system had to be shut down and purged of the entire thread.

If you have questions about cpuminer-opt please post them in my thread.

Yet another unsupported assertion on your part. The locked up supply is lower both relatively (54% vs 65%)
and absolutely (3.07 M vs 3.11 M).

Here's an unsupported assertion: there was no botnet. It's just as valid as any claim there was.

Edit: On the other hand I will support my assertion.

The network hashrate pre-fork was around 400K. My i7 hashes at 275 H/s. That's the equivalent of less than
1500 i7's mining hodl for the entire network. If there was a botnet in there it would have to be pretty small
and therefore insignificant.

I there was a botnet it would be easy for pool operators to detect it by looking for multiple connections
from different IPs from the same user.

Yup, I broke that in 3.3.7. I knew that one of my optimizations would break it but forgot to follow up.
I had removed the automatic ctx init in the close function of all sph algos because it was unnecessary
in most cases. But it is needed in algos like skein2 that run the same algo multiple times. I simply forgot
to add an explicit init before the second skein round.

I can confirm that mining decred at nicehash is broken yet it works at zpool. I have also found some of the
other blake based algos are broken at nicehash.

I will have to do some more investigation.

Your mining guide says to use hodlminer-qt to mine europecoin, maybe you can fix that.

Wolf0 wrote the AES optimized hodlminer-wolf and I included his code in cpuminer-opt.

Will the current hodlminer work with europecoin of have you made changes to the algo?

It should also be noted this miner only supports stratum so it can't be used to mine the wallet. A stratum pool is required.

That supposed botnet must have been buying a lot of TDs because the locked up supply has been shrinking
since the fork even with forced lockup of all new coins.

Also who would want to run a pool when they can't distribute the coins or collect their fee for a year?
Just like the devs wanted it.

I'm confused. How do you mine Europecoin with a hodlcoin wallet?
Your web site has a link to infernopool but I can't find Europecoin there.
Your mining guide shows the hodl pool at suprnova.

Is there a Europecoin wallet and pool?

Please clarify.

Thanks for reporting this. It appears to be specific to decred and nicehash. I will look into this and do a round of testing
on nicehash to confirm only decred is broken. I'm not very motivated to implement a workaround if it only applies to one
algo in one pool.

I should also point out that decred, and other blake algos, are the worst performing algos for CPU mining.

In summary this is a very low priority issue.

client thread gets created at stratum.cpp:344 by the stratum_thread which was created by main.


Looks the same to me. It's over my head now, you need someone who knows the application code.
Could be a race condition between threads due to some missing mutex.

Caveat: I am not strong in c++ but have lots of exepience analysing system crashes.

The traceback only contains system code, I don't know if you trimmed it but if you have level #11 it might be where
the application called clone.

The crash itself occurred while allocating memory while cloning a process. malloc detected memory corruption:

#3  0x00007ffff66479b2 in malloc_printerr (ptr=<optimised out>, str=0x7ffff67467e4 "corrupted double-linked list", action=1) at malloc.c:4996

This is not an error in the code in the traceback, it likely tripped over prexisting corruption. The data was probably corrupted the last time it
was accessed prior to calling clone.

If you are seeing different crashes it is quite possible they are all the result of the same bug. It may be the same data being corrupted
every time or possibly other data. The victim just happened to be the first proceess to access the data after it was corrupted.

The application probably got hold of a bad pointer somehow and used it to write some data to the wrong place. Due to the cause
being disconnected from the crash these kinds of bugs are hard to find. If the problem is recent it narrows the scope of the problem
to a recent change.

I suggest you try to look for the point of deviation, ie when the crashes first started to see what was changed just prior. Since the crashes
seem fairly consistent you could backout recent changes until the crashes stop.

Edit: I tend to forget that c++ has no array bounds protection so it is vurnerable to buffer overflows. This would be a more likely
scenario than a random bad pointer.

 

It's working now, but it was broke from 12:00 to around 12:30, look at the hashrate graph. I was mining during
that time.

Quark is broke, no hash reported at pool.

I'm just guessing but it look like the notation means <slot version>@<running version><lanes>. That would mean the slots
were running at PCIe v1.1 even though the slots and cards support v3. I have no idea why swapping slots would change that.
Glad you got it fixed.