[ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 163.

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kramble on December 14, 2013, 12:09:57 PM

Quote from: BlueDragon747 on December 14, 2013, 12:03:19 PM

same shift as Bitcoin/Litecoin from Blakecoin wallet 0.8.6

only the work limit is different
Bitcoin has 2^32
Litecoin has 2^20
Blakecoin has 2^24

OK, I am confused then. I'll have to go and have a look at the code and think about this.

AS I commented above (in the EDIT), do you want my to push my current 3.1.1 miner up onto github now (and dropbox for the windows binary) or wait until I've got to the bottom of what I need to do difficulty-wise?

happy to test the windows binary for now Cool

btw your FPGA code consistently gets higher shares than my GPU's maybe its just lucky code Wink

kramble

sr. member

Activity: 384

Merit: 250

Quote from: BlueDragon747 on December 14, 2013, 12:03:19 PM

same shift as Bitcoin/Litecoin from Blakecoin wallet 0.8.6

only the work limit is different
Bitcoin has 2^32
Litecoin has 2^20
Blakecoin has 2^24

OK, I am confused then. I'll have to go and have a look at the code and think about this.

AS I commented above (in the EDIT), do you want my to push my current 3.1.1 miner up onto github now (and dropbox for the windows binary) or wait until I've got to the bottom of what I need to do difficulty-wise?

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kramble on December 14, 2013, 11:57:37 AM

Quote from: BlueDragon747 on December 14, 2013, 11:45:33 AM

I did change the shift in the wallet as it was incorrect in early release version it now matches a 29 shift like Bitcoin
https://github.com/BlueDragon747/Blakecoin/blob/master/src/rpcblockchain.cpp#L31

the shift reduced the difficulty by a multiple of 256 so you can see kramble's point 65536/256 = 256

the other value that is different to Bitcoin/Litecoin is the bnProofOfWorkLimit
https://github.com/BlueDragon747/Blakecoin/blob/master/src/main.cpp#L38

The thing that's confusing me a little is that the genesis block matches to a target of 0x000000FF (it actually hashes to 0x000000BA), then when you changed the shift I used the same hash target as bitcoin 0x00000000 for the fpga mining code.

So it appears to me that we've currently got the same diff=1 target as bitcoin. But maybe I'm just confused about this.

same shift as Bitcoin/Litecoin from Blakecoin wallet 0.8.6

only the work limit is different
Bitcoin has 2^32
Litecoin has 2^20
Blakecoin has 2^24

kramble

sr. member

Activity: 384

Merit: 250

Quote from: BlueDragon747 on December 14, 2013, 11:45:33 AM

I did change the shift in the wallet as it was incorrect in early release version it now matches a 29 shift like Bitcoin
https://github.com/BlueDragon747/Blakecoin/blob/master/src/rpcblockchain.cpp#L31

the shift reduced the difficulty by a multiple of 256 so you can see kramble's point 65536/256 = 256

the other value that is different to Bitcoin/Litecoin is the bnProofOfWorkLimit
https://github.com/BlueDragon747/Blakecoin/blob/master/src/main.cpp#L38

The thing that's confusing me a little is that the genesis block matches to a target of 0x000000FF (it actually hashes to 0x000000BA), then when you changed the shift I used the same hash target as bitcoin 0x00000000 for the fpga mining code.

So it appears to me that we've currently got the same diff=1 target as bitcoin. But maybe I'm just confused about this.

EDIT Looking at the calc_diff() function, this has changed significantly from cgminer 3.1.1 to 3.7 and I'm going to have to have a good hard think about what's happening in there to back-port the "d64 *= (double)16777216" change.

I'm kinda tempted just to push up my current code as it seems to be working (I'm running a bit short of time today). Any thoughts or should I just leave it to tomorrow?

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kramble on December 14, 2013, 11:31:46 AM

Quote from: kr105 on December 14, 2013, 11:09:45 AM

Quote from: kramble on December 14, 2013, 10:55:54 AM

Quote from: kr105 on December 14, 2013, 10:46:39 AM

I was unsure if this was due to a bug on my cgminer implementation or on the pool, now that you tested your own working cgminer and it didn't work too i will take a further look on the pool.

The only changes I made were the single sha256 in gen_hash() plus the diff1targ in test_nonce() which is actually done directly in submit_nonce in cgminer 3.1.1

The only query I have is about set_target() line 5976 (of your cgminer.c) which has ...

if (opt_scrypt)
d64 *= (double)65536;

I wonder if this needs to be (double)256 for blake?

I got it like this on my cgminer:
https://github.com/kR105/cgminer/blob/3.7/cgminer.c#L3140

Ah. I missed that one entirely (but it does seem to be working without it). I'll put it in and see it it makes any difference.

