Topic: Magi XMG mining (Read 1112 times)

# First things first
The recent hard fork gathered lots of attention and excitement and people are jumping into the currency with both feet. It needs a few months to settle out.

Patience.

Twitter @coin_magi_xmg posted a couple weeks ago about a big announcement scheduled for 1 Feb. That will have some effect on popularity and is likely to again disrupt mining activity and rewards.

Patience.

Consider that exchanges dislike frequent hard forks. They're maintaining wallets for hundreds of coins, database servers, thousands of user accounts, fail-over and backup systems. They're busy. Don't make them do more wallet maintenance than needed. Every wallet upgrade requires testing prior to implementation live on their system. It has to function correctly with the user database, trade scripts, web front-end, etc.

It's a little easier for mining pools but they, too, have an expectation that their wallets are stable and their stratum gateways, account databases, and web front-ends all function nicely together. For big multi-pools, upgrading one wallet potentially breaks the whole pool.

Patience.

Any change to how the network deals with mining is going to require a hard fork and, as we've seen this month, hard forks can be messy and time-consuming and can even introduce bugs which break the network.

HODL. Wait. Watch. Patience.

Let things settle down for three to six months.

---

# Assumptions
1. Purpose/Function of MagiReward-PoS is to encourage HODLers:
     a. to keep wallets (hereafter: nodes) on the network in order to prevent centralization
     b. to provide a level of inflation (increase number of total XMG)
2. Purpose/Function of MagiRewards-PoW is to encourage miners:
     a. to secure the network against double-spend and other attacks by transaction verification
     b. to provide a level of inflation (increase number of total XMG)
4. No provision for Proof of Burn or other security measures

# Current Situation

Nearly 1/3 (!!!) of all nodes on the network are maintained by crypto-currency exchange services (10-20) and "public" mining pools (30-50.) [Numbers are guestimates assuming need for load-balancing and maximum up-time (fail-over security.)]

__Proof of Stake__
1. By keeping open nodes on the network, the network remains a Network rather than a single centralized processing center.
2. Individuals are encouraged to keep an open node on the network through MagiReward-PoS. To wit, each node participates in a lottery whose reward is freshly minted coin in the wallet.
     a. Chance of "winning" the lottery for any given block is a function of coin age (how recently it was last transmitted between addresses, the wallet was opened for staking, or minted as a PoS reward), network PoS difficulty (determined ... how?), and the number of coin at stake.
     b. actual reward is a different function of same parameters
3. MagiReward-PoS increases the total number of coin available for use.

__Proof of Work__
1. "Miners" actively secure the network against a variety of attack vectors by computing cryptographic verification hashes of transactions taking place on the network while competing to "solve" a block-hash.
2. Each transaction has a Fee involved, which is shared by the verifying miners (?? Or is it Burned ??)
3. "Miners" are rewarded for participating in this security by receiving a portion of fees (?) as well as a number of freshly minted coin in inverse proportion to network difficulty.
4. Network difficulty is a function of the number of transactions in the verification cue, the total amount of computational power of miners on the network, and the difficulty of the previous n blocks.
5. Reduction of reward based on network computational power is intended to reduce electrical energy use of the network while preserving the well-proven security function of active computation.

---

# Proposed

This proposal attempts to solve mining rewards diminishing in the face of growing network and coin popularity AND preserve the spirit of electrically efficient, commodity hardware, mining network.

1. Allow __all__ active nodes, even those with a zero balance, to participate in MagiReward-PoS
     a. Serves to increase the total number of network nodes and keep network decentralized.
     b. Resources needed to maintain a node are, currently, relatively low. This will only marginally increase total network electrical use.
2. Increase PoS-based inflation to 5% +/- 1.
     a. 5% is enough to beat inflation in __most__ national fiat currencies. 2% +/- 1 does not.
     b. may also be enough to compensate for electrical energy use to keep node open and active; stake-weight dependant
3. Add parameters {qty_nodes} and {local_hashes_at_node} to MagiReward system such that the number of nodes on the network increase total inflation and hash rate on a single node reduces mining related inflation at __that__ node.
     a. PoS_reward = qty_nodes * pos_diff * stake_weight
     b. PoW_reward = ((net_hashes / (qty_nodes * pow_diff)) / local_hashes_at_node) + tx_fees
          i. pow_diff is a function which grows in proportion to net_hashes and shrinks in proportion to qty_txids
          ii. local_hashes_at_node is hash rate of all miners working on the rewarded node
     c. or similar ...

