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

Wow nice game and nice reward 
But what do you mean "fastest"? The lowest time or the lowest moves? 

Did post it in a tweet, not using FB anymore.

Thank you very much Digithusiast, great work. 

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.

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.

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.

Wow nice! Awesome job Digithusiast.

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.

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.

Thanks for that Feldenthorne.

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.

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

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?

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!

Working together. Awesome to watch this!
Well done!

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

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.

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

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

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