◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈

[bitcreditscc]

now i'm synced to 210005, block accepted with correct data. Just pushed fix for vote prefix, small pull and make shaould make ordinary non-BN nodes build grantDB automatically.

[dragos_bdi]

please recheck the ratings/grantdb.dat to be created if not found.

case:
1. blockchain till 210008
2. ratings/grantdb.dat does not exists
3. start the wallet
4. wallet try to read the grantdb.dat.
5. not found, sigfault

[dragos_bdi]

till now, successfully synced till 210005 and banknode started on 2 nodes:

91.230.123.101:8888
91.230.123.11:8877

Edit2: after he found a block, the mining process stop
Edit: on both nodes "getblocktemplate" tells me that my bnminingkey is invalid, but mining works ...

Code:

2015-10-02 07:22:01 CheckBlock() : Using non-specific banknode payments 210006
2015-10-02 07:22:01 CheckBlock() : Found banknode payment 210006
2015-10-02 07:22:01 CheckBlock() : Using non-specific banknode payments 210006
2015-10-02 07:22:01 CheckBlock() : Found banknode payment 210006
2015-10-02 07:22:01       - Connect 1 transactions: 0.01ms (0.012ms/tx, 0.000ms/txin) [0.00s]
2015-10-02 07:22:01 New vout  address:- 6C4maPsTQYkPjgkU2sw3pNCobo1Uw5uRZB , amount :-840000000
2015-10-02 07:22:01 New vout  address:- 5qoFUCqPUE4pyjus6U6jD6ba4oHR6NZ7c7 , amount :-180000000
2015-10-02 07:22:01 New vout  address:- 6133GZGV2XRnS53DkLSWrK661TsQMqnewL , amount :-180000000
2015-10-02 07:22:01 New vout  address:- 6C4maPsTQYkPjgkU2sw3pNCobo1Uw5uRZB , amount :-600000000
2015-10-02 07:22:01     - Verify 0 txins: 14.20ms (0.000ms/txin) [65.05s]
2015-10-02 07:22:01 Running BitcreditMiner with 1 transactions in block (289 bytes)
2015-10-02 07:22:01 CreateNewBlock(): total size 1000
2015-10-02 07:22:01   nActualTimespan = 447470  before bounds
2015-10-02 07:22:01 GetNextWorkRequired RETARGET
2015-10-02 07:22:01 Params().TargetTimespan2() = 60    nActualTimespan = 480
2015-10-02 07:22:01 Before: 20025e53  025e530000000000000000000000000000000000000000000000000000000000
2015-10-02 07:22:01 After:  2001e186  01e186eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
2015-10-02 07:22:01   nActualTimespan = 447470  before bounds
2015-10-02 07:22:01 GetNextWorkRequired RETARGET
2015-10-02 07:22:01 Params().TargetTimespan2() = 60    nActualTimespan = 480
2015-10-02 07:22:01 Before: 20025e53  025e530000000000000000000000000000000000000000000000000000000000
2015-10-02 07:22:01 After:  2001e186  01e186eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
2015-10-02 07:22:01 CheckBlock() : Using non-specific banknode payments 210006
2015-10-02 07:22:01 CheckBlock() : Found banknode payment 210006
2015-10-02 07:22:01 CheckBlock() : Using non-specific banknode payments 210006
2015-10-02 07:22:01 CheckBlock() : Found banknode payment 210006
2015-10-02 07:22:01       - Connect 1 transactions: 0.01ms (0.015ms/tx, 0.000ms/txin) [0.00s]
2015-10-02 07:22:01 New vout  address:- 6C4maPsTQYkPjgkU2sw3pNCobo1Uw5uRZB , amount :-840000000
2015-10-02 07:22:01 New vout  address:- 5qoFUCqPUE4pyjus6U6jD6ba4oHR6NZ7c7 , amount :-180000000
2015-10-02 07:22:01 New vout  address:- 6133GZGV2XRnS53DkLSWrK661TsQMqnewL , amount :-180000000
2015-10-02 07:22:01 New vout  address:- 6C4maPsTQYkPjgkU2sw3pNCobo1Uw5uRZB , amount :-600000000
2015-10-02 07:22:01     - Verify 0 txins: 16.55ms (0.000ms/txin) [65.07s]
2015-10-02 07:22:01 Running BitcreditMiner with 1 transactions in block (289 bytes)