This proposal allows total network size, counted in nodes, to participate in the inflation rate. This serves to encourage more nodes on the network which increases decentralization.

1. local_hashes_at_node discourages large hash rate per node.
     a. Severely penalizes botnets and js web-based (CoinHive type) deployments by either
          i. reducing reward to near zero if massive hash rate on single node
          ii. vastly complicates set-up and maintenance requirements if hashing on multiple nodes
     b. Sadly, it also penalizes pooled mining but that can't be helped.
     c. On the upside, it encourages all miners to operate at least one node since, by increasing qty_nodes, rewards go up.
2. local_hashes_at_node also encourages miners to use low power consumption mining rigs, such as Arduino and other SoC boards.
3. A node consumes one or more cpu cores (and, currently, about 250MB RAM) reducing the number of cores a mining machine can reasonably devote to mining if it self-hosts a node which achieves a, admittedly small, reduction in electrical usage for mining activity.

Just missing everything. What about people that want to mine? What about people that can't throw a lot of fiat into XMG? The idea is making xmg available to the small guy too.

It can be done on a laptop. Bit of a power hog but if it's what you have. The general Idea is to try to make mining energy efficient and possible for those that can't afford to buy tons of CPU power.

Not trying to troll, but it just seems so dumb and convoluted trying to engineer around the problems with pow. Why not 100% pos? if your really concerned about electric usage then any added difficultly is wasted electric.

Why do you need to save POW? am I missing something?

I'm new to this mining thing, can anyone show me how to do it efficiently.
Is it good to do it using a laptop?

