Nice, will add up to OP.

This will be absolutely interesting, and right matches with the direction this coin is going; will take a look at the miner (I hope someone could look into it if possible as I got dozens of things in hand). I guess we need linux installation on PS3 to get the miner working according to Google search?

Can you do the test in case we have something worked out?

jawitech's statement is right. Let me know any questions.

Real time control on the temperature is nice. There will be concern of heating sources from programs other than the miner though. Also the miners needs to check the temperature. This is different from program sleep and thus might not reduce the temperature, but will take up resources and reduce the hashrate. From this point of view, temperature control might be desired by another program which takes the output of the miner as the input. This is the case one can use to avoid overheat, either reducing the hash rate is optional if one wants to reduce power consumption as well as the heating.

The miner has a particular focus with consideration of saving energy by simply cutting down the hash rate. There is no ways of reducing energy unless enforcing the miner going into sleeping mode for a certain time, and thus mitigate the source taken-up monster / heat generator. The importance is then to determine the duration; what's done is that, at the beginning of miner launching, hash rate testing, and self-adjustment by enforcing sleeping every 10 hashes in order to yield desired hashrate. Improvement can further done using dynamic adjustment. I am sure complex adjustment by combining cpu usage / temperature etc will be something interesting to deploy further.

Looks like the update; it's enabled now.

There is no limitation in the wallet balance. The 3000 XMG limitation is only applied to one transaction, not to the total wallet balance. So basically if you have 10,000 XMG, you'll have to split them on different transactions, for example, each transaction holding 500 XMG. Let's say 10,000 XMG is already in your wallet, set up a few accounts (add new address, and label them as like, a, b, c), and then you can move funds; open up debug windows --> Console, you can do so for a few times.

For any amounts of coins in staking, the offline time should be less than four days; after four days, the stake weight is not gaining but dropping. There is a reason that people want to keep a big amount of coins in one transaction, since by doing that they can get stake rewards as soon as possible. However, in that case, the allowed offline time is reduced, for example:
2000 --> 3 days
5000 --> 2 days

For best results, amount of coins/transaction should be between 100 - 1000 XMG; 500 XMG is recommended, whilst 100 XMG should be fine at this moment. At current network weight (about 1000,000), the expected time to earn rewards is < 1 day for 500 XMG and five days for 100 XMG. So you can see that 100 XMG is nearly the limit, since the stake weight is dropping at the 5th day.

The determination of all the parameters takes into account any future increase of the network weight; for example 500 XMG staking will receive rewards in about 3.5 days when it increases to 5000,000.

Same as before . PoW mining algo is not changed, and won't touch that any more. 

Are you mining with Windows system?

I'm keen to this miner; only for people who want to avoid over heat or lower hashrate, but not targeting high hashrate. Compiling is pretty straightforward for linux or mac os,
 


Spexx, are you able to include the "-e" option in your software package? Without the "-e" option or "-e 100", mining is exactly same as the prior miner.

Also for any info, see this doc:
Magi Cheat Sheet v1: http://coinmagi.org/files/misc/magi-cheat-sheet-v1.pdf
Trying to get all in one place.

I'm sorry to answer whether mining is profitable or not. You may want to try VPS: https://bitcointalk.org/index.php?topic=735170.msg8800103#msg8800103
or any other similar.

To check mining, using the following API:
10 is hashrate in kh/s.

We're expecting to have MagiPay soon.

Missed a few posts before.

Firstly, repost the hard fork as already mentioned by jawitech.


Please update the wallet to v1.2.0.1 (mandatory):

Windows: http://coinmagi.org/files/magi-release/win32_magi_v1.2.0.1.zip
Linux: http://coinmagi.org/files/magi-release/linux_amd64_magi-qt_v1.2.0.1
Source code: https://github.com/magi-project/magi/

This update includes the following hard forks:
PoS hard fork at block 131100 for better staking results (Expected on January 6)
PoS-II Protocol V2 hard fork at block 131300 (Expected on January 6)
PoW-V2 hard fork: 1/7/2015, 12:00:00 PM EST time (GMT-5:00)

