Yesterday Magi team had a talk about the future of Magi and the improvements. In our main thread and on other forums our Magi community members gave some great ideas. Our awesome dev is working on those ideas to integrate them in the improvements and updates. With the coming updates & improvements it might be the most important step forward for the future of Magi. Magi team appreciate the patience of our great community and will try to make you all very happy with those updates/improvements. I can not give details yet but I can tell that the team listen and looked very good at the advices (from example Cryptonit & others) and the latest developments in the Crypto-world.  Magi will become 2 years old at 15-09-2016 and time has come that we give Magi a huge boost and continue to grow further in the world of digital currencies! Keep your eyes on the threads and other social media! Thanks for promos; I hoped some are really & actually done. |
|
|
|
Is this only a cpu mineable Coin? could mine with GPU?
My hashrate is 4 Kh/s with core i7-6770 equal to 0.22 Magi daily. Is this okay?
It is very far from Profitability with cpu mining.
4 Kh/s from i7 is significantly off; make sure you have the right miner. Is this only a cpu mineable Coin? could mine with GPU?
It IS CPU mineable; the reason why I am saying that is we're yet to leave behind by big miners. However, must to be frank, I was told by professionals that mining with GPU is likely, though nobody is claiming, less interested or something else, don't know. It is not clear that existing GPU mining or not; it may be clear that CPU mining could go marginal at some time, though I don't have the first-hand information at this point as to comparing with other CPU minings. In either case, you'd be better to mine a while to get to know about magi. It is less likely to completely reject big miners include GPU, FPGA things, botnets or whatever; but it is likely to frustrate these things. How to EFFECTIVELY get the frustration onto them is yet to be done. One thing I am sure and what we must declare is that magi would go less pointing without taking the mobile mining as the formost purpose, and that IS a must go and what I intend to do to tackle, in order to be useful in a certain way. |
|
|
|
Sorry for long delay. I'm working on it heavily since most recently; spent much more time on looking around before hands-on, and trying to get done what'd be asked; will have some posted out I guess. In either way, no ETA and details to be done, that would put me under pressure.  Will it include COMPLETE binaries set, not only the part of it like today?
Yes, that's for sure. No problem Joe. Take your time in developing a new fresh wallet for XMG. As long as it remains usable, and stable enough to keep it staking, it shouldn't be an issue. I've been a little away from crypto, but I could say that things are going well for the crypto world. Usually when BTC price goes up, other alt coins follow but XMG has remained stable (except that the price has plummeted a little recently) which make it good for investing. Appears a strong correlation between XMG and BTC price.  |
|
|
|
After few runs, I was sort of not able to find way to tolerate the slow startup, so looked at it and realized this can readily be done; so I pushed a github branch 1.2.3 there, in case one needs to have a speeding wallet right away. https://github.com/magi-project/magi/tree/1.2.4rcWhat's needed is to re-download the whole blockchain (delete block data & make a backup of wallet.dat). I won't compile a complete set of binaries at this time cause this is not final. I'd like to purse an even faster startup wallet, that would be v1.3 branch. Let me know if one needs a binary. will it work if we use this https://bitcointalk.org/index.php?topic=735170.msg14645889#msg14645889That is the original block data; we'll need a one with block hash recorded, by re-syncing or I can get that at some time. |
|
|
|
thx for ur statement joe i share the opinion that wallet startup time is medium but POW/POS optimisation is high priority selfadjusting POS (split and merge coin pile deepens on coin age and coin size) here i can support u if u want to see how it works in DMD i think the way XMG is set up u can split everything that stake below 4 days coinage and merge above 4 days but only coin pile below size 300 up to a max of 300 this will lead to a zero micromanagemant by user required POS network where we have a nice stable POS diff and most coin pile in network are in a size between 100 and 300 optimal in my opinion regarding balance of coinrollout i would shift more from POW to POS because POS mostly create BUY pressure (because u need coin to generate coins) and POW most of the time sell pressure special in the way it can be abused now update: did check ur source a bit https://github.com/magi-project/magi/blob/master/src/wallet.cpp#L1586basical u have all u need u just need to adjust value ncombinetreshhold to 300 and dont add coinpile as addtional input which are below 4 days age or above 300 size and u should be fine Thanks & noted for this, that's more interested than speeding up. It was loading PoS blocks that takes time, in addition to the PoW, during which hash (magi) was calculated and pulled up at the start-up as well. As I can see the latter was sort of avoided by saving bockhash on disks in DMD. This can be done, but not so quick to be done. I'll get this modification skipped for now until other urgent things are done. Try to get a new wallet first, and then turn to PoW & PoS ASAP (not the merging staking part, but something else like I've to clean up the PoS model).. After few runs, I was sort of not able to find way to tolerate the slow startup, so looked at it and realized this can readily be done; so I pushed a github branch 1.2.3 there, in case one needs to have a speeding wallet right away. https://github.com/magi-project/magi/tree/1.2.4rcWhat's needed is to re-download the whole blockchain (delete block data & make a backup of wallet.dat). I won't compile a complete set of binaries at this time cause this is not final. I'd like to purse an even faster startup wallet, that would be v1.3 branch. Let me know if one needs a binary. |
|
|
|
You are right indeed. As it is not about the prices of a crypto currency, but development and community to make it succeed, I would like to say that is has been doing pretty good when compared to other alt coins. I understand that dev is busy sometimes, but getting a new wallet is not very far than what I least expected. If we could get a killer new GUI for the wallet, then I would certainly make XMG rock! Take a look for instance at CasinoCoin's wallet and see for yourself the new and improved GUI. Something like that I would like to see for XMG. Just suggesting.  1. Wallet GUI does not change anything. More important is to provide complete wallet, with all the binaries compiled and possible to download from the coin homepage. Just like other coins and not only qt executable file like is today for XMG. 2. For me professional and fully involved dev team is more important that community making another pictures with XMG on it. Hello! What is ETA for new wallet? Will it include COMPLETE binaries set, not only the part of it like today? Thx. Sorry for long delay. I'm working on it heavily since most recently; spent much more time on looking around before hands-on, and trying to get done what'd be asked; will have some posted out I guess. In either way, no ETA and details to be done, that would put me under pressure. Will it include COMPLETE binaries set, not only the part of it like today?
Yes, that's for sure. |
|
|
|
I just got synced but my wallet has the error:
WARNING: Checkpoint is too old. Wait for block chain to download, or notify developers.
"version": "v1.2.3.1-magi",
"protocolversion": 71041,
"walletversion": 60000,
"balance": 0,
"newmint": 0,
"stake": 0,
"blocks": 815670,
This wasn't an error but a warning that will be fixed. |
|
|
|
I would NOT change some things about the wallet.
Magi has some features other wallets don't have:
Six (6) recent transactions is very nice.
The total balance line is good to have.
The staking info with approximate time to stake.
Also, I would never change the name or coin image
or colors.
It looks like maybe the numbers and letters could be
made just a little bit larger. The left side could be
stretched down some, or have something added below it,
like a coin image or graph. And a USD price conversion
would be awesome!
Surely the USD price conversion from within the wallet would be pretty convenient to keep track your profits in fiat for XMG. Also, it would be pretty cool if you could buy XMG right from the wallet without the need for an exchange. This would be similar to Shapeshift, but with the ability to exchange BTC to XMG instantly right from the wallet itself. Just sharing my ideas... That is a great idea. Imagine an in-wallet 'buy/sell' button which trades against the average XMG/BTC(or whatever currency) price...do any other wallets implement such a feature? Some do have; however imho going this way would be an off-topic for magi at least at this moment. Giving USD price can be a go. |
|
|
|
OK i have some questions about using m-cpuminer. I'm using the GUI version, trying to get it started. This is the info i'm working with: Solo mining: ./m-minerd --url http://127.0.0.1:RPCPORT/ --user RPCUSER --pass RPCPASSWORD --threads thread_numbers -e cpu_efficiency As i understand it, RPCUSER and RPCPASSWORD can be anything. But where do i put my magi address? Is the parameter -addr <magicoinaddress> ? Is RPCPORT a number, and how do i know what to use there? Maybe i'm missing something more here. Does the wallet need to be running and configured to solo-mine? I'm confused. I remember putting a wallet in server mode before (litecoin i think) to try mining. Hope you get the answer, or google will help that easy out; it's mining to wallet and wallet needs to be running. |
|
|
|
thx for ur statement joe i share the opinion that wallet startup time is medium but POW/POS optimisation is high priority selfadjusting POS (split and merge coin pile deepens on coin age and coin size) here i can support u if u want to see how it works in DMD i think the way XMG is set up u can split everything that stake below 4 days coinage and merge above 4 days but only coin pile below size 300 up to a max of 300 this will lead to a zero micromanagemant by user required POS network where we have a nice stable POS diff and most coin pile in network are in a size between 100 and 300 optimal in my opinion regarding balance of coinrollout i would shift more from POW to POS because POS mostly create BUY pressure (because u need coin to generate coins) and POW most of the time sell pressure special in the way it can be abused now update: did check ur source a bit https://github.com/magi-project/magi/blob/master/src/wallet.cpp#L1586basical u have all u need u just need to adjust value ncombinetreshhold to 300 and dont add coinpile as addtional input which are below 4 days age or above 300 size and u should be fine Thanks & noted for this, that's more interested than speeding up. It was loading PoS blocks that takes time, in addition to the PoW, during which hash (magi) was calculated and pulled up at the start-up as well. As I can see the latter was sort of avoided by saving bockhash on disks in DMD. This can be done, but not so quick to be done. I'll get this modification skipped for now until other urgent things are done. Try to get a new wallet first, and then turn to PoW & PoS ASAP (not the merging staking part, but something else like I've to clean up the PoS model).. |
|
|
|
hmm long time since the last post on this community, and it still alive the dev and team work hard to make it still worth to follow. And bump dev Joe was back too. Still believe in magi  best regards wakhidNkcom Man, glad you're sticking around. |
|
|
|
compared to before activity in this thread reduced by 95%
community was always the strong point of XMG
should i be worried?
and whats up with more infos regarding new wallet changelog and release?
DOTN WORRY, or you can. Obviously though I posted and committed to a look at the wallet code a while ago, I lied , sorry, and just started to seriously look at the coin until this week or so. There was a (long) story I'd talk later on... The first thing I'm about to conclude as of yet is that a quick-start wallet might not be the way (for now), unfortunately... Magi loaded 45,1055 blocks in 381s, and PPC is 23,5092 blocks in 242s (so I took an example for comparison), both are nearly at the same speed. The following is where a lot time is consumed at start-up -- all just read blocks from the disk; nothing else checking is done though: https://github.com/magi-project/magi/blob/master/src/db.cpp#L797I am aware that DMD has sort modified this section as you mentioned, and it appears there is a change in the blockchain from my quick look at this time. I'll look further then... In my general sense regarding changes to a quick start-up, I tend to be conservative, though, as I said, I'll take a close look before a definite conclusion is made... In contrast to above, I'm more concerned with the PoW & PoS with some really urgent works to be done, however each parts will just swallow a loooooooot time... Obviously a new wallet is planned, but don't expect too much. There was a huge blank gap already filled in-between the last update and what the Magi is now. All just require time to be taken... |
|
|
|
1 year no update for XMG.  That does sound embarrassed; I guess I have more time pulled out from work already. |
|
|
|
He amigo,
Magi had a meeting yesterday. Joe will work on a new wallet with more improvements.
It will take time. (because of his new Job and moving to another place)
In the mean time there will be a temporary new wallet what will be faster.
Hope that one will not take much time for launching.
OK. Two questions: - when this new it will be delivered? - whether new wallet (doesn't matter temporary or not) will deliver all binaries compiled? please answer my two questions [/quote] 1) Joe did not gave a delivery date yet. He told us hè will develop it but has not much free time because of new job and moving to another house/city. So we have to give him some time. 2) Think yes. For sure Joe noticed your request and hè will deliver those or respond on it. [/quote] Thanks for the info. But it is a little scary. One developer with no time. [/quote] Sorry for some uncertainties, seems like that this is the reality, rest assured trying to work out something. |
|
|
|
|
I have updated the pools. Thanks.
I have a shift to a new job that makes me somehow put most concerns on things elsewhere, trying to make something happening.
|
|
|
|
Merry Christmas everyone! I would purchase more for the PoI but XMG is not working on Cryptopia; I think they might need the daemon compiled for the latest version (as a guess). (Crypsy scared me away rather badly. ) A late wish Merry Christmas to all |
|
|
|
Been mining this on my RPi2, love it! Of thinking as to how to make pi mining better. |
|
|
|
Can somebody do a check-up on the Magi-wallet and find out what is the reason the wallet takes some time to start.
Would be good if Magi speed up the wallet.
Thanks in advance.
fast start is missing Fast start (QT opens in seconds as compared to mins), its basical a "improvement" that at startup just check less of blockindex and this way fullfill that part of startup much faster its no improvement just less startup checks Additionally, I was thinking that the slow start might be caused by a lot of transactions in the wallet too. The way PoS is set-up on this coin it encourages a lot of small value amounts to be generated. (This causes issues with the block explorers too if there are too many transactions in one address.) You can fix this by sending your coins to an address in a new wallet and retiring the old wallet. Maybe we should think about this a bit when we do the next update, if we had a command like “setstakesplitthreshold” or increased the minimum stake time, and added a block reward cap, this might help prevent so many small transactions from being made. Yes, we need merging staking. |
|
|
|
Of course PoS mining is hashing with SHA256 - but you're not doing it constantly. Secondly, the wallet mining is slower mostly because the code is old - isn't it still the original M7M implementation?
EDIT: Also, SHA256 is probably wasting so much time because you're probably using a slow one-way implementation of it - if you're hashing, you can probably use SSE/AVX to parallelize the different iterations.
These are all where we can put optimizations on.  Hi all, just got back from 3 weeks vacations in Thailand - was 100% off...Whats going on? Some new thing (most important)? What happened with price (big drop ) cheers y'all Welcome back! |
|
|
|
|
Show Posts
