Bitcoin Forum

All Magi miners & community,

Due to the fact that there is much talk about the bigger miners and the low blockreward i made a special thread focused on these topics.
In this way we get a clearer picture of the ideas and possibilities.
Think the main issue is clear for everybody. Because huge miners use huge hashrate the blockreward drops & smaller miners will not receive enough rewards. Feel welcome to post your ideas here and ensures that the posts are constructive contributions.

Thanks

Maybe creating a coin that increases the block rewards when difficulty gets higher could be a solution? The higher hashrate the more coins are produced. The price will decrease when more miners come because there are much more coins produced (inflation). Miners stop mining and less coins are produced. Less new coins on market make price higher. Hopefully price stabilize and miners get rewarded in a fair way. Mining difficulty would stabilize and not rise to infinity. Why is no such coins created? I know most coins are for Quick profits and intended to rise in price as fast as possible. But why is there no coins designed to have a constant price? This would make the coin more suitable for payments because we know the value of the coin. It could be a success for real usage and as a reference coin. When more people want to use the coin for real payments the price will rise but then more miners come to rescue and keep the value of each coin stable. The supply is created by the miners and the demand is for supply is created by users. If setup correctly it should even out.

Is that a crazy idea?

The higher hashrate the lower reward and vice versa? It would be very green. Then again, how recognize mining of the same person to multiple wallets.

If I count on Abacus - the reward should be superbig?  ;D

Genius  :o  First straight curve, decreasing slightly if hashrate >100 kh/s, decreasing more abruptly afterwards?

If I can give you some serious advice, stay away from this pool.  http://www.xpoolx.com/  >:(

Why so, is it not giving you as much money as you want?

xpoolx is good! They returned my 35 xmg that got lost in that mix up

Good day to all. I have a very long time ago an idea that if a group of people unite in the so-called "pool"? The essence of the idea is that to combine your speed in order to increase your earnings. Suppose a person 10-40 will work under the same account on any pool, so the speed and reward of the miner will grow, but the speed of the network will not change.
Can such an idea exist?

Why does reward have to proportionate to hash power? E.g. have it more of a "Lottery" with Miners than "who solves this mathematical problem first". This way there is incentive to use the "lightest" or most "power efficient" devices, while still keeping to the (at least I thought) goal of "everyone being equal".  This may kill pools, but IMO they aren't helping the distribution of the Magi network, just consolidating it into various entities.

Wouldn't it be nice if a Pi 0 could "mine" (and get a reward)? For $20 I can make one that is solar powered, network connected, and a battery backup.

Maybe make block time / rewards equal to the number of nodes supporting the network? The more nodes, the higher the rewards across the network?

I guess a good baseline would be to state the Dev position on this issue.  If Dev says, "It will sort itself out" then our mumbling, grumbling and groaning will merely be self soothing.

Do the Devs see whales as a problem requiring a developmental (hard coding) solution?

Many have responded that a hard code into the wallet or mining source code could be an answer.  I get that whales could simply create many wallets/forks/workers/etc.  The truth is, simply being unprofitable does not seem sufficient.  When you mix pain in the butt with inefficient you will likely see a marked reduction in whales.

Thoughts?

Not really, i like ur idea

Some mining questions.

PoS mining:

Are the rewards linear to hashing power?  That is, if I only dedicate 1 CPU to PoS while the other 3 mine, will I get less PoS rewards than if I dedicated all 4 CPU to staking?

How is PoS weight calculated?  How/why can I go from a weight of 168 to a weight of 0 just because I restarted my wallet?


PoW mining (solo):

It has been said repeatedly that solo mining is worse than playing the lottery.  Can someone explain why?  How long would it take to solve a block at ~52kh/s?

If I do eventually solve a block, what is the pay?  Variable from 1-10 XMG?  Fraction of an XMG?

Am I trying to solo mine on the same block that the pools are solving?

If so, how can I mine a unique block where no one else is trying to solve it?

Wasn't that a design goal of the coin?


This proposed solution is to make so many coins through hyper-inflation that it loses its value, and people stop mining it. This sounds to me like the end of the coin. What will bring value back after people stop mining it, when there are still millions(+) of already-mined coins out there?


This is currently how the network works. On an individual level, with an anonymous and decentralized currency, this is not practical (someone with high hash rates can just create multiple low hash rate instances).


Doesn't this trade mining power for node-hosting power? In any event, you have the same problem as above: Let's say that the minimum system requirements for a "node" is one Raspberry Pi Zero. Someone with the power of 1,000 Raspberry Pi Zeros can just divide their computing power to run 1,000 nodes, and earn 1,000 times a single Raspberry Pi Zero.

Mining, as it stands, is basically a lottery anyway, but people with more tickets (computing power) have a higher chance of winning. In addition, Magi has the built-in protection that as more tickets build to the next drawing (current network hash power), the reward for winning goes down. As such, it creates a communal incentive not to overload the network.

I'm not a Magi developer, but it seems to me like the basis of the coin was not that every miner gets an equal reward, but rather that everyone on the network needs to work together in order to make it worthwhile to be part of the network. As a result, there isn't much to do for someone (or some groups) who brings a lot of hash power to the network, other than to hope that they give up. Maybe that was a flaw in the design, but that is the design...unless I'm missing something.

I would also add that people are complaining about low block rewards, but forgetting how much value 1 XMG has gained over the years. Would you rather 40 XMG worth (for example) a total of $0.01, or .4 XMG worth a total of $0.60? Lower block rewards due to higher network hash values means reduced availability of 1 XMG, so the overall value per coin should go up (if people find value in such a coin).

How to simulate the hashrate vs coins rewarded ?

for the first few days they paid, after update they have not paid me for 2 days!

And you should ask your mother if she got as much she want for got got pregnant from the Pimp who hired her!   ;D

just reading along....

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

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 was getting 0.72 per RpiZero ;)
4 of them running did give a nice 2.8Khash/s

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 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.

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 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

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

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

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.

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.

Only POS!

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.

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

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'm new to this mining thing, can anyone show me how to do it efficiently.
Is it good to do it using a laptop?

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?

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.

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.

# 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 (https://twitter.com/Coin_Magi_XMG/status/949750814180036609). 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.