Topic: [ANN] [XMG] MAGI | CPU mining | mPoW | mPoS | [MagiPay] - page 1223. (Read 2375926 times)

Allow me to post info regarding the coin swap; you can read the OP too, swap was delayed to protect new miners.

[Update: an potential adjustment of block rewards - diff]

Initial design

We have to go back to review the initial design.
https://bitcointalksearch.org/topic/m.8755719


According the above image, sorry for big miners, my initial thinking is to exclude the (personal) big hash as much as possible. Since we are initially based on M7, GPU mining is allowed at that time. The situation I am trying to avoid is the GPU farm, that is the reason of using diff-dependent rewards. As to M7M, allowing big hash in network means allowing GPU miners too if they exist. I do believe CPU miners (even with farms) would hate to see GPU farms online, same applied to individual CPU miners. This initial direction must be complied.

Issues

Network hash keeps increasing; we haven't see the arrival of rewarding peak yet while we already noticed the coming of big miners;

Current mining status in two pools:

It would be conclusive that individual miners have reached saturation, further increase in hash is mostly due to big miners. We haven't got into the 500 XMG/block stage. Provided the general user base won't grow (most likely), what do we expect once net hash hitting a point where gets 500 XMG/block?

Solutions

1) We intend to get 500 XMG/block into the net, but conditional

2) This is the idea; let's say we have three mining groups


Though we may expect nonexisting of GPU miners, we can't exclude the possibility (individual). This must be taken care of.  

The most importance of this solution is to maintain the #A:
a. Mining hash of #A must remain the same or above during the lifetime of mining.
b. Moving the optimum diff to a point where the net hash equals to the hash of #A; optimum diff is where we get maximum rewards.



It will be clear that with the arrival of #B, #A+#B leads to less rewards; Both #A and #B suffers low rewarding. #A is a faith miner and never go way in spite of zero reward or 500 XMG, and what happened to #B. #A is a set of many individual miners; for one who mines with 1 cpu, it won't be much loss if nothing coming out in one or two days (in an extreme case, we can assume at #A+#B rewards is zero). But for #B, since #B is a big farm and running costly, it won't be acceptable for them to mine without any return. We can image the same thing for #A+#B+#C. Obviously, the only way of getting rewards for #B or #C is to lower their hashing power, so that the block rewards are available for mining; it may get them to the same hashing level as #A.

If we can go this way, we will will need to select optimum diff and reward-diff pattern. The standard can rely on the mining history so far.

Any suggestions are appreciated!

Please suggest if this is the way we can go.

Dear Dev,
When will you start to swap coins from MAGICOIN I?
What's the way?

OMG, yesterday 60000sat, today someone sell 5100, what a fu**ing idiot!!!

[Update: an potential adjustment of block rewards - diff]

Initial design

We have to go back to review the initial design.
https://bitcointalksearch.org/topic/m.8755719


According the above image, sorry for big miners, my initial thinking is to exclude the (personal) big hash as much as possible. Since we are initially based on M7, GPU mining is allowed at that time. The situation I am trying to avoid is the GPU farm, that is the reason of using diff-dependent rewards. As to M7M, allowing big hash in network means allowing GPU miners too if they exist. I do believe CPU miners (even with farms) would hate to see GPU farms online, same applied to individual CPU miners. This initial direction must be complied.

Issues

Network hash keeps increasing; we haven't see the arrival of rewarding peak yet while we already noticed the coming of big miners;

Current mining status in two pools:

It would be conclusive that individual miners have reached saturation, further increase in hash is mostly due to big miners. We haven't got into the 500 XMG/block stage. Provided the general user base won't grow (most likely), what do we expect once net hash hitting a point where gets 500 XMG/block?

Solutions

1) We intend to get 500 XMG/block into the net, but conditional

2) This is the idea; let's say we have three mining groups


Though we may expect nonexisting of GPU miners, we can't exclude the possibility (individual). This must be taken care of.  

The most importance of this solution is to maintain the #A:
a. Mining hash of #A must remain the same or above during the lifetime of mining.
b. Moving the optimum diff to a point where the net hash equals to the hash of #A; optimum diff is where we get maximum rewards.



It will be clear that with the arrival of #B, #A+#B leads to less rewards; Both #A and #B suffers low rewarding. #A is a faith miner and never go way in spite of zero reward or 500 XMG, and what happened to #B. #A is a set of many individual miners; for one who mines with 1 cpu, it won't be much loss if nothing coming out in one or two days (in an extreme case, we can assume at #A+#B rewards is zero). But for #B, since #B is a big farm and running costly, it won't be acceptable for them to mine without any return. We can image the same thing for #A+#B+#C. Obviously, the only way of getting rewards for #B or #C is to lower their hashing power, so that the block rewards are available for mining; it may get them to the same hashing level as #A.

If we can go this way, we will will need to select optimum diff and reward-diff pattern. The standard can rely on the mining history so far.

Any suggestions are appreciated!

Please suggest if this is the way we can go.

You can try with some vps...