Test different network
hmm, what's the purpose? |
|
|
|
Magi should add on c-cex
better on bittrex, not c-cex. I agree with this; they list coin in a different way. All please tweet @ them and mention Magi XMG. Either we sort of need funds that will make it soon. PM me if some of you like to discuss this further. |
|
|
|
Magi should add on c-cex
We have the prior coin there for voting, sent message to ask for change. |
|
|
|
[Mandatory wallet update v1.0.0.2]- Please update your wallet before block 2700. This update is mandatory.
- Block rewards to maximum 300XMG/block
Downloads I have updated Suprnova to the latest version Thanks.  |
|
|
|
[Mandatory wallet update v1.0.0.2]- Please update your wallet before block 2700. This update is mandatory.
- Block rewards to maximum 300 XMG/block which will occur at a reduced difficult;
- Modified the PoS-II block initiated at block 10080 (about two weeks);
Downloads
|
|
|
|
|
ALL, we are going to do promotions though social networks, the tweet / retweet about XMG as possible as you can.
Follow us @CoinMagi
If you want to see magi in exchange, please tweet @ the exchange.
|
|
|
|
Dear Dev, When will you start to swap coins from MAGICOIN I? What's the way? Allow me to post info regarding the coin swap; you can read the OP too, swap was delayed to protect new miners. Prices are still very low for MAGI I on swisscex. I'm going to snap some up! Be cautious we're holding back the swap, no guarantee that way works you out. You may consider months investment in that. i dont understand why holding back the swap? arent investors in magi also investors in xmg. this makes it like there's 2 separate coins and those who bought in magi are left holding outdated coin? i do not think this is fair for investors? when can we expect the swap to be initiated. only then will magicoin price rise because there is no incentive to buy the old coins atm. To all new XMG miners, we didn't hear from our prior magicoin supporter before regarding the coin swap, but here is Coinler's opinion. It is fair that the opinions from our prior supporters should be taken care of too. So please make advice to the questions. |
|
|
|
[09/19]Some plansThis is the 5th day since launch; it won't be very necessary at this time to focus on big exchanges, but going forward, some works should be done upfront. 1) we are forging the marketing plans, one of those will be the better organization of twitter, facebook, reddit, and maintain regular updates; 2) plan to get on few more exchanges; swisscex and c-cex are two of them; 3) I've been in touch with some magi followers, some of them have provided us very nice supports; for example, ex33s offered us the dice game without asking for any bounties. Also someone mentioned working on Android wallets, while what he wants is to see the success of Magi. It's my pleasure to have them, and my work to make magi staying with user base like them. Among these tasks, block explorer and rich list will be a more urgent one since it is needed to get into coinmarketcap and most of exchanges (e.g., bittrex). I've contacted http://blockexperts.com about this, with a charge of 0.1 BTC to create and host the explorer. It should be done soon once confirmed. The following plans will be exchanges then. A public pledgeI'd like to send a pledge out for fundraising if you can help us. We current have limited access to magi funds since that is based coin swap, while coin swap has been delayed significantly. In some cases, BTC is needed to help promotion and importantly to get us on exchanges. Here we ask for your supports to carrier out various tasks: 1) Articles, media, video 2) promotions in social networks (registered PoA, promotion in twitter will spend some BTC too) 3) exchanges (likely somewhere to spend funds to promote and get people into this aspect) 4) reaching out people to apps dev (BTC will be likely an effective way of doing this) 5) and more ... Wallet address: BTC - 188AmugttD1jfy2xYNy6muTzVzYha1JEuq XMG - 95V9eZnrghtEriGUhBwwEuqMbDm1HBJ58u We will record all donators name, and BTC/XMG address. Your donation won't be completely free, rather we will return a portion in the form of BTC or XMG back to you later on, once we can, according to your donating weight. MagiTeamMagi team will be created coming out from the community. Magi had a good start, and will continue to grow. With few new features, cpu mining, coin distribution mode, and the PoS-II (we didn't talk about it much yet), magi will be a well-formed base to allow it grow up. Anyone who can contribute to magi, please contact me for bounties, or you want kindly donate your contribution (we will maintain a list for this for future disbursement when we have funds and are able to support). Anyone who is interested to join us please send me a PM; out of Magi already had, we welcome coin/apps dev to enhance this aspect. We will also reach out other coins for possible cooperation. Any suggestions to make magi better are welcome!
|
|
|
|
Dear Dev, When will you start to swap coins from MAGICOIN I? What's the way? Allow me to post info regarding the coin swap; you can read the OP too, swap was delayed to protect new miners. Prices are still very low for MAGI I on swisscex. I'm going to snap some up! Be cautious we're holding back the swap, no guarantee that way works you out. You may consider months investment in that. Are you guaranteeing a swap a some point? Will do swap for sure, but take time, no guarantee when swap will be done. |
|
|
|
|
Miners selling whatever they mined to cover cost is normal, while I suggest to hold back any comments at this time about exchanges; daily volume is only 0.x BTC, you can figure selling how many coins to get significantly depressing down the prices, that's quite easy, vice versa, putting 0.1 ~ 0.2 BTC buying order can easily pull it up.
|
|
|
|
Dear Dev, When will you start to swap coins from MAGICOIN I? What's the way? Allow me to post info regarding the coin swap; you can read the OP too, swap was delayed to protect new miners. Prices are still very low for MAGI I on swisscex. I'm going to snap some up! Be cautious we're holding back the swap, no guarantee that way works you out. You may consider months investment in that. |
|
|
|
I liked this coin because is was going to be CPU only, change and you will become a needle in the hay stack.
You cannot create fair mining coin to suit everyone as the job will be way too big and you will fail on all three areas.
What you have stated is a good end state, but we are live and you need to implement interim steps.
For what it is worth I would recommend the following :-
1. Update algorithm to exclude GPU's - Memory coin could do it so why can't we!!
2. Update algorithm to address large hashing power with some sort of split mining.
3. Introduce GPU mining.
The point is that you do not have an army of programmers and each move, like a game of chess, has to be a careful one.
As you can see people want a CPU coin so work on this!
I am sure your points to keep us to be safe as a CPU coin, while as far as I know, there is no GPU miners. The above approach is a "soft" control as we planned but not well functioned so far since this is a new algo; this approach could also be a solution to botnet problem (at least in part). Thus far, I don't think of need to change the algo. |
|
|
|
[Update: an potential adjustment of block rewards - diff]Initial designWe have to go back to review the initial design. https://bitcointalk.org/index.php?topic=735170.msg8755719#msg8755719 Predicted consequence is fair distribution, avoiding big mining farms and maintaining the network hash under a certain level (unlike BTC network keep increasing). It will frustrate mining farms (if existed) when network hashrate is so high that the mining rewarding is at the decline side. Mining XMG is less profitable compared to mining others; only belivers keeping mining will receive the most out of it. Same frustration applies to GPU miners if they existed. 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. IssuesNetwork 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: Suprnova Workers: 244
Nonce-Pool Active Workers: 183
total works: 427
Total network hash is about 105 MHps.
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? Solutions1) 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 Group A - CPU individual miners
Group B - CPU farms
Group C - GPU miners & farms 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. Am amazed no one has replied to the DEV yet, a shame to see the thread disintegrate into discussions of how much coins are selling for on exchanges already. You guys need to take a long term view not look for instant payouts ! Joe, I like your thinking which is enforcing the original design such that a high overall hash cripples the payouts. There are only two problems I see; If you can identify(2) and don't mind the extra mining duration of (1) then go ahead and tighten the block reward for excessive network hash. I have a few ideas for how to prevent the mega-miners, but unfortunately they would have to be baked into the coin design at the start, your suggestion above is the best I can see at this stage. Thanks for feedback, db6. 1) This would probably extend your phase 1 POW past the intended 2 months because it will take a while for the CPU farms/botnets to abandon the mining, after all they are doing nicely right now so they don't have much incentive to give up quickly. This means coin rewards will be disbursed more slowly than intended until the mega-miners abandon it. Change to the decline side in the figure needs to be done (will make another distribution curve), in order to make the decline much faster than what it is now. Let's think about an extreme case, #A+#B gets 0 rewards; I can see #B might quit very quickly as #B can't afford loss when getting 0 return. Situation could be very different as to #A, since #A (many individual miners) can afford the loss somehow (we've seen people in sole mining keeps mining without find a block; we call this "mining involvement" ). 2) How do you distinguish between (a) a lot more solo miners joining your network as word spreads, and (b) one high hash-rate farm ? This question is very most important in a real case. We can't distinguish #A from #B actually, what we need to know is the hash power #A might have, let's say 50 MH/s. Assuming a CPU yields 50-100 KH/s, that amounts to 500 - 1000 CPUs. So we will pre-target a 500 - 1000 user bases among which XMG will be distributed. Practically one may have few CPU running, so we may consider a tolerance, say targeting 75 MH/s where we get maximum rewards. In this way, we actually don't deny big miners much. For example, #A has 50 MHs, that allows additional 25MHs from #B. That is actually reasonable since one who is able to get more hash power has the right to get more returns. The example is a lot though; some optimization needs to be done in the real case. But the approach does deny many big miners taking over, so does the GPU miners. This is the key. would like to know if you have additional ideas might consolidate the plan here further. |
|
|
|
Dear Dev, When will you start to swap coins from MAGICOIN I? What's the way? Allow me to post info regarding the coin swap; you can read the OP too, swap was delayed to protect new miners. |
|
|
|
OMG, yesterday 60000sat, today someone sell 5100, what a fu**ing idiot!!!
after dev made a new post, then the price go down  cause somebody know there's more coin coming, they can make profit even at 5100sat This was actually stated in the OP as PoW phase I, but looks like most of people ignored reading the OP.  |
|
|
|
OMG, yesterday 60000sat, today someone sell 5100, what a fu**ing idiot!!!
Volume is little, can be easily manipulated, no worries of changes when volume is at this level. Edit, look at the top of sell and top of buy, you will figure out what's going on. |
|
|
|
What is this error???!!!
*
We are investingating issues in the backend. Your shares and hashrate are safe and we will fix things ASAP.
Findblocks disabled, new blocks will currently not show up in the frontend
Payouts disabled, you will not receive any coins to your offline wallet for the time being
*
No worry, every thing is under control except they have issues with the payout I guess, be patient. |
|
|
|
[Update: an potential adjustment of block rewards - diff]Initial designWe have to go back to review the initial design. https://bitcointalk.org/index.php?topic=735170.msg8755719#msg8755719Predicted consequence is fair distribution, avoiding big mining farms and maintaining the network hash under a certain level (unlike BTC network keep increasing). It will frustrate mining farms (if existed) when network hashrate is so high that the mining rewarding is at the decline side. Mining XMG is less profitable compared to mining others; only belivers keeping mining will receive the most out of it. Same frustration applies to GPU miners if they existed. 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. IssuesNetwork 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: Suprnova Workers: 244
Nonce-Pool Active Workers: 183
total works: 427
Total network hash is about 105 MHps.
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? Solutions1) 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 Group A - CPU individual miners
Group B - CPU farms
Group C - GPU miners & farms 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.
|
|
|
|
|
Show Posts
