◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈

[dragos_bdi]

https://github.com/bitcreditscc/bicreditsnew/blob/bb21fcb8bcf5dbc43e89eca6996f51e19d116479/src/main.cpp#L2158

>=50000*COIN

[bitcreditscc]

https://github.com/bitcreditscc/bicreditsnew/blob/bb21fcb8bcf5dbc43e89eca6996f51e19d116479/src/main.cpp#L2158

>=50000*COIN

What would be rationale behind that...? I mean from a technical PoV? Having 50K is all wee and fine, but the reason i used > rather than >= was at that time i assumed that one would first spin up a BN then get at least one payment to prove they are an active BN then start mining. However users can get around that by simply sending 50000.001.

How can we resolve this ?

[dragos_bdi]

https://github.com/bitcreditscc/bicreditsnew/blob/bb21fcb8bcf5dbc43e89eca6996f51e19d116479/src/main.cpp#L2158

>=50000*COIN

What would be rationale behind that...? I mean from a technical PoV? Having 50K is all wee and fine, but the reason i used > rather than >= was at that time i assumed that one would first spin up a BN then get at least one payment to prove they are an active BN then start mining. However users can get around that by simply sending 50000.001.

How can we resolve this ?

if they send 50000.001 they cannot start a BN but can mine. (for a BN to be started it's needed a fixed 50000 transaction)
If they send 50000 they can start a BN but cannot mine until they receive a payment.
If they have more BN's and just clear the BN wallet and send all coins received to another wallet, there is a possibility that they cannot mine because they are left only with 50000 BCR transaction.

For me, does not seems right ...

[bitcreditscc]

https://github.com/bitcreditscc/bicreditsnew/blob/bb21fcb8bcf5dbc43e89eca6996f51e19d116479/src/main.cpp#L2158

>=50000*COIN

What would be rationale behind that...? I mean from a technical PoV? Having 50K is all wee and fine, but the reason i used > rather than >= was at that time i assumed that one would first spin up a BN then get at least one payment to prove they are an active BN then start mining. However users can get around that by simply sending 50000.001.

How can we resolve this ?

if they send 50000.001 they cannot start a BN but can mine. (for a BN to be started it's needed a fixed 50000 transaction)
If they send 50000 they can start a BN but cannot mine until they receive a payment.
If they have more BN's and just clear the BN wallet and send all coins received to another wallet, there is a possibility that they cannot mine because they are left only with 50000 BCR transaction.

For me, does not seems alright ...

Right, thus we find the conflict. However, do we make provisions in the code for this , or should we leave this to the users' discretion? Indeed we have to have clear policy and support for various setups and options, but do the benefits of coding a solution outweigh the costs in terms of development/testing/deploy time and the additional computing required ? remember we now check for balances and consecutive keys. Already the client suffers slow downs , would the additional cost of computing be worthwhile, or should we leave it to users to understand that emptying a BN means wait for another payment before mining? In general users emptying a BN use coin control perhaos we can just add a note in the client that warns users of this ?

Hehehe, I am changing my approach to development/problem solving based on what I am learning through books and practical 

[dragos_bdi]

https://github.com/bitcreditscc/bicreditsnew/blob/bb21fcb8bcf5dbc43e89eca6996f51e19d116479/src/main.cpp#L2158

>=50000*COIN

What would be rationale behind that...? I mean from a technical PoV? Having 50K is all wee and fine, but the reason i used > rather than >= was at that time i assumed that one would first spin up a BN then get at least one payment to prove they are an active BN then start mining. However users can get around that by simply sending 50000.001.

How can we resolve this ?

if they send 50000.001 they cannot start a BN but can mine. (for a BN to be started it's needed a fixed 50000 transaction)
If they send 50000 they can start a BN but cannot mine until they receive a payment.
If they have more BN's and just clear the BN wallet and send all coins received to another wallet, there is a possibility that they cannot mine because they are left only with 50000 BCR transaction.

For me, does not seems alright ...

Right, thus we find the conflict. However, do we make provisions in the code for this , or should we leave this to the users' discretion? Indeed we have to have clear policy and support for various setups and options, but do the benefits of coding a solution outweigh the costs in terms of development/testing/deploy time and the additional computing required ? remember we now check for balances and consecutive keys. Already the client suffers slow downs , would the additional cost of computing be worthwhile, or should we leave it to users to understand that emptying a BN means wait for another payment before mining? In general users emptying a BN use coin control perhaos we can just add a note in the client that warns users of this ?

Hehehe, I am changing my approach to development/problem solving based on what I am learning through books and practical 

Pffff ... You are right about this. I think the best solution is to warn users. 

At present time, I was trying to spin up some more miners to find 210286 ... 

[dragos_bdi]

Latest Windows 64 build based on master branch - version 0.30.17.5

Download Link: https://mega.nz/#!q4EXHZLK!-EdiPIZSD7qVYurXI_ypVUj_GKUc_32G5v2mv48562A

[bitcreditscc]

Pffff ... You are right about this. I think the best solution is to warn users. 

At present time, I was trying to spin up some more miners to find 210286 ... 

Just logged in to miner, yeah it's got a high difficulty. network hashrate has not yet stabilized. i had one core dedicated to mining i'll set 4 and see if that helps.

Nice catch though, these situations must be explored and discussed so that when we right a complete user guide, it will have all necessary information.

[dragos_bdi]

Found it !!!! 210286

Difficulty now 9155 ?!?!?!? OMG



{
"version" : 301705,
"protocolversion" : 70012,
"walletversion" : 60000,
"balance" : 50006.35664640,
"darksend_balance" : 0.00000000,
"blocks" : 210286,
"timeoffset" : 0,
"connections" : 31,
"proxy" : "",
"difficulty" : 0.00009155,
"testnet" : false,
"keypoololdest" : 1443254195,
"keypoolsize" : 2,
"paytxfee" : 0.00000000,
"relayfee" : 0.00001000,
"errors" : ""
}

[bitcreditscc]

Found it !!!! 210286

Difficulty now 9155 ?!?!?!? OMG



{
"version" : 301705,
"protocolversion" : 70012,
"walletversion" : 60000,
"balance" : 50006.35664640,
"darksend_balance" : 0.00000000,
"blocks" : 210286,
"timeoffset" : 0,
"connections" : 31,
"proxy" : "",
"difficulty" : 0.00009155,
"testnet" : false,
"keypoololdest" : 1443254195,
"keypoolsize" : 2,
"paytxfee" : 0.00000000,
"relayfee" : 0.00001000,
"errors" : ""
}

full power on an i5, when i get a minute i'll throw 8 cores from a 8 core AMD processor.

[dragos_bdi]

Found it !!!! 210286

Difficulty now 9155 ?!?!?!? OMG



{
"version" : 301705,
"protocolversion" : 70012,
"walletversion" : 60000,
"balance" : 50006.35664640,
"darksend_balance" : 0.00000000,
"blocks" : 210286,
"timeoffset" : 0,
"connections" : 31,
"proxy" : "",
"difficulty" : 0.00009155,
"testnet" : false,
"keypoololdest" : 1443254195,
"keypoolsize" : 2,
"paytxfee" : 0.00000000,
"relayfee" : 0.00001000,
"errors" : ""
}

full power on an i5, when i get a minute i'll throw 8 cores from a 8 core AMD processor.

I did not see that high diff form when was +100GPU mining.
It's worth your time to check the diff algo keeping in mind that now we mine only with cpu-wallet only.

Me, i'm out from mining, 3 wallets are at 50000 and the one that found the block is off till the next one.

[dextronomous]

yes thanks guys, dragos great thanks,

mine's off to till i figure out how to keep mining?

[thelonecrouton]

Without banknode.conf working, having more than one exactly 50k input in a wallet screws up starting your banknode, as the client seems to select a 50k vin at random, not necessarily the one that matches your banknodeprivkey.

I think things as they are now will do, it allows users to decide which income stream(s) they prefer.

You can run as many miningkeys as you can afford off a Pi2 or similar, appx. running cost nothing - 1 core of a Pi2 uses well under 500mW at full load, so take your electricity cost per kW/h and divide it by 2000, it doesn't amount to much even if you're paying European prices... or you can stick 10+ BNs on a $4/month 2GB RAM VPS... or do both, or whatever combination you like.

[thelonecrouton]

yes thanks guys, dragos great thanks,

mine's off to till i figure out how to keep mining?

Right now you only need 2 x 50k+ addresses to mine continuously, just put both addresses in miningkeys.dat. When it increases to 1 in 20 (or whatever) you'll need 20 x 50k+ addresses to mine continuously.

[thelonecrouton]

Found it !!!! 210286

Difficulty now 9155 ?!?!?!? OMG



{
"version" : 301705,
"protocolversion" : 70012,
"walletversion" : 60000,
"balance" : 50006.35664640,
"darksend_balance" : 0.00000000,
"blocks" : 210286,
"timeoffset" : 0,
"connections" : 31,
"proxy" : "",
"difficulty" : 0.00009155,
"testnet" : false,
"keypoololdest" : 1443254195,
"keypoolsize" : 2,
"paytxfee" : 0.00000000,
"relayfee" : 0.00001000,
"errors" : ""
}

Hmm, I'm stuck on 210285:

getmininginfo
{
"blocks" : 210285,
"currentblocksize" : 1677,
"currentblocktx" : 3,
"difficulty" : 0.00000002,
"errors" : "Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues.",
"genproclimit" : 1,
"networkhashps" : 0,
"pooledtx" : 3,
"testnet" : false,
"chain" : "main",
"generate" : true,
"hashespermin" : 5
}

Diff is nice and low here...  

[dextronomous]


{
"blocks" : 210286,
"currentblocksize" : 1225,
"currentblocktx" : 1,
"difficulty" : 0.00009155,
"errors" : "",
"genproclimit" : 1,
"networkhashps" : 3.88963552,
"pooledtx" : 1,
"testnet" : false,
"chain" : "main",
"generate" : true,
"hashespermin" : 2.49818881
}

here sweet.. so if no block found cpu keeps mining.. and if found stops till i activate it again or how does that part work?
i have my banknode.conf ok in place. worked till so far.

[dragos_bdi]


{
"blocks" : 210286,
"currentblocksize" : 1225,
"currentblocktx" : 1,
"difficulty" : 0.00009155,
"errors" : "",
"genproclimit" : 1,
"networkhashps" : 3.88963552,
"pooledtx" : 1,
"testnet" : false,
"chain" : "main",
"generate" : true,
"hashespermin" : 2.49818881
}

here sweet.. so if no block found cpu keeps mining.. and if found stops till i activate it again or how does that part work?
i have my banknode.conf ok in place. worked till so far.

sleeps until another one find a block, then start again on your wallet. at least now ....

[bitcreditscc]

Found it !!!! 210286

Difficulty now 9155 ?!?!?!? OMG



{
"version" : 301705,
"protocolversion" : 70012,
"walletversion" : 60000,
"balance" : 50006.35664640,
"darksend_balance" : 0.00000000,
"blocks" : 210286,
"timeoffset" : 0,
"connections" : 31,
"proxy" : "",
"difficulty" : 0.00009155,
"testnet" : false,
"keypoololdest" : 1443254195,
"keypoolsize" : 2,
"paytxfee" : 0.00000000,
"relayfee" : 0.00001000,
"errors" : ""
}

full power on an i5, when i get a minute i'll throw 8 cores from a 8 core AMD processor.

I did not see that high diff form when was +100GPU mining.
It's worth your time to check the diff algo keeping in mind that now we mine only with cpu-wallet only.

Me, i'm out from mining, 3 wallets are at 50000 and the one that found the block is off till the next one.

I'm @ work so it's tight, i'll get some time @ lunch and use it to organize my mining nodes .You are right about the diff algorithm though, we once discussed using floats for adjustments, but it's scary stuff. Right now i'm working on json (when there are no clients of course) if i can get it to work, then when i go home all i'll be doing tonight is figuring out how to fix diff adj to float type...that should result it smoother increases and decreases.

[bitcreditscc]

Found it !!!! 210286

Difficulty now 9155 ?!?!?!? OMG



{
"version" : 301705,
"protocolversion" : 70012,
"walletversion" : 60000,
"balance" : 50006.35664640,
"darksend_balance" : 0.00000000,
"blocks" : 210286,
"timeoffset" : 0,
"connections" : 31,
"proxy" : "",
"difficulty" : 0.00009155,
"testnet" : false,
"keypoololdest" : 1443254195,
"keypoolsize" : 2,
"paytxfee" : 0.00000000,
"relayfee" : 0.00001000,
"errors" : ""
}

Hmm, I'm stuck on 210285:

getmininginfo
{
"blocks" : 210285,
"currentblocksize" : 1677,
"currentblocktx" : 3,
"difficulty" : 0.00000002,
"errors" : "Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues.",
"genproclimit" : 1,
"networkhashps" : 0,
"pooledtx" : 3,
"testnet" : false,
"chain" : "main",
"generate" : true,
"hashespermin" : 5
}

Diff is nice and low here...  

Likely an issue of connectivity. Since there are a few nodes fully operational it's taking a few seconds longer than usual for tx to get around the whole net. Also blocks may not propagate properly. I've sent a pm to the bitnodes guy, i'll compare his rates to just managing our own nodes.

[bitcreditscc]

Code:

   if (pindexLast->nHeight+1 >29999){
		if (nActualTimespan < Params().TargetTimespan2()/4)
        nActualTimespan = Params().TargetTimespan2()/2;
		if (nActualTimespan > Params().TargetTimespan2()*4)
        nActualTimespan = Params().TargetTimespan2()* 8;
	}

Maybe to something like

Code:

   if (pindexLast->nHeight+1 >21100){
		if (nActualTimespan < Params().TargetTimespan2()/4)
        nActualTimespan = Params().TargetTimespan2()/1.1; //10% increases in diff
		if (nActualTimespan > Params().TargetTimespan2()*4)
        nActualTimespan = Params().TargetTimespan2()* 8; //not sure if I should change this (works specially well to drastically reduce diff against possible attacks )
	}

[dragos_bdi]

Code:

   if (pindexLast->nHeight+1 >29999){
		if (nActualTimespan < Params().TargetTimespan2()/4)
        nActualTimespan = Params().TargetTimespan2()/2;
		if (nActualTimespan > Params().TargetTimespan2()*4)
        nActualTimespan = Params().TargetTimespan2()* 8;
	}

Maybe to something like

Code:

   if (pindexLast->nHeight+1 >21100){
		if (nActualTimespan < Params().TargetTimespan2()/4)
        nActualTimespan = Params().TargetTimespan2()/1.1; //10% increases in diff
		if (nActualTimespan > Params().TargetTimespan2()*4)
        nActualTimespan = Params().TargetTimespan2()* 8; //not sure if I should change this (works specially well to drastically reduce diff against possible attacks )
	}

Why don't you use last 900 blocks to do a better diff adjustment ?

Code:

// Go back by what we want to be 14 days worth of blocks
    	const CBlockIndex* pindexFirst = pindexLast;
	const CBlockIndex* pindexFirst900 = pindexLast;
    	if ((pindexLast->nHeight+1) < 4800){
    		for (int i = 0; pindexFirst && i < Params().Interval()-1; i++)
        		pindexFirst = pindexFirst->pprev;
	}
	else if ((pindexLast->nHeight+1) >210000 ){ 
		for (int i = 0; 900; i++) {
        		pindexFirst900 = pindexFirst900->pprev;
		}
	       	pindexFirst = pindexFirst->pprev;
	}
    assert(pindexFirst);
    assert(pindexFirst900);

    // Limit adjustment step
    int64_t nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
    int64_t nActualTimespan900 = whole((pindexLast->GetBlockTime() - pindexFirst900->GetBlockTime())/900);
    if (fDebug)
    if(fDebug)LogPrintf("  nActualTimespan = %d  before bounds\n", nActualTimespan);

	if (pindexLast->nHeight+1 >210000){
		if (nActualTimespan900 < Params().TargetTimespan2()/4)
        nActualTimespan900 = Params().TargetTimespan2()/1.1;
		if (nActualTimespan900 > Params().TargetTimespan2()*4)
        nActualTimespan900 = Params().TargetTimespan2()* 8;
	nActualTimespan = nActualTimespan900;
	}   

   else if (pindexLast->nHeight+1 >29999){
		if (nActualTimespan < Params().TargetTimespan2()/4)
        nActualTimespan = Params().TargetTimespan2()/2;
		if (nActualTimespan > Params().TargetTimespan2()*4)
        nActualTimespan = Params().TargetTimespan2()* 8;
	}