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

My idea was using the hash of the actual mined block (reward of block using factor from lower bytes of hash of same block), not the previous one. So it's not guessable beforehand. If you don't like the yielded reward, you can always try to mine another alternative block before someone else does, but I guess that wouldn't be profitable anymore.

I have put a test chain on node 45.35.251.73. This is only for test; mining won't be valid:

Download the wallet and blockchain from the following:

http://coinmagi.org/bin/test/
(I'm away from my compiling setup so only 64bit binaries are available at the moment)

source: https://github.com/magi-project/magi/tree/v1.4.3-test

* v1.4.3.1
* v1.4.3.2: Updated protocol version so that prior version will be disconnected
* v1.4.3.3
Difficulty adjustment

Pls help the test (PoW & PoS mining). We'd see if this test comes out without forks.

The chain will proceed when PoS and PoW both are mined or in a pace of about 15minutes when block conditions aren't met. If you have coins in the official chain, you might be able to use that on the test chain for PoS minting (make sure backup wallet.dat).

Node:

Randomness can be optional, while I'm wondering if randomness is mainly served to make block value guess be difficult? However, if we go patterning the average reward following a rule, I bet people can make use of the average rule. And yet, I wouldn't go complete random blocks at this point, as in the case big miners jump in who will actually control majority reward; the reward must make connections to parameter(s) that reflects the actual mining scene.

Other than the mentioned solution, I actually in part put efforts on the PoW mining that, in the case of big hashrate, put aside block reward to benefit people, who remains in nodes, PoS mode, or some other services.

Why making it so difficult?
You have to fill a default reward array before start.
Just calculate the next (but now not next) block reward, as always.
Only put this reward in the array.
Then you pick a reward from the array randomly, or by own algorithm as a reward for the current mined block.
Algorithm: When hashrate is high, pick only smaller rewards, hashrate low, pick higher rewards.

That's why we have magipay (it works at this point), and I was pursuing all along, however things came out upon limits when the coin relies on few people. I wish we have a community-surrounded involvements in creating various services / developments which will absolutely lead to more technical stuffs than just the team.

anyway im just gonna wait and see if joe likes the idea. Nothing we can really do if he doesnt like it. Also if it can actually be done. No use if he likes it but not possible. hahaha

Time to go back to what i was suppose to be doing... :p

hahaha. i already thought about it a while ago but wanted to hear others opinion 1st. id like to learn how others who actually try to do this. Like i said more minds better. Even if it is not doable i still enjoy actually thinking of possible solution. A healthy exercise for the mind.

And yup
yup people will be able to tell the value of the next block but that will give them more work to actually do flash mining and just jump when its profitable. if its based on the time stamp of the previous block or hash then they gotta pull that up every time then check the  value of that then point the bots. when blocks are found in less than 3 mins that would add some more work for them to just flash mine. getting all those bots pointed right away wont be that easy as well some will have delays. Right now if you observe the network we get a few high reward blocks before they can jump in. so if they dont improve their reaction time to just a few secs they wont be able to jump in at the right time. If it can be done or not i do not know. Will joe like the idea or not? I do not know. Its just an idea i wanted to share. really up to joe and the community.


12 hr avg only without the randomizer will probably just make it worse. thinking about it i think 12 hrs is way too long a per hr avg might be better. i didnt really think of how long the period should be just the randomizer idea is what i focused on. The period should adjust the maximum coin that can be mined or at least a figure to be multiplied by the randomizer. something along those lines would do.

about the deceasing rewards based on activity. im suggesting something like that to be implemented in the future when the coins has more users. not now. definitely not now. by adjusting rewards based on activity, as the network grows more can be accommodated. if you think about it rewards grew but also users and miners grew so it is just adjusting to the increase and therefore not really an increase of what you can mine but just giving everyone a chance to still earn mining even as more users and of course miners come in.

we cant really implement it if there are not many merchants accepting the coin yet. otherwise rewards would be almost nil.

It's curious that while you were writing that I was editing my post with part of the exact same idea

I guess every coin should have something more than only algoritm,  what really magi coin does?  I read about magi pay, is this works?   Where can I pay by magi coin? 
Before coin have no real value - it is not a coin and just an air.
I hope devs will do more in real life with this coin after fix fork issue.

I think a 12 hour average might be enough, in and of itself. It would certainly eliminate hopping, I would think, and benefit loyal miners. Of course, the assumption is that it would be something like DigiShield, just slightly modified. But, then again, if block discovery time is longer as diff climbs, that is already a reward reduction, isn't it? So the two together are somewhat redundant. Not sure about this. Thinking out loud as it were.

Here's a reddit post on DigiShield: https://www.reddit.com/r/Digibyte/comments/213t7b/what_is_digishield_how_it_works_to_retarget/

Also, with regards to increasing rewards with increased network activity, and the opposite, decreasing rewards with less activity (not sure if I've correctly understood what's been said on this, so if I've misunderstood, just disregard this), AidBit tried that and died a fairly quick death.
https://bitcointalksearch.org/topic/annaid-aidbit-digital-currency-redefined-powpos-groestl-charity-683317

Glad you've got interested into buying Magi, mate. Believe me, it will be the best investment you'll ever make as the coin has managed to rise in value over the course of time. With its friendly community and active development, it will survive for many years to come.

The latest improvements for Magi, will make it more robust and popular towards helping it soar all the way to the moon. In addition, Magi is ASIC resistant, making it easy for anyone with an average PC or low powered device, to start mining some coins. I've been mining XMG within my smartphone for a couple of days and have obtained quick results unlike many altcoins out there.

Nevertheless, if you take the time to research more about the Magi project and make the right decision with your investment, you may become successful with this exciting cryptocurrency for many years to come.

Somewhere along those lines. But, let's see what Joe has to say about those ideas. As long as a random factor (whatever that factor is) is not present, by having the source code anybody with some degree of programming knowledge can tell 100% accurate the value of the block. Unless I'm missing something.

you might be right. anyway its an idea. my coding skills aren't really good. Just what i learned in high school from a 3rd world country who still uses pascal programing in school.

i havent really checked a blockchains code but i recon you can use the last alphabet or number in a hash to generate a not really so random number for a reward or maybe use a time stamp if blockchain keeps those. But since the time or the hash is random so its as good as a random reward. then use the last 24 hrs supposedly reward multiply by the random number as a multiplier of sort. if that is at all possible.

its just one idea. if you know how to code you can probably give some insight if its possible or maybe suggest something that is possible to solve the big hash rate miners problem. Its always better to have more minds that just one. It would benefit us all anyway

Not sure if this is feasible. It's not possible to gather network consensus on a random number. All nodes would have to blindly accept the block rewards "suggested" by the miner.
It would be easy for someone with less good intentions to change the source code to give one the maximum possible block reward within the limited validations other peers can make.
But Joe is master on this and maybe can tell us if this is so?

EDIT: ...unless the random number is not so random, e.g., deterministically derived from the last 2-4 hexadecimal digits in the mined block hash.

either that or a randomizer and then paired with another idea about the reward which should only be implemented in the future when the coin matures a bit more.

The idea is to make the reward directly related to the transaction volume or value whichever you think is best. We do like to keep the fees low but instead of charging higher fees and giving it to miners as compensation reward can be directly proportional to the fees or value or just volume of transaction per block. So the more the network becomes alive the more you get from mining. The less movement the less reward. Traditionally reward has never really been directly related to transaction volume or value. mostly fix reward or based on hash with this coin.

This way the more we use the coin the more reward we get. We stimulate the use of the coin since we directly profit from it. Botnets who dont really spend the coin just send to a exchange to convert will lose interest if we make reward based on transaction volume. Well they may wise up and break up the sending to exchanges in a lot of batches as well.

But if we think about it its more logical for rewards to be directly related to transactions volume or amount than just plain old hash. but it is better than just a fixed number like most other coins

i thought about that also. it would be the simplest fix. but joe still like to control the numbers based on hash. And i kinda like the idea that hash affects the coins as well. If the numbers were anywhere in 1-11. those who deem it profitable will just stay and mine. botnets or not. This is just a partial solution. Joe was on the right track with the hash rate adjustment. But it just needs to be unpredictable to be a more complete solution. with that said its really up to Joe. But i really think adding a randomizer will make this coin truly stand out and become closer to a coin for everyone. No need to make it solo mine only or whatever. The randomizer will at least deter those flash miners who jump in and out with high hashrate.

Actually, I like the idea too. Sometimes a complicated problem can have a very simple answer. What if the block reward will be a random number between 1.00 and 11.99? Doesn't matter what was happening in the last 2,3 or 12 hours. It cannot be predicted.

ive been busy lately so havent been on the forum. But been thinking of a way to contribute an idea that could possibly fix this POW hash rate. But this idea of mine is very complicated to actually code. You will need to code a randomizer which will also have an total average. Im not saying Joe cant do it. But I imagine it to be a daunting task. Computers really dont like random numbers.

and like i said in the past rather than complain its best that we try to be constructive and think of ideas to solve something instead of just restating a problem that everyone already knows about.

This is really a jolly good idea. Maybe just thinking a bit (or byte) more, but this can be the start of a definite solution, good thinking.

Dont get me wrong i am supporting any solution to make this coin as decentralized as possible specially for mining POS and POW. But let me share a few things on my mind.

1. 0 POW blocks and low rewards are almost the same effect.
2. Instant adjustment- immediate next block penalties weather low reward or POW cancel will give big hash miners another variable to contend with. They can flash mine then leave the next block but it will be more troublesome for them and it would be painful if by some chance someone else got the block before them. This would actually add a deterrent over the current implementation of slow adjustment spread over several blocks.

Then i would like to present an alternate solution that can be used.

1. let magi reward fluctuate and be random to some degree but following an average depending on network hash for the last 12 hrs or so. The randomness of the reward but with a target average would benefit miners who mine long term and not botnets who only jump when reward is high and leave as soon as it is low. Because rewards go up and down they are left with one choice. Continuously farm or not to farm at all.