[ANN] [XMG] MAGI | CPU mining | mPoW | mPoS | [MagiPay]

[light85bit]

You may have missed my reply to this

https://bitcointalk.org/index.php?topic=735170.msg10991465#msg10991465

No man, i read your reply, but like you said, it's easier for big miners than small miners to reduce the hashrate. An example is like me, I have 125KH/s, i can lower to 50KH/s, but how about another miners? If they stay the same, hoping for another miners lower, then they'll get more than another people?  Then after some days, i'll mine with full speed again Is there anyway to make ALL miners reduce their hashrate by half?  No i think 

The Magi community is growing exponentially. After some times, after some PoM campaign, the big miners will exit the Magi mining. But more and more small miners will join Magi. So the hashrate will rise. And the block reward will be always low. Is it an fictive scare or a real one ? The magical Magi team does has a wonderful solution for that ?

I have the same question too  

the way i see it the price of magi will rise and rise more when big miners go away, as it happened with many coins. High number of small miners/holders higher the price of coin few but big miners = doom and dumping of the coin (like with spreadcoin and many others).

cheers  

not just the price will rise, but the amount will lesser, so longer the coin will live, it's good 
But what if too much more miners that the amount reduce to ~ 0XMG per block?  We'll have to wait wait wait until enough miners goes away? What if everyone think like that and stay? 

[111magic]

Announcement:
Registration for Magi Proof Of Mining 2015 campaign will start Friday, April 10th.
Keep eyes on thread or Twitter @103tango @coinmagi !

---------------
More info will follow.

[Spexx]

Can someone please explain me the PoS thing in simple words? I read a couple of articles but I don't really seem to understand it. In simple words, if I leave my wallet running will I earn more XMG?

Ok I'll try that, but it rather depends on whether you mean the Proof-Of-Stake campaign (now closed for entry) or proof-of-stake mining with the wallet. I will assume the latter.

Just leaving the wallet running is not quite enough. Every thirty days, you need to send all your coins to yourself to "renew" your stake. It all hinges on your incoming transactions and sending your coins to yourself generates, effectively, an incoming transaction which qualifies. Forget all the complicated mathematics, coin splitting etc. Does my head in. You will earn "interest" on the incoming transactions.

When you send all your coins to yourself, there is a short period when it has no value for staking purposes, but quickly grows over a few hours and you will see the "stake weight" reported by the wallet go up and up and up again over the next two weeks or so. I have observed the "stake weight" reach a value just about twice the total number of coins in the wallet after about ten days, stay up there for a while and then gradually decline. After thirty days the "stake weight" gets so low that you feel the need to send all your coins to yourself again. In that time, the wallet mines literally hundreds of individual small POS rewards, sometimes as often as once every few minutes and occasionally I have observed the wallet mine three POS rewards in under a minute. The value of individual POS rewards is highly variable. The biggest I ever got was about 0.33 XMG I think - memory fades - but generally I see rewards at about 0.01 XMG each, moreorless. What really changes is the rate at which the rewards are received. It goes up and tails off in the same way that the "stake weight" does.

I played around with sending a proportion of coins back and forth between two wallets, then experimented with sending coins around three wallets, in smaller twice-daily chunks. Nothing seemed quite as effective as simply sending the whole lot to yourself in one wallet at first glance, but when I crunched all the numbers it actually turned out that the "rate of interest" earned was about 2 percent equivalent APR on the total balance in the wallet(s) no matter what I did, just as long as I was generating incoming transactions and turning over the contents of the wallet(s) in a relatively short space of time. My conclusion with this is to keep it simple - just send the whole lot to yourself. It works like a charm. If you have a lot of coins then you may find that you cannot send the whole lot in one transaction, so split it into smaller chunks and send them to yourself at, say, ten minute intervals. If you try to send one chunk after another in quick succession, you will find that the transaction fees keep going up and up. Sneaky that.

Hope that was simple enough

[feldenthorne]

Someone reported a pretty bad blunder in the documentation in the GitHub repo: https://github.com/magi-project/magi/issues/7.

In short, Debian 8 (Jessie) removes libdb4.8 from the official repositories, which the wallets rely on to be built and several other build dependencies were missing from the build documentation.

I added the missing dependencies to the documentation in my pull request, but I didn't want to make the decision to change the Berkeley DB version for the official builds as well, since it will screw up the usage of wallet.dat between user-compiled and official versions. I do think, however, that it would be best to officially migrate to libdb5.1 for official builds because it's one more thing that will work out of the box for users.

