Any ideas? Thanks!

Hi All,

I'm having an issue that I don't think I've previously had (i.e. before v1.4.5.3). It looks like coins that are staking are unavailable for sending. magid getbalance does not show them in the balance, and magid getinfo shows the same "balance" as magid getbalance, with the remaining coins showing in "stake".

When trying to send more XMG than I have in my "balance" (but less than I have in total), I get an error that there are insufficient funds.

Even if I restart magid with staking off in the config file, the coins are still stuck in "stake". It seems like the only way to use these coins is to wait.

What is the way around this? How can I send coins that are currently stuck in "stake" and/or prevent them from being unusable while staking?

Thank you.

Wasn't that a design goal of the coin?


This proposed solution is to make so many coins through hyper-inflation that it loses its value, and people stop mining it. This sounds to me like the end of the coin. What will bring value back after people stop mining it, when there are still millions(+) of already-mined coins out there?


This is currently how the network works. On an individual level, with an anonymous and decentralized currency, this is not practical (someone with high hash rates can just create multiple low hash rate instances).


Doesn't this trade mining power for node-hosting power? In any event, you have the same problem as above: Let's say that the minimum system requirements for a "node" is one Raspberry Pi Zero. Someone with the power of 1,000 Raspberry Pi Zeros can just divide their computing power to run 1,000 nodes, and earn 1,000 times a single Raspberry Pi Zero.

Mining, as it stands, is basically a lottery anyway, but people with more tickets (computing power) have a higher chance of winning. In addition, Magi has the built-in protection that as more tickets build to the next drawing (current network hash power), the reward for winning goes down. As such, it creates a communal incentive not to overload the network.

I'm not a Magi developer, but it seems to me like the basis of the coin was not that every miner gets an equal reward, but rather that everyone on the network needs to work together in order to make it worthwhile to be part of the network. As a result, there isn't much to do for someone (or some groups) who brings a lot of hash power to the network, other than to hope that they give up. Maybe that was a flaw in the design, but that is the design...unless I'm missing something.

I would also add that people are complaining about low block rewards, but forgetting how much value 1 XMG has gained over the years. Would you rather 40 XMG worth (for example) a total of $0.01, or .4 XMG worth a total of $0.60? Lower block rewards due to higher network hash values means reduced availability of 1 XMG, so the overall value per coin should go up (if people find value in such a coin).

Is there a way to import multiple private keys without triggering a rescan for each one? This seems to be a feature of later BTC-based wallets. Thanks!

There is no "expected time..." line in the getinfo output...

Any way to check via the command line?  Didn't see anything in the header files.

In the end, I joined a pool...and since then, I've mined four blocks worth 55 XMG, and I've earned a touch over 6 XMG, before fees...Not the most encouraging of numbers..

Set auto-save to 1 minute and save often!

The problem with that is that running on the PPE doesn't mean it'll run on the SPEs.

It looks like there was a BTC miner developed for the PS3/SPEs called "Cellminer".  That might prove to be a nice starting point.

Looks like you're still a ways off.  Have you installed the Cell SDK?  To my untrained eye, it looks like you're running on the PPE, not the SPE, which effectively means you're not running on the processing elements that you want to!

That doesn't touch on the issues you're having - but you might find that things start to come together when you get all of the pieces.  (You will need to recompile everything - minerd + dependencies - for the SPEs.)

I am running the latest client, v1.2.1.1.  I don't have any coins in my wallet (or at all ), so perhaps this is a result of there being "nothing to stake"?

I see it quite frequently.  I'm not constantly monitoring debug.log, but it seems like whenever I check it, I can find these sorts of errors.

Is this a local issue, or the blockchain keeping itself sane?

Hmm.  This is all interesting to consider, but I do have my thoughts about the decentralized nature of the currency compared to the centralized nature of pools.

I'll probably give pools a go at some point as well.  I think that both are interesting from a learning perspective.

A month?!


I know this isn't real-time, but it should mean that pulling a few khash/s should yield >1 block/week, no?

I think that my solo mining config is correct..I have magid running and receiving blocks, and an independent miner connected via local RPC and computing hashes.

That said, I'm still a little confused by how everything is connected, e.g. how this somehow leads to blocks being verified, etc.

Anyway, I wanted to start without a pool because that seems to be one of the primary motivations behind this project - that you don't need to be part of a large pool in order to contribute/benefit.

As I understand it, the benefit to joining a pool is that I will receive continuous fractions of blocks based on my computation share.  Assuming that my hashrate doesn't change, then on average it will take me x days to receive y XMG, regardless of whether I am in a pool or not.  Given that the time to mine a block is within reach for a solo miner, what is the benefit to joining a pool?  (I'm asking out of honest curiosity, not trying to defend one way vs. the other!)

I'll hang around here and hopefully not repeat too many questions, then

Ah, good to know.  I figured the same basic source would be in both, and was wondering why the instructions would recommend a separate process then.


Fair enough - hopefully some of the key information will be available on the site with the relaunch.

Thanks!  Glad to see CPU mining is back, and it looks like a friendly community, too!

Is there a forum beyond this one massive thread?  It's a bit..hard to keep track of?

Thanks

Hi All!

I just started mining Magi yesterday - it's the first cryptocurrency I've ever mined!

Since I'm new to the field, I have a few questions.  I have some experience with *nix, parallel processing, and some programming, so I'm not starting completely from scratch.

First, since I'm mining on Linux (Ubuntu 14.04), I mostly followed this guide: https://bitcointalk.org/index.php?topic=735170.msg8800103#msg8800103

I'm solo-mining to start, so I went until the end.  Step 9 caught me off-guard, because when step 10 didn't work, I realized that I had to download the entire blockchain, which took a few hours.  I think they missed that part in the tutorial!

Afterwards, I looked into Bitcoin API commands, since the wallet is based off of the original BTC client.  I found that there is a "setgenerate" option.  So this raises the question of why I'm running a separate minerd on the same machine, if the wallet daemon itself can mine?  Is there an advantage of one over the other?  I compiled both independently.

Speaking of compiling both on my own, the pre-built Linux package didn't work because it was dynamically linked.  Maybe it would be better to static link in the future?

Next, every now and then I see blocks come in with the following result:

Is that something going wrong, or is that normal?  (Also, is there anything personally-identifiable in there that I should edit out?)

Finally, how does the wallet work exactly?  I understand that it stores the private keys to the public addresses that I can publish, but how do coins play into it?  What specific (private) data do I need from a wallet.dat backup in case of data loss, and what is recoverable from the blockchain?

Thanks!