I'll admit that I'm rather twiddling in the dark here as I haven't analyzed the code to work out exactly what the difficulty/target code is actually doing. Though I am a little concerned that you're apparently using base 256 as the diff1 target while this was actually changed to base 0 in an early patch release of the blake wallet (if I'm recalling correctly, bluedragon may want to chip in here).

I did change the shift in the wallet as it was incorrect in early release version it now matches a 29 shift like Bitcoin
https://github.com/BlueDragon747/Blakecoin/blob/master/src/rpcblockchain.cpp#L31

the shift reduced the difficulty by a multiple of 256 so you can see kramble's point 65536/256 = 256

the other value that is different to Bitcoin/Litecoin is the bnProofOfWorkLimit
https://github.com/BlueDragon747/Blakecoin/blob/master/src/main.cpp#L38

kramble

sr. member

Activity: 384

Merit: 250

Quote from: kr105 on December 14, 2013, 11:09:45 AM

Quote from: kramble on December 14, 2013, 10:55:54 AM

Quote from: kr105 on December 14, 2013, 10:46:39 AM

I was unsure if this was due to a bug on my cgminer implementation or on the pool, now that you tested your own working cgminer and it didn't work too i will take a further look on the pool.

The only changes I made were the single sha256 in gen_hash() plus the diff1targ in test_nonce() which is actually done directly in submit_nonce in cgminer 3.1.1

The only query I have is about set_target() line 5976 (of your cgminer.c) which has ...

if (opt_scrypt)
d64 *= (double)65536;

I wonder if this needs to be (double)256 for blake?

I got it like this on my cgminer:
https://github.com/kR105/cgminer/blob/3.7/cgminer.c#L3140

Ah. I missed that one entirely (but it does seem to be working without it). I'll put it in and see it it makes any difference.

I'll admit that I'm rather twiddling in the dark here as I haven't analyzed the code to work out exactly what the difficulty/target code is actually doing. Though I am a little concerned that you're apparently using base 256 as the diff1 target while this was actually changed to base 0 in an early patch release of the blake wallet (if I'm recalling correctly, bluedragon may want to chip in here).

kr105

hero member

Activity: 938

Merit: 501

Ok thanks, I will run a diff to see if I can find any other important change.

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kr105 on December 14, 2013, 11:23:43 AM

Bluedragon, what bitcoin version did you use as base?

main line 0.8.5 official release not the beta
https://github.com/bitcoin/bitcoin/tree/0.8.5

my prototype was in 0.8.3 but I only ported my changes over to 0.8.5

kr105

hero member

Activity: 938

Merit: 501

Bluedragon, what bitcoin version did you use as base?

kr105

hero member

Activity: 938

Merit: 501

Quote from: BlueDragon747 on December 14, 2013, 11:18:39 AM

Quote from: kr105 on December 14, 2013, 11:09:45 AM

Quote from: kramble on December 14, 2013, 10:55:54 AM

Quote from: kr105 on December 14, 2013, 10:46:39 AM

I was unsure if this was due to a bug on my cgminer implementation or on the pool, now that you tested your own working cgminer and it didn't work too i will take a further look on the pool.

The only changes I made were the single sha256 in gen_hash() plus the diff1targ in test_nonce() which is actually done directly in submit_nonce in cgminer 3.1.1

The only query I have is about set_target() line 5976 (of your cgminer.c) which has ...

if (opt_scrypt)
d64 *= (double)65536;

I wonder if this needs to be (double)256 for blake?

I got it like this on my cgminer:
https://github.com/kR105/cgminer/blob/3.7/cgminer.c#L3140

I notice the else if for the opt_blake256 @ line 3139 to set the difficulty for the option switch in calc_diff but not in set_target at line 5976 does it not need an else if for the option switch?

I just tried this on the last H-non-zero wave, but it didn't worked.

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kr105 on December 14, 2013, 11:09:45 AM

Quote from: kramble on December 14, 2013, 10:55:54 AM

Quote from: kr105 on December 14, 2013, 10:46:39 AM

I was unsure if this was due to a bug on my cgminer implementation or on the pool, now that you tested your own working cgminer and it didn't work too i will take a further look on the pool.

The only changes I made were the single sha256 in gen_hash() plus the diff1targ in test_nonce() which is actually done directly in submit_nonce in cgminer 3.1.1

The only query I have is about set_target() line 5976 (of your cgminer.c) which has ...

if (opt_scrypt)
d64 *= (double)65536;

I wonder if this needs to be (double)256 for blake?

I got it like this on my cgminer:
https://github.com/kR105/cgminer/blob/3.7/cgminer.c#L3140

I notice the else if for the opt_blake256 @ line 3139 to set the difficulty for the option switch in calc_diff but not in set_target at line 5976 does it not need an else if for the option switch?

psyc

sr. member

Activity: 266

Merit: 250

hi, I'm trying to undermine, but I get only reject H-NOT-ZERO: (

kr105

hero member

Activity: 938

Merit: 501

Quote from: kramble on December 14, 2013, 10:55:54 AM

Quote from: kr105 on December 14, 2013, 10:46:39 AM

I was unsure if this was due to a bug on my cgminer implementation or on the pool, now that you tested your own working cgminer and it didn't work too i will take a further look on the pool.

The only changes I made were the single sha256 in gen_hash() plus the diff1targ in test_nonce() which is actually done directly in submit_nonce in cgminer 3.1.1

The only query I have is about set_target() line 5976 (of your cgminer.c) which has ...

if (opt_scrypt)
d64 *= (double)65536;

I wonder if this needs to be (double)256 for blake?

I got it like this on my cgminer:
https://github.com/kR105/cgminer/blob/3.7/cgminer.c#L3140

kramble

sr. member

Activity: 384

Merit: 250

Quote from: kr105 on December 14, 2013, 10:46:39 AM

I was unsure if this was due to a bug on my cgminer implementation or on the pool, now that you tested your own working cgminer and it didn't work too i will take a further look on the pool.

The only changes I made were the single sha256 in gen_hash() plus the diff1targ in test_nonce() which is actually done directly in submit_nonce in cgminer 3.1.1

The only query I have is about set_target() line 5976 (of your cgminer.c) which has ...

if (opt_scrypt)
d64 *= (double)65536;

I wonder if this needs to be (double)256 for blake?

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kr105 on December 14, 2013, 10:46:39 AM

I was unsure if this was due to a bug on my cgminer implementation or on the pool, now that you tested your own working cgminer and it didn't work too i will take a further look on the pool.

it was at the start of working on block 37208 just after we solved block 37207

lasted about 5-10 minutes then it came back to block 37208 and was normal again

kr105

hero member

Activity: 938

Merit: 501

I was unsure if this was due to a bug on my cgminer implementation or on the pool, now that you tested your own working cgminer and it didn't work too i will take a further look on the pool.

kramble

sr. member

Activity: 384

Merit: 250

Quote from: BlueDragon747 on December 14, 2013, 10:27:09 AM

not the first time I have seen this H-not-zero error but last time it resolved itself Undecided

And the very moment I read that, the pool ramped back up again (possibly at a new block as its now on 37208). All working perfectly again Roll Eyes

And its gone off again, in mid block 37212 rather than at a new block (I was watching it).

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kramble on December 14, 2013, 10:24:09 AM

Quote from: BlueDragon747 on December 14, 2013, 10:21:33 AM

yeah it recovers but is definitely a pool bug of some sort, "H-not-zero means the hash of the header isn't zero for the first 32-bits." but why would it be so random like you said same difficulty Huh

Well the pool is currently showing 0GH/s and pool invalids are climbing rapidly. Pool failure methinks.

Quote from: kr105 on December 13, 2013, 05:23:40 PM

Quote from: BlueDragon747 on December 13, 2013, 05:22:18 PM

Quote from: kr105 on December 13, 2013, 05:16:56 PM

Quote from: BlueDragon747 on December 13, 2013, 05:08:49 PM

Quote from: kr105 on December 13, 2013, 04:08:16 PM

Good news guys, the pool fee has been lowered from 7% to 3% !

getting H-not-zero errors on the pool atm Huh

I got them too, I'm not sure if it is a bug on cgminer or the pool, I'm looking at this now.

ok working again Cheesy

It seems to trigger with a certain target threshold btw, as I have not done anything yet Tongue

not the first time I have seen this H-not-zero error but last time it resolved itself Undecided

kramble

sr. member

Activity: 384

Merit: 250

Quote from: BlueDragon747 on December 14, 2013, 10:21:33 AM

yeah it recovers but is definitely a pool bug of some sort, "H-not-zero means the hash of the header isn't zero for the first 32-bits." but why would it be so random like you said same difficulty Huh

Well the pool is currently showing 0GH/s and pool invalids are climbing rapidly. Pool failure methinks.

BlueDragon747

legendary

Activity: 1509

Merit: 1030

Solutions Architect

Quote from: kramble on December 14, 2013, 10:18:12 AM

Quote from: ?? on ??

Awesome

I think I spoke too soon. Its just started kicking out "H-not-zero" errors and stopped accepting shares (all now being rejected by the pool). Not at a diff change either as we're on block 37307 according to the pool. Restarting cgminer hasn't helped, its just seems broken Sad

Then again, I think its the pool that's died, according to the dashboard.

yeah it recovers but is definitely a pool bug of some sort? "H-not-zero means the hash of the header isn't zero for the first 32-bits." but why would it be so random like you said same difficulty Huh

Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 163. (Read 409641 times)