◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈ - page 74.

tombcoin

newbie

Activity: 49

Merit: 0

Quote from: bitcreditscc on October 02, 2015, 06:13:22 AM

I deleted the post linking to that trash article. We are not ready for media attention.

Well done

Syncing will kill me soon, nervwrecking and stupid.
Seeing lines scrolling and scrolling. Tons of lines.

Can´t even remember which nodes I have updated and which not.

Hope there will be a normal way of life soon.
lg t.

bitcreditscc

hero member

Activity: 602

Merit: 501

I deleted the post linking to that trash article. We are not ready for media attention.

dragos_bdi

sr. member

Activity: 322

Merit: 250

Quote from: bitcreditscc on October 02, 2015, 05:48:31 AM

Quote from: dragos_bdi on October 02, 2015, 05:10:01 AM

Quote from: bitcreditscc on October 02, 2015, 04:52:37 AM

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 ?

Yeah, that's the plan, i want it to check if it mined the last block, but instead of waiting for a new block signal, it just uses time delay.

Perfect !

bitcreditscc

hero member

Activity: 602

Merit: 501

Quote from: dragos_bdi on October 02, 2015, 05:10:01 AM

Quote from: bitcreditscc on October 02, 2015, 04:52:37 AM

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 ?

Yeah, that's the plan, i want it to check if it mined the last block, but instead of waiting for a new block signal, it just uses time delay.

dragos_bdi

sr. member

Activity: 322

Merit: 250

Quote from: bitcreditscc on October 02, 2015, 04:52:37 AM

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 ?

bitcreditscc

hero member

Activity: 602

Merit: 501

Quote from: tombcoin on October 02, 2015, 03:56:24 AM

Quote from: bitcreditscc on October 02, 2015, 03:08:29 AM

Quote from: dragos_bdi on October 02, 2015, 03:03:29 AM

5zoh1bN2XTbFrbM5yPiBEK1R2nomhPa9dY,5152535000000
6C4maPsTQYkPjgkU2sw3pNCobo1Uw5uRZB,5439320000000

Quote from: dragos_bdi on October 02, 2015, 02:57:31 AM

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

bitcreditscc

hero member

Activity: 602

Merit: 501

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?

dragos_bdi

sr. member

Activity: 322

Merit: 250

Quote from: bitcreditscc on October 02, 2015, 04:34:48 AM

Quote from: dragos_bdi on October 02, 2015, 03:56:29 AM

Quote from: bitcreditscc on October 02, 2015, 03:46:44 AM

Quote from: dragos_bdi on October 02, 2015, 03:38:05 AM

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

hero member

Activity: 602

Merit: 501

Quote from: dragos_bdi on October 02, 2015, 03:56:29 AM

Quote from: bitcreditscc on October 02, 2015, 03:46:44 AM

Quote from: dragos_bdi on October 02, 2015, 03:38:05 AM

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

sr. member

Activity: 322

Merit: 250

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

dragos_bdi

sr. member

Activity: 322

Merit: 250

Quote from: bitcreditscc on October 02, 2015, 03:46:44 AM

Quote from: dragos_bdi on October 02, 2015, 03:38:05 AM

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 ?

tombcoin

newbie

Activity: 49

Merit: 0

Quote from: bitcreditscc on October 02, 2015, 03:08:29 AM

Quote from: dragos_bdi on October 02, 2015, 03:03:29 AM

5zoh1bN2XTbFrbM5yPiBEK1R2nomhPa9dY,5152535000000
6C4maPsTQYkPjgkU2sw3pNCobo1Uw5uRZB,5439320000000

Quote from: dragos_bdi on October 02, 2015, 02:57:31 AM

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.

bitcreditscc

hero member

Activity: 602

Merit: 501

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?

bitcreditscc

hero member

Activity: 602

Merit: 501

Quote from: dragos_bdi on October 02, 2015, 03:38:05 AM

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

hero member

Activity: 602

Merit: 501

Quote from: dragos_bdi on October 02, 2015, 03:24:49 AM

Quote from: bitcreditscc on October 02, 2015, 03:13:12 AM

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...

dragos_bdi

sr. member

Activity: 322

Merit: 250

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

dragos_bdi

sr. member

Activity: 322

Merit: 250

Quote from: bitcreditscc on October 02, 2015, 03:13:12 AM

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 ...

bitcreditscc

hero member

Activity: 602

Merit: 501

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.

bitcreditscc

hero member

Activity: 602

Merit: 501

looks like chain is on the move 210010

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

bitcreditscc

hero member

Activity: 602

Merit: 501

Quote from: dragos_bdi on October 02, 2015, 03:03:29 AM

5zoh1bN2XTbFrbM5yPiBEK1R2nomhPa9dY,5152535000000
6C4maPsTQYkPjgkU2sw3pNCobo1Uw5uRZB,5439320000000

Quote from: dragos_bdi on October 02, 2015, 02:57:31 AM

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.

Topic: ◈◈Bitcredit ◈◈ Migrating to UniQredit◈◈ - page 74. (Read 284545 times)