(If the devs talk it over and want to bump up the version to 5.1, let me know and I'll add that to my pull request.)

[joelao95]

Someone reported a pretty bad blunder in the documentation in the GitHub repo: https://github.com/magi-project/magi/issues/7.

In short, Debian 8 (Jessie) removes libdb4.8 from the official repositories, which the wallets rely on to be built and several other build dependencies were missing from the build documentation.

I added the missing dependencies to the documentation in my pull request, but I didn't want to make the decision to change the Berkeley DB version for the official builds as well, since it will screw up the usage of wallet.dat between user-compiled and official versions. I do think, however, that it would be best to officially migrate to libdb5.1 for official builds because it's one more thing that will work out of the box for users.

(If the devs talk it over and want to bump up the version to 5.1, let me know and I'll add that to my pull request.)

feldenthorne, thanks for the heads up. Let's move to version 5.1. I shall build the binaries as well.

[feldenthorne]

feldenthorne, thanks for the heads up. Let's move to version 5.1. I shall build the binaries as well.

Alright, sounds good. That simplifies the unix build readmes as well since the ARM builds were using 5.1 by default.

For Windows builds, this will mean switching to build 5.1.29.NC from http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index-082944.html, since the previous dependency is 4.8.30.NC. Once you confirm that that's fine, I'll update my pull request.

[joelao95]

feldenthorne, thanks for the heads up. Let's move to version 5.1. I shall build the binaries as well.

Alright, sounds good. That simplifies the unix build readmes as well since the ARM builds were using 5.1 by default.

For Windows builds, this will mean switching to build 5.1.29.NC from http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index-082944.html, since the previous dependency is 4.8.30.NC. Once you confirm that that's fine, I'll update my pull request.

Yes, this looks fine, while I haven't yet done the compilation; will do so in the following days. 

[111magic]

Working together. Awesome to watch this!
Well done!

[joelao95]

Magi World Online Campaign!

Magi (XMG) the unique coin of the future
launches the Magi World Online Campaign
This multiple promotion campaign rewards current community members by receiving some extra XMG and offers new members the opportunity to become acquainted with the Coin of the Magi and receive their first XMG for free.
The tour consists of multiple assignments for which you can receive some XMG.

Check here: http://bitcoingarden.tk/forum/index.php?topic=3315.msg89738#msg89738

Thanks mate, this is ever unique social to the community. I am confident it only happens to magi because of our passionate and loyal supporting magi team member!

[vince232]

mining really is hard now. as i understand the bigger the hashrate is the lesser the reward right?

isnt it possible to limit the hashrate of an account.?

like for example in supernova you can only have 1 worker?

[joelao95]

mining really is hard now. as i understand the bigger the hashrate is the lesser the reward right?

isnt it possible to limit the hashrate of an account.?

like for example in supernova you can only have 1 worker?

Exactly; we're trying to get this option for PoM.

[feldenthorne]

feldenthorne, thanks for the heads up. Let's move to version 5.1. I shall build the binaries as well.

Alright, sounds good. That simplifies the unix build readmes as well since the ARM builds were using 5.1 by default.

For Windows builds, this will mean switching to build 5.1.29.NC from http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index-082944.html, since the previous dependency is 4.8.30.NC. Once you confirm that that's fine, I'll update my pull request.

Yes, this looks fine, while I haven't yet done the compilation; will do so in the following days. 

Alright, my armv7l_official branch (the one that's pull requested) has been updated to build with BDB 5.1 by default. It compiles and works on x86 Ubuntu and ARM v6 and v7. Not sure about Windows or OSX, but I updated the documentation and makefiles for everything with the proper package names. So it needs testing on OSX and Windows, but I think it should be good to go.

[111magic]

Thanks for that Feldenthorne.

[Spexx]

No man, i read your reply, but like you said, it's easier for big miners than small miners to reduce the hashrate. An example is like me, I have 125KH/s, i can lower to 50KH/s, but how about another miners? If they stay the same, hoping for another miners lower, then they'll get more than another people?   Then after some days, i'll mine with full speed again Is there anyway to make ALL miners reduce their hashrate by half?   No i think  

I do think that one important development in this respect is Sweet Spot targeting. I have been using it for some time and you will see my hashrate on the pool(s) going up and down as the block rewards get bigger and smaller respectively. It saves on my electricity bill, but better than that it is "one in the eye" to the big miners. When block rewards are low, let the big miners thrash away at it for peanuts, then when the bigger block rewards come along, give them some serious competition. I love it. Large numbers of smaller miners using this kind of targeting will have a significant effect.

[vince232]

No man, i read your reply, but like you said, it's easier for big miners than small miners to reduce the hashrate. An example is like me, I have 125KH/s, i can lower to 50KH/s, but how about another miners? If they stay the same, hoping for another miners lower, then they'll get more than another people?   Then after some days, i'll mine with full speed again Is there anyway to make ALL miners reduce their hashrate by half?   No i think  

I do think that one important development in this respect is Sweet Spot targeting. I have been using it for some time and you will see my hashrate on the pool(s) going up and down as the block rewards get bigger and smaller respectively. It saves on my electricity bill, but better than that it is "one in the eye" to the big miners. When block rewards are low, let the big miners thrash away at it for peanuts, then when the bigger block rewards come along, give them some serious competition. I love it. Large numbers of smaller miners using this kind of targeting will have a significant effect.

hey is that sweet spot targeting already available for download? that is why i stopped mining. i saw the block rewards as low as 0.8 i think. there is no point mining right now if you only have 1 miner.

[111magic]

In order to spread the word about Coin Magi, there is now a puzzle contest with a XMG 1,000 prize available on http://www.coinmagipuzzle.org/
The idea is to have as many Coin Magi supporters play the game and submit their score, so their record score is shared among friends on Facebook.
Please do not set a worldrecord right away, as that will demotivate others to give it a try, and the goal is to get as many new people as possible get to know Coin Magi!

www.coinmagipuzzle.org

Wow nice! Awesome job Digithusiast.

[feldenthorne]

Another new wrinkle in the BDB updating:

I was reading the packages for Debian incorrectly (and it was pointed out on GitHub)- libdb5.1-dev is only available by default in Debian 7 (wheezy), not Debian 8 (jessie). I really don't know how you'd like to handle that as a dev team. Debian 7 is the "stable" release and Debian 8 is the "testing" release, but I really don't know much about the usage statistics for Debian in terms of what version is more popular.

Since Ubuntu 14.04 and Debian 8 both default to using BDB 5.3, though, it may be a reasonable option to just shoot for BDB 5.3 as the actual upgrade choice. Debian 7 users can also use the backports repositories to download libdb5.3 reasonably easily, which means that Ubuntu 13 (and even 12 LTS, I think) users can also compile with minimal effort. I also checked the Raspberry Pi repositories and it appears that armv6l and armv7l both have access to libdb5.3-dev libraries as well (which makes sense since it's based on Debian, but it wasn't certain). And Gentoo and FreeBSD appear to have libdb5.3-dev too.

Windows and OSX can use the easily-accessible BDB 5.3.28.NC release from http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index-082944.html, so the two more prominent platforms should have no problem either.

This time my research into package availability was a little more extensive, so everything should work out if you decide on BDB 5.3. But that will inevitably force people that are using older Linux releases (however many there are) to compile the BDB libraries themselves. If they're on older releases, though, they're probably more comfortable with compiling... But it's also another hoop to go through.

Some community input on this might be best, to determine if this will affect anyone enough to take them out of their comfort zone... But I suppose upgrading to BDB 5.1 could have had the same effect.

In the end, though, it's your choice as developers to make the call. I can revert to BDB 4.8 if you'd rather stick with that, keep it at 5.1, or rework everything for 5.3. Just let me know.

[Spexx]

hey is that sweet spot targeting already available for download? that is why i stopped mining. i saw the block rewards as low as 0.8 i think. there is no point mining right now if you only have 1 miner.

Sweet Spot ...

http://xmg.makejar.com

... plus I will release my bolt-on variant in a couple of few hours time. Just applying finishing touches now.

[joelao95]

Another new wrinkle in the BDB updating:

I was reading the packages for Debian incorrectly (and it was pointed out on GitHub)- libdb5.1-dev is only available by default in Debian 7 (wheezy), not Debian 8 (jessie). I really don't know how you'd like to handle that as a dev team. Debian 7 is the "stable" release and Debian 8 is the "testing" release, but I really don't know much about the usage statistics for Debian in terms of what version is more popular.

Since Ubuntu 14.04 and Debian 8 both default to using BDB 5.3, though, it may be a reasonable option to just shoot for BDB 5.3 as the actual upgrade choice. Debian 7 users can also use the backports repositories to download libdb5.3 reasonably easily, which means that Ubuntu 13 (and even 12 LTS, I think) users can also compile with minimal effort. I also checked the Raspberry Pi repositories and it appears that armv6l and armv7l both have access to libdb5.3-dev libraries as well (which makes sense since it's based on Debian, but it wasn't certain). And Gentoo and FreeBSD appear to have libdb5.3-dev too.

Windows and OSX can use the easily-accessible BDB 5.3.28.NC release from http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index-082944.html, so the two more prominent platforms should have no problem either.

This time my research into package availability was a little more extensive, so everything should work out if you decide on BDB 5.3. But that will inevitably force people that are using older Linux releases (however many there are) to compile the BDB libraries themselves. If they're on older releases, though, they're probably more comfortable with compiling... But it's also another hoop to go through.

Some community input on this might be best, to determine if this will affect anyone enough to take them out of their comfort zone... But I suppose upgrading to BDB 5.1 could have had the same effect.

In the end, though, it's your choice as developers to make the call. I can revert to BDB 4.8 if you'd rather stick with that, keep it at 5.1, or rework everything for 5.3. Just let me know.

This is a thing I didn't notice; I checked my Mac os compilation which acutally used the version 6. I agree that we should stick to one version. It is likely that the future release of linux (debian and else) steps into more than 5.3. It won't be a big concern if the wallet gets updated by that time as well; let me check it out and fix the way we should take.

[joelao95]

In order to spread the word about Coin Magi, there is now a puzzle contest with a XMG 1,000 prize available on http://www.coinmagipuzzle.org/
The idea is to have as many Coin Magi supporters play the game and submit their score, so their record score is shared among friends on Facebook.
Please do not set a worldrecord right away, as that will demotivate others to give it a try, and the goal is to get as many new people as possible get to know Coin Magi!

www.coinmagipuzzle.org

Thank you very much Digithusiast, great work.