Details regarding this update: https://bitcointalk.org/index.php?topic=735170.msg9991269#msg9991269


I did spend some time and tried to figure out the CPU algo, but all have been done just under the range of my knowledge. People are talent; no one would know the capability other people can do. It's not my intention to hold firmly the CPU algo statement. PTS was arguing only CPU minable, and was awarding how many dollars for a GPU miner? Everyone knows that PTS is minable with GPU now.

Once upon a time, someone was suggesting me that, go for a CPU algo, finish the PoW mining and then going into PoS. That was right likely, but not all to me. Pure PoS is not right way I figured.

Wolf0, you're absolutely right (not the GPU part since not proved yet), that "just because no one bothers to spend the time on it" cause it's unprofitable. Let me extend the statement, the idea of GPU mining is neither profitable for now, nor profitable in the future even when magi gets into top. I encourage people to work on a GPU miner for magi, but surely up to you whenever you see a time coming with profits.

Wondering?... read the OP, or the coinssource article, evok3d did spend a lot time researching and writing before publishing the article:
http://www.coinssource.com/coin-magi-a-cpu-miners-dream-proof-of-mining-pos-ii/
I've spent time on this, and the idea behind it worth of a try; I want to say magi is a coin CPU minable "ever".

I almost forgot to post the miner, for some people who may want to run it in computers with limitations, just use the "-e" option.

# m-cpuminer-legacy

https://github.com/magi-project/m-cpuminer-legacy


This is none different from the regular miner, except that an option "-e cpu_efficiency" is added, where cpu_efficiency is a number between 1 - 100, for example, 50 representing for 50% of CPU usage. A few instances:

I've finished most of stuffs regarding the coin itself, will now focus on other things including better organization of all the information, firstly the official site.

Downloads also available here:

https://sourceforge.net/projects/coinmagi/files/

Digithusiast has very much supported the magi project. I will make a full donation list as well.

We will try to get the new version as soon as possible.

Thanks mate, nice summary; magi won't be here without this community. I love it.

Happy New Year to all!

The current block reward is jumping from one block to another. The update will fix this issue. Unfortunately, once we stabilize the reward, the reward might become trivial if the network hashrate stays at 50 MH/s.

Also, for now the block reward cannot be 50 XMG because of the diff jumping. The update will make the rewards stabilized at 50 XMG if the network hashrate is 20MH/s,

Thanks RazvanO, that's really quick.

As far as I know, all exchanges did the upgrades before the hard fork; could you post details regarding the lost?

Some info:

# Currently doing the magipay tests; targeting merchant tests soon as planed.

# Planned giveaway in IRC (#magi) in the next 24 hours, send out coins over minimum 1000 XMG. We will mostly use "!tip" for the giveaway; so for one wish to participate, please be active in the channel so that we can tip you. Also please spread the words regarding the hard fork. Thanks.

[12/31] PoW & PoS updates

Please update the wallet to > v1.2.0 (mandatory):

Windows: http://coinmagi.org/files/magi-release/m-wallet-1.2.1.1-win.zip
Linux: http://coinmagi.org/files/magi-release/m-wallet-1.2.1.1-linux.tar.gz
Mac OS X: http://coinmagi.org/files/magi-release/m-wallet-1.2.1.1-macosx.dmg
Source code: https://github.com/magi-project/magi/

This update includes the following hard forks:
PoS hard fork at block 131100 for better staking results (Expected on January 6)
PoS-II Protocol V2 hard fork at block 131300 (Expected on January 6)
PoW-V2 hard fork: 1/7/2015, 12:00:00 PM EST time (GMT-5:00)

# Piece of info
Magi Cheat Sheet v1: http://coinmagi.org/files/misc/magi-cheat-sheet-v1.pdf

# Brief summary

