Here's an idea that doesn't require changing anything previously cast in stone, allow TD trading.
All that is required is the ability to transact locked in funds. TDs could be traded just like bonds
or commodity futures.

Of course that would have to wait until the TD user interface is significantly improved.

Unfortunately it seems HOdl coin development is stagnant and some people are looking for a magic pill
to make them feel better about the less than impressive price performance.

HOdl needs to develop and grow and I don't see that happening.

Yet more "solutions" for an undefined problem. What problem is trying to be solved and how do these proposals solve it?

The only effect I see in reducing the block reward is a marginal decrease in supply growth over the next year. There is no case
to demonstrate that the current block reward is causing problems and, even it it is, how will reducing the contribution from
mining make a difference when the large majority of new supply will come from  maturing TDs?

And you mentioned the botnet bogeyman again. What evidence is there of a HOdl botnet?

I haven't seen one coherent argument for reducing the block reward except greedy self interest by existing
HOdlers. It's a misguided self interest at that because cutting the block reward will have little impact on the
supply growth.

It should be the responsibility of those who want the change to justify it with data and reasoned arguments.
They must convince you it is the right thing to do by proving there is a problem and the proposed block reward
reduction will solve it.

The following question needs to be answered:

Given that block reward reduction is a strategy to slow supply growth as a coin matures, and, given HOdl
is not a mature coin, and,  given HOdl mining only represents 16% of supply growth in the next year, how will
reducing the block reward slow the growth in supply of HOdl?

Recent events in the UK should be a warning of what can happen when you ask the opinion of people who
are ill informed. It's your coin, you decide.

I have just realized I have been misinterpreting the Fuzzballs charts. And the result is the supply from maturing deposits
is greater than I previolusly thought.

The supply chart lists the supply of locked in HOdl is 3.5 M but the immature deposit value shows a supply of 50 M HOdl.
That means the pie chart only represents the number of existing HOdl locked up, not the potential HOdl generated by TD interest.
64% of the existing HOdl is locked up but it represents more that 10 times that much in the future.

Mining has produced 4.5 M Hodl since inception 5 months ago. Based on that rate it should produce another 10 M in the next year.
Add that to the current immmature TD value and you have a market cap of 60 M Hodl. If all mining was eliminated today the coin
supply would only be reduced by 16% over the next year.

Then there is the impact of the desctuction of mining. Who would want to mine HOdl if the block reward was cut by 50% or more?
I wouldn't. How many miners would remain? The protectionist nature of a block reward cut would also alienate any potential new
users that learn about new coins by mining.

Bots have been mentioned a couple of times but never with any supporting evidence. This seems more like fear mongering.
My onw thoughts are that HOdl algo is less attractive to bots due to the heavy demand on RAM being easy to notice by infected users.
No matter how much a bot would try to hide it always needs 1 Gb of RAM to mine.

This rush to reduce the block reward seems driven by panic fueld by FUD.

I have a significant investment in HOdl and I want it to be worth something when it matures. If it wasn't for that I would
be long gone from here.

That is nothing new. You should never download an untrusted binary file.

Notwithstanding that it is supposed to be carved in stone my main concern with cutting the block reward is the effect it will
have on the supply as it is only one source of new coins, the other being mature TDs.

The supply increase will accelerate as the big longer term TDs start to mature adding more
to the supply than mining. This will be the  case until the interest rate has settled and all high interest TDs have matured.
The result is that cutting the block reward may be ineffective in reducing the supply of new HOdl.

If reducing the supply of new coins is desireable the technique used must be proven effective. With all the data used in Fuzzballs'
charts it should be possible to map the future coin supply based on existing minig parameters and the maturation of TDs.

I'm also concerned that the significance of the price drop is being exagerated. There are two factors contributing to this that are
unique to HOdl. The supply of tradeable coins is only 30% of the total supply which reduces liquidity, and the inflationary interest
rate will put constant downward pressure on the exchange rate as the big TDs start to mature. Both need to be considered when
analyzing price trends.

I'm not yet convinced there is a problem or that the proposed solution will fix it.

Excellent point. HOdl needs to attract new users, not insulate existing users.