Thanks! I've compiled it using the same options mentioned in the post and now I'm getting 7Kh/s in the rpi3 with arch64. I will try with another power supply and I will repeat the test (now I'm using an Anker multi port power supply that gives 2.1A per port as max). What power supply are you using with the rpi?

Another test that I will run is use pi64 instead of arch64.

I followed this tutorial: https://steemit.com/bitcoin/@dury10/cpu-mining-use-your-cpu-to-make-money-online-with-an-eco-friendly-algorithm

on average: 10khs

Hi,

One question, I'm trying to mine XMG using two rpi3. Using raspbian I'm getting about 4Kh/s (4 * 1.1) for each rpi3. Some time ago I've read this thread https://www.raspberrypi.org/forums/viewtopic.php?t=196909 where an user says that he's getting about 10Kh/s for a single rpi3 using a 64bit SO.

So I've installed arch64 in one of my rpi3 and after compiling the m-cpuminer-v2 I'm getting the same 4Kh/s than the 32bit SO. Are these the expected results? Could it be related with the way I've compiled it? Could it be related with the pool I'm using (minerclaim)? Any idea about what's happening?

Thanks in advance for your help.

Only POS!

Reward per block should increase according to new Magi reality and bigger hashrates IMO.
"Ignoring to let it go away" is not working so far, those evil whales (lol) stay for some reason and we all enjoying 0.7 XMG/block.

I am considering some ideas but I need to know more about this world first. Still learning at this point but I do like the mission of the coin. Tweaks can always be expected.Trouble is there is no "one source" for the info. I know there is a slack thread where a "wiki" of sorts is being discussed.

The following are some solutions to the problem:

- create some sort of passport registration to mine and eventually impose limits (not the ideal solution)
- Token mining - Example -> X amount of tokens are generated every 12 hours. Every token has a max hash limit of 4320000 hashes (100hashes/second For 12 hours). Once this token is used (limit reached), it can no longer be used. These tokens are distributed randomly among interested miners. There might be times when you don't receive a token, but when you do you can't exceed the limits. This technique will create a balanced network.

--Edit

Tokens can be distributed per block

what about bonus reward per hashes, more hashes = more reward bonus

I haven't actually looked at the cost of AWS services, but my Pi 3 (arch64) "magid -daemon" is using 213MB of Swap, Reserved 691MB, and Sharing 20MB of "Memory", and additional storage of the BChain just to be connected to the network, so there is a tangible cost of resources just to run a wallet, then if limited that to per IP, would make the complexity, setup, and cost of added nodes prohibitive to most, and likely not worth the payout.

From Crypto ID
=======================
 84 connections
Network Clients seen in the last 24 hours

Sub-version   Protocol   Count   Network Share
/m-core:1.4.5.3/   
71064   178   91.3 %   91.3 %
/m-core:1.4.5.1/   
71064   15   7.7 %   99.0 %
/m-core:1.4.5.2/   
71064   1   0.5 %   99.5 %
=======================
178 Clients seen in the last 24 hours of the latest version, or sub 200 for all of them.  

Wouldn't it be nice if rewards were just evenly split between these nodes provided they are active on the network (regardless of stake)? Then you just removed all the complexity on the end user to "mine", and open it up for any device capable of running the wallet software with a stable connection to the network can earn a "ticket" (as someone else referred to it), so that those running the wallet software on their "Smart Phones", can contribute to the network and possibly earning some rewards in the process. Which makes you even more poised to be used for everyday transactions. As the network grows, decrease minimum time between blocks, to distribute the rewards a little bit quicker, but possibly reduce the amount of rewards (maybe at certain milestones?).

What about the equivalent of stratum with the above? When the network needs work done, it can be split among multiple nodes (and rewards divided accordingly?), that way one low powered device isn't trying to tackle a bunch of complicated transactions, but still can have a part, while offering scalability to the network? Make the network the pool (sorry operators) /brainstorming

Personally I think the only way to discourage the "High Mhash" whales is to have a Net hash limit at which rewards are fixed at zero.

This could be based on the average number of miners divided by net hash (If it goes over this then rewards are zero.)
then the decrease in rewards at ether side of the "sweet spot" can be modified so that it's not so harsh, as any whales would make the network hit the Zero limit quickly. 

Or have a hard-coded rate limit fixed into the system.

I do like this idea. Perhaps the chance of finding a block could be tied to the network hashrate so that if the network hashrate is high, devices with lower hashrates have a better chance of finding a block. This would encourage miners to use less-powerful devices and mine solo (better for the network).

Block rewards could be based on the number of connected nodes. With this system, rewards could be lowered when too many nodes are connected (This is to prevent people from setting up hundreds of low-power solo miners on AWS or running lots of local miners at 1 h/s) and raised when less are connected. This means that people are still encouraged to solo mine with a small number of devices since pool nodes would have a very small chance of finding a block due to having such a high hashrate.

I wll repeat what I already said on the main thread, I think it could be a possible solution.


Difficulty is still calculated the same, more hashpower = more difficulty. The only problem that I see with this approach is people expoiting the ups and downs to earn more rewards.

A variant of this could be to decrease the reward when the hashrate is not stable (going up and down in short periods of time) and increase it when the hashrate is somewhat stable. With either of them, the problem of increasing the number of miners and, hence, the increased hashrate in the network could be paliated.

The whales can do a lot of damage, but increasing the number of behaving miners too.

As a second option, there could be a mecanism of auto-regulation implemented in the miner, but this is easily bypassed using any other miner.

As a third option, rewards is constant but difficulty skyrockets when there's more hashpower. This would be bad because it defeats the main porpuse of the coin, to be eco-friendly.

And as a fourth, I think it's already been mention, take into the calculation the number of nodes and miners in the network (if there's any way to account for that) and have an average of the hashrate to calculate the rewards, and the total hashpower for the difficulty.

Hope this make sense to anyone!

My C++ is really rusty, but as a software engineer myself, I could give it a go and help if a solution comes out of this thread

i was getting 0.72 per RpiZero
4 of them running did give a nice 2.8Khash/s

I really don't care.  I am mining for fun.  I have a 2010 era HP touchsmart that I re-purposed with Ubuntu that would be running anyway.  I have a a 2008 era netbook that I also re-purposed with Ubuntu.  And then a Raspberry Pi with a 7in touchscreen that was doing nothing.  Add my home business windows 10 machine and I get about 50KH/s all day long from all 4 put together.  I am more or less doing it to learn about how to mine and to use up my idle, running, computers.  Energy consumption is negligible.  The wales will dye, they are in it for profit...not me.

I tried with a Pi Zero (had to use Raspbian). Was doing about 0.5 khases/second. Not worth it.