• Implement a filter for the difficulty data and stabilizing yielded block rewards; anticipation is improved accuracy of the block-rewarding (MagiReward) system in responding to the actual network hashrate;
• Introduce a CPU miner targeting at reducing hash rate (https://github.com/magi-project/m-cpuminer-legacy) which is much more meaningful for magi in comparison with any other coins;
• Adapt a close limitation of the PoS stake weight which disables potential PoS attack via accumulating significant amount of coins or offline stake time;
• Other miscellaneous updates.

Huge amount of energies consumed in the cryptocurrency has been a big issue, which is totally opposite to the global efforts in saving energy. This issue should be resolved sooner or later in order to advance the cryptocurrency any further. As one of the possible solutions, that's the reason we have PoS. However, the pure PoS mode would never give rise to decentralization. Any approaches are vain if decentralization cannot be maintained, unless one agrees with a coin with limited time of mining or with total premining, or the such likes. The PoW should be remained in order to distribute coins into a broad audience over time.

The basic rule of dealing with the energy concern is to involve a "braking" mechanism in coin design. Such a rule exists in every piece of things in nature: why earth/electrons should circle the sun/nucleus without collapsing or departure? or just imagine a vehicle without brakes. Bitcoin or litecoin does not put actual limits in the rewards, or that simply not functioning properly. That's where magi plugs in.  

What do we need to save energy?

On the whole, mining should be encouraged at a lower hashrate level.

# MagiReward-V2

The issue to be solved in this upgrade is the removal of the vague dependence of block rewards on the difficulty, due to the fluctuating nature of block time. A basic consideration is applying a filter to smooth out the difficulty data. Details are as follows.



# Necessary to adjust miner efficiency?

A direct consequence of the above implementation is the well-shaped block rewards in which big rewards due to network fluctuation are totally avoided. The following figures disclose the real situation most likely:



Mining at a network hashrate of 22 Mh/s results in 50 XMG/block, whilst hashrate increases to 36 Mh/s like mining the air.

Who shall mine nothing?

Provided that I have a miner with hash rate of 1000 kh/s; I would have big concern of yielding nothing at its full speed, but I don't care throwing 10kh/s at nothing. The reality behind this scene will be a different story; at the time by which the exit of miners will pull the block reward back to some numbers, one is able to mine something by then. Reducing hash rate does sound the right action in this incident.

Attenuating hashrate of miners in mining bitcoins is very unusual or pointless, since the higher the hash rate, the greater the bitcoin amount mined. Except this sole "advantage", there are dozens of facts people should be aware of that increasing hash rate comes along the wrong direction: 1) running a PC miner is totally incompetent since every single person in the world would like to sharpen their miners with high hashrate; 2) running 100% CPU usage miners is impractical in most of situations even if one can do so; 3) mobile devices are incompetent under this scene.

It will be wise to run a hashrate-depressed miner under the improved MagiReward system. Technically by doing so it's possible to run miners everywhere.

# m-cpuminer-legacy

We are "joking" the miner, but this is for real that you'll need it; running it in VPS without incurring limitation imposed by vendors? working computers / school's super computer? Here is the option.

https://github.com/magi-project/m-cpuminer-legacy


This is none different from the regular miner, except that an option "-e cpu_efficiency" is added, where cpu_efficiency is a number between 1 - 100, for example, 50 representing for 50% of CPU usage. A few instances:


Given 10~30% CPU usage, the miner is more like a regular program. Please notice that neither I nor the magi team shall be responsible for any consequence because you run the miner in your working computers or school super computer.

# PoS-II-V2

What we have done in this upgrade is adding rigorous limitation on the amount of coins in one transaction for staking purpose, and reducing maximum staking time within one week. We don't expect impact on typical situation where one remains wallet online for PoS stake; the offline time should not exceed more than a week. We also recommend to keep 100 - 1000 XMG in one transaction for best results.

Again, magi implemented a braking mechanism which makes it more secure compared to any other PoS coins. To understand that, take a look at the basic PoS mining equation:

and,