You've been mining for 2 weeks and you accuse long time well known developpers of open source software of infecting
it with malware without a shread of evidence that is freely available because it's OPEN SOURCE.
Is your real name Donald Trump by any chance?


You're fired!

How will reducing the block reward affect the overall supply of free HOdl?

Much of the supply growth over the next year is locked in and unaffected by mining.
Reducing the block reward will not have s significant effect on current supply but will
slow the growth of TDs which will slow the growth beyond one year.

I don't see a connection between the problem (low current price) and the proposed solution.
It still makes no sense to me conceptually but some numbers may make is clearer. Unfortunately
I don't have the numbers.

I also object to the proposal to change the block reward as a violation of HOdl's specifications. which
include a plan for block reward reductions and a declaration that it is "set in stone".

Nutocracy is a mistake just like having a brexit referendum.

The two biggest motions are to reduce the block size because the exchange price is dropping.
That makes no sense at all. I presume the premise is that cutting the block size will reduce inflation
but the real cause of inflation is high interest rates. In a short time the supply increase from maturing TDs
will overtake that from mining and the supply from mining will become trivial.

High inflation is an inherent part of Hodl due to its extremely high interest rate. One HOdl today will be
20 HOdl in a year. To have the same value the exchange rate will have to drop proportionally. It is inevitable
the price will drop and continue to drop as TDs begin to mature and add to the coin supply.

Democracy doesn't belong in business. Competition takes care of consumer choice. Decisions made by nutocracy
is the bigger threat to the survival of HOdl based on the quality of the motions so far.

I've mentioned it before, the focus needs to be on the features that make Hodl unique. With hundreds of other coins
to comptete with it's the only way to survive. And the lack of interest in improving the user experience with TDs is
very disappointing.

After a quick start the whole project appears to be stuck in the mud with no sense of direction.

CPU freq is not so simple. It can be read diectly from the /sys/ or /proc/ file systems on Linux but I don't know of an API
for Windows.

Using /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq would be preferred because it returns a simple numeric string.
But it is root access only.

/proc/cpuinfo is accessible and also includes the CPU freq but it needs to be filtered from two pages of output.

This will require more thought and more work.

Thanks for the tips.

I agree with CPU freq. Simply displaying the default freq is of no use, it just happens to be part of the brand string.
I'm sure the actual freq can be found, the code may already exist.

About github, I presume your suggestion to fork the original cpuminer-multi is to maintain its history, this is a good thing.
I wanted to wait until the development slowed down so I wouldn't be trying to  learn github while trying to fix bugs in cpuminer.

Now may be a good time to dig into it. I need to play in a sandbox for a while before I comit to it.

Thanks, that's good to know. Either it's fixed or the 980ti problem was a different issue.

The price/performance may not be ideal yet but there should be much more potential for SW optimizations.
And the power savings alone is worth it unless Maxwell prices drop significantly.

I also wonder about the possible 32 GB barrier. I'm not aware of anyone getting more than 5 980ti's working.
With the 8 GB on the 1080 & 1070 this could be limited to 4. Hopefully this is just a simple driver fix and not something
more fundamental.

Most algos are around 50% higher than their Maxwell predecessor and so is the price. When Maxwell came out it
had an immediate price advantage in addition to the power saving over Kepler.

A lower price to performance ratio would also have been nice. The lower power usage is the only advantage over Maxwell ATM.

Because it increases the overall hashrate of the rig if the CPU is powerful enough, but the priority for the CPU is to serve
the GPUs.

As someone else commented about dedicating one CPU thread per GPU, it should be noted this is more important when using -C.

That's what the arg is called but not what it does. I had assumed it did what it said but it just uses more CPU
to be more responsive to the GPU which helps the GPU hash faster. The CPU doesn't hash at all.

I replied to your message.

Your first post included CPU info that indicated you are using QEMU. Please describe the configuration of your PC
and how you are using QEMU to compile cpuminer-opt.

If you don't understand what I am asking maybe you can find some way to translate to vietnamese.

We were both wrong, I looked at the code.

-C actually has nothing to do with CPU mining, it only changes how the CPU and GPU are synchronized.

It is not implemented in other forks as it is selected automatically when appropriate.