Good, good, we are getting somewhere. Now, check your balances.dat and look for the address you are trying to use to mine. the balance is xxxxx/100000000. if that number is > 50000 then your key is valid.

1) Remember you cannot mine consecutive blocks with the same key (i'll write a method to automatically try multiple keys later)

2) If your balances.dat is corrupted (you can tell if there are negative numbers), then your key may be rejected.

5zoh1bN2XTbFrbM5yPiBEK1R2nomhPa9dY,5152535000000
6C4maPsTQYkPjgkU2sw3pNCobo1Uw5uRZB,5439320000000

[bitcreditscc]

A review of BITCREDIT has been submitted by a user.

You can read the review of 'bitcredit' HERE

Brought to you by: allcryptocoins.net

Please remove the review of Bitcredit, not only is it highly biased and inappropriate, we have not opened up to anyone for review.

The article in question is no different from assessing a car's performance before the engine has even been built.

[bitcreditscc]

5zoh1bN2XTbFrbM5yPiBEK1R2nomhPa9dY,5152535000000
6C4maPsTQYkPjgkU2sw3pNCobo1Uw5uRZB,5439320000000

please recheck the ratings/grantdb.dat to be created if not found.

case:
1. blockchain till 210008
2. ratings/grantdb.dat does not exists
3. start the wallet
4. wallet try to read the grantdb.dat.
5. not found, sigfault

do a git pull, build then start client. Next use "reconsiderblock "insertblockhashof210005here"

it will rewind the chain to 210005, and try reconnecting all the blocks, if they are connected, then they are valid, if not it will stop at the last valid block.

[bitcreditscc]

looks like chain is on the move 210010

need to get chainz in on this, manually looking up each single block is exhausting.

[bitcreditscc]

i'm prepping a bootstrap for users who want to jump the rather extended sync process. Bootstrap includes miners.dat, ratings/grandb.dat and balances.dat.

starts @ 210010.

[dragos_bdi]

looks like chain is on the move 210010

need to get chainz in on this, manually looking up each single block is exhausting.

blocks from 210005 till 210010 are found by me on two wallets.
but if I found the wallet on first wallet, i must reissue setgenerate true on second, and after i found the block on second wallet, i must do "setgenerate true" on first, and so on ...

[dragos_bdi]

also, why do you serialize the grantdb.dat from block 1 if he applies from 210000 ?
test 1-5 minutes till he finish ..

[bitcreditscc]

looks like chain is on the move 210010

need to get chainz in on this, manually looking up each single block is exhausting.

blocks from 210005 till 210010 are found by me on two wallets.
but if I found the wallet on first wallet, i must reissue setgenerate true on second, and after i found the block on second wallet, i must do "setgenerate true" on first, and so on ...

Ok then we must find a way for miner to only attempt when it's key is valid

I think i have an idea...

[bitcreditscc]

also, why do you serialize the grantdb.dat from block 1 if he applies from 210000 ?
test 1-5 minutes till he finish ..

Nice catch, we can serialize from 209980. This is ok.

Maybe we can also set a "wait"  condition in miner that only allows mining if next block is valid. 

[bitcreditscc]

miners.dat logic is still in the wind, but i'll lock it down. so, we've proven :-

1) the new rules work
2) addrDB is accurate
3) dragos is a great person

Need to check

1) Miner + BN + Grant + Payout block
2) Miner + BN + Grant block
3) Miner + BN block

I think to be safe, let's work out these bugs as well before opening up the clients to public?

[tombcoin]

5zoh1bN2XTbFrbM5yPiBEK1R2nomhPa9dY,5152535000000
6C4maPsTQYkPjgkU2sw3pNCobo1Uw5uRZB,5439320000000

please recheck the ratings/grantdb.dat to be created if not found.

