Hard fork [client version v1.2.0.1]
[12/31] PoW & PoS updatesPlease update the wallet to v1.2.0.1 (mandatory): Windows:
http://coinmagi.org/files/magi-release/win32_magi_v1.2.0.1.zipLinux:
http://coinmagi.org/files/magi-release/linux_amd64_magi-qt_v1.2.0.1Source 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 infoMagi 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-V2The 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-legacyWe 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-legacyminerdlegacy -o stratum+tcp://pool_url:pool_port -u pool_user.worker -p password -t thread_numbers -e cpu_efficiency
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:
-e 75 -->
-e 50 -->
-e 25 -->
-e 1 -->
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-V2What 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 two weeks. 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:
hashProofOfStake <= [Coin-age] x [Target]
[Coin-age] = [amount of coins] x [days in stake]
and,
[PoS-block-reward] = [Coin-age] x APR / [days in a year]
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:
[Coin-age] = [amount of coins] x M(coins, days)
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 updates1) 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
getnewblockvaluebynumber 122478
{
"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
}
}