Apparently [Coin-age] is a paramount quantity for PoS, which is the driving force for people to stake with as many coins/days as possible. The major weakness in this mode is a possibility of attacking the network by mining a number of blocks ahead of other PoS miners, which can be done via accumulating significant [Coin-age] by

1) having significant amount of coins, which is technically difficult to be achieved in PPC, but rather easy in a freshly created coin;
2) accumulating significant amount of offline days of coins which shall not undergo any transactions before staking, which is a rather feasible approach.  

Approaches to resolve the above situation have been proposed, mostly by manipulating the staking days. In contrast to PPC's linearly increasing coin age with time, BC and RDD are two example coins with efforts towards this, but neither of them take care of both situations simultaneously. The BC's V2.0 takes the staking time out of the equation, i.e., [Coin-age] = [amount of coins], which does not solve the issue #1. It is also none organic that one cannot buy advantages from staking time using a cheap PC, in addition to simply buying coins. The growth rate of staking days over time is compromised in RDD if one stakes coins over a month; it should be noted that any desired attack can happen within a month staking time. In addition to the above point, one should be aware that the difference in the number of coins under stake should be emphasized too. The system should encourage one staking with more coins, but discourage greedy accumulations.

Magi's PoS-II?

Magi takes the following form for coin age:
where M(coins, days) is a function of the amount of coins, and the days under stake. [Coin-age] is also the so called stake weight. The best description of M is shown below:



It's rather empirical to determine the best value of stake days. I am rather taking time to sit down and figure, with a basic rule in mind, to limit it within a week. Let's see how it solves the PoS issues:

1) one holding more than 3000 XMG does not result any good in the stake weight; for staking over 25,000 XMG is like staking with nothing;
2) the maximum offline stake time is four days, beyond which staking weight starts to drop; it's unlikely to accumulate infinite staking time.

A side advantage of the PoS-II is that significant amount of offline time is not allowed. There is no advantage of gaining coin age for offline more than 4 days. For any online stake holders, the block time will be refreshed upon finding blocks. The stake weight (coin-age) nearly increases proportional to the amount of coins when coins in one transaction are between 100 and 1000 XMG.

# Misc updates

1) PoS status update in wallet GUI; please be aware that "expected time to earn reward" is only an estimate.  

2) Correction of the money supply shown in API calls: getinfo by reducing 720,000 XMG, which was burned (https://bitcointalk.org/index.php?topic=735170.msg9900074#msg9900074).

3) Added API calls:


"Expected PoS (hours)" : 3

{
    "flags" : "proof-of-work",
    "difficulty" : 1.62299710,
    "difficulty-V2" : 1.54876817,
    "blockvalue" : 5.36191184,
}

Mining calculator:
{
    "hashrate (kh/s)" : 10.00000000,
    "difficulty" : 1.56666109,
    "difficulty(aver)" : 1.35112710,
    "blockvalue" : 5.23089843,
    "mining (XMG)" : {
        "1 hour" : 0.03245060,
        "1 day" : 0.77881439,
        "1 week" : 5.45170070
    }
}

It's very hard to define an "exact" algo to take care of the diff issue in my view. It's rather a static math problem but a real time matter involving with time-relevant situations; every algo can only solve part of issue at one time. A "perfect" algo should be smart enough to predicate the 'next' diff before it actually happens which is rather clueless since you'd never know the input, i.e., the actual hash rate. "Accurate" adjustment is possible in applications, for example, under a stable environment (http://en.wikipedia.org/wiki/PID_controller). Any efforts coping with the dynamic environment barely leads to convergence. It could lead to improvement but rather a solution. Diff adjustment in all existing algo is based on past blocks which actually tell what they did are just rough guess. My simple tip is trial-and-error, implementing adjustment particularly for the issue you had and then further optimization if needed later on.

Magi JSON-RPC libraries for C++ and Node.js:

https://github.com/magi-project/magi-api-cpp

https://github.com/magi-project/node-magi

Let me be aware of any issues.