case:
1. blockchain till 210008
2. ratings/grantdb.dat does not exists
3. start the wallet
4. wallet try to read the grantdb.dat.
5. not found, sigfault

do a git pull, build then start client. Next use "reconsiderblock "insertblockhashof210005here"

it will rewind the chain to 210005, and try reconnecting all the blocks, if they are connected, then they are valid, if not it will stop at the last valid block.

Which branch do we use for now?
Head
master
or new bla... which is eq with master

lg t.

[dragos_bdi]

also, why do you serialize the grantdb.dat from block 1 if he applies from 210000 ?
test 1-5 minutes till he finish ..

Nice catch, we can serialize from 209980. This is ok.

Maybe we can also set a "wait"  condition in miner that only allows mining if next block is valid. 

Exactly, now i understand why he stops.

let's say he found a block, accepted, valid.
he still mine, but, if the next block found is by the same wallet, the mining thread stop and you must reissue "setgenerate true".

an elegant way, will be:
if he found a block, sleep until the found block +1.
 What you say ?

[dragos_bdi]

Correct nodes, till now:

91.230.123.101:8877
91.230.123.101:8888
91.230.123.11:8877
82.211.1.181:8877

all, at present time sync till 210011

[bitcreditscc]

also, why do you serialize the grantdb.dat from block 1 if he applies from 210000 ?
test 1-5 minutes till he finish ..

Nice catch, we can serialize from 209980. This is ok.

Maybe we can also set a "wait"  condition in miner that only allows mining if next block is valid. 

Exactly, now i understand why he stops.

let's say he found a block, accepted, valid.
he still mine, but, if the next block found is by the same wallet, the mining thread stop and you must reissue "setgenerate true".

an elegant way, will be:
if he found a block, sleep until the found block +1.
 What you say ?

Yup, that's the best solution, but we will have to increase that to 20 later when i figure out logic for 20 block limit.
can you upload a copy of the balances.dat ? Maybe just use pastebin

[dragos_bdi]

also, why do you serialize the grantdb.dat from block 1 if he applies from 210000 ?
test 1-5 minutes till he finish ..

Nice catch, we can serialize from 209980. This is ok.

Maybe we can also set a "wait"  condition in miner that only allows mining if next block is valid. 

Exactly, now i understand why he stops.

let's say he found a block, accepted, valid.
he still mine, but, if the next block found is by the same wallet, the mining thread stop and you must reissue "setgenerate true".

an elegant way, will be:
if he found a block, sleep until the found block +1.
 What you say ?

Yup, that's the best solution, but we will have to increase that to 20 later when i figure out logic for 20 block limit.
can you upload a copy of the balances.dat ? Maybe just use pastebin

http://pastebin.com/18CAw7Wq

[bitcreditscc]

I think a simpler method could be possibly a time-based wait period, that sort of follows the coding style already present in the mining code The logic is already there.

@dragos_bdi
Thoughts?

[bitcreditscc]

5zoh1bN2XTbFrbM5yPiBEK1R2nomhPa9dY,5152535000000
6C4maPsTQYkPjgkU2sw3pNCobo1Uw5uRZB,5439320000000

please recheck the ratings/grantdb.dat to be created if not found.

case:
1. blockchain till 210008
2. ratings/grantdb.dat does not exists
3. start the wallet
4. wallet try to read the grantdb.dat.
5. not found, sigfault

do a git pull, build then start client. Next use "reconsiderblock "insertblockhashof210005here"

it will rewind the chain to 210005, and try reconnecting all the blocks, if they are connected, then they are valid, if not it will stop at the last valid block.

Which branch do we use for now?
Head
master
or new bla... which is eq with master

lg t.

new bla ver

[dragos_bdi]

I think a simpler method could be possibly a time-based wait period, that sort of follows the coding style already present in the mining code The logic is already there.

@dragos_bdi
Thoughts?

Still exists the possibility that the same wallet find 2 blocks in row.

Could you write a function that if the miner address that found the last block equal with the -bnminingkey, the miner threads sleep for 1 sec or so ?