it is reportedly working on hawaii based cards (290, 290x, 390...), apparently NOT working on rx series (polaris), NOT faster than opensource on tahiti (280, 280x...)

And (max_coins - mined_coins)  should equal the balance of the coinbase account.

I have 50 connections on my daemon. You might have some software or hardware firewall blocking the connections.

someone did it already.
but it's only part of the story: you need to adapt the software to the different getblocktemplate results.

you are right.
maybe it's that space:

x.x.x.x: 8252

-s is a commandline option of the miner.
rpcallowip = ip (or subnet) of the machine with the miner

The upfront cost does not change things that much. It only blocks small miners, but bigger farms will buy it and make the difficulty rise, to the point it's not profitable for them any longer, 'cause they battle each other.

WALLET IMPROVEMENT PROGRESS UPDATE

I want to increase the max trie slice size. That is the maximum size of the pieces of accouting sheet, that are requested by a syncing client, and sent by its sync peer back.
I think that will improve the initial sync a lot (because that's where it usually stops). It will also reduce load on both machines, as they will do less operations.
The problem is that the change may introduce additional issues if the wallets aren't updated soon enough.
That is, unless I want to make a new protocol version and all the stuff that is needed to deal with two different protocols together.
But maybe it's a non issue, because the old clients do not need to get those trie slices (they just get the new full blocks), and the new one will use the new wallet.
Same if you use the blockchain snapshot: you don't need trie slices in that case.

What do you guys think about this matter?

coinbase * 243*COIN+10*CENT / MAX_MONEY

listen=1 may not be enough, you may need to open the right port on your router/firewall or use upnp.
I found out that ccminer doesn't like -s=1 and prefers -s=2, at least on my rigs.

yes but you may need to add other options, depending on your setup.

yes there are some "tricks":

- allow incoming connections
- compile your own wallet with optimisations for your cpu (-march=native -O3)
- mine with "-s 2" (getwork expire in seconds)

void mpz_set_uii(mpz_t &mpz, uint64_t v){
    mpz_import(mpz, 1, -1, sizeof(uint64_t), -1, 0, &v);
}

uint64_t mpz_get_uii(mpz_t &mpz){
    uint64_t v[16];
    mpz_export(v, 0, -1, sizeof(uint64_t), -1, 0, mpz);
    return v[0];
}

int64_t GetBlockValue(uint64_t coinbase, uint64_t nFees)
{
    mpz_t mcb,mquot,t;
    mpz_init(mcb);
    mpz_init(mquot);
    mpz_init(t);

    //Setup so half of coinbase distributed in ~10 years
    mpz_set_uii(mcb,coinbase);
    mpz_set_uii(t,243*COIN+10*CENT);
    mpz_mul(mcb,mcb,t);
    mpz_set_uii(t,MAX_MONEY);
    mpz_div(mquot,mcb,t);

    uint64_t value = mpz_get_uii(mquot);

    mpz_clear(mcb);
    mpz_clear(mquot);
    mpz_clear(t);

    return value + nFees;
}

Since you are on ubuntu, why don't you simply use gcc?

Calculator: when suprnova works, you can take its estimate and divide by two. Or, you can make a simple calculation: take your hashrate and divide by the net hashrate; a block of about 200 xcn of award is generated every minute, you will take your share of that, but you must take into account about half because of orphans and failed submissions.

Failsafe solo mining: ccminer doesn't support backup pools. If you know some scripting you can manage some crude form of automatic backup.

The qt wallet should close in some seconds.

Please post in the new thread:

https://bitcointalk.org/index.php?topic=1801595

Thanks! I just dropped a note to bitfreak. Meanwhile there is a link to your guide in the first post.

thanks! when it's ready, I will notify bitfreak so he can update the wiki.

Of course there is. Look in cryptonite.info

I do use code navigation and completion as well.
You do not need to import that, just run autogen, configure and make.