Bitcoin Forum
March 28, 2024, 06:46:18 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 [41] 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 ... 204 »
  Print  
Author Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net  (Read 409406 times)
kr105
Hero Member
*****
Offline Offline

Activity: 938
Merit: 501


View Profile
December 14, 2013, 04:07:29 AM
 #801

I just found another "feature". The coinbase confirm at 140 blocks, not 120 as stated on the OP.

https://github.com/BlueDragon747/Blakecoin/blob/bf4339873ef0c50c98581905ae9f510bc1707384/src/main.cpp#L927

I noticed this because the pool balance went negative, and I started poking around and I found this. This seems to be how Bitcoin handled coinbase maturity in the past, and they changed it here: https://github.com/bitcoin/bitcoin/pull/2947/commits

Well, anyway, the pool balance should stabilize in the coming blocks!

Bitcoin 0.8.5 and 0.8.6
https://github.com/bitcoin/bitcoin/blob/0.8.6/src/main.cpp#L934

still uses +20 for coinbase maturity  Undecided

so with Bitcoin its 100 +20 buffer
and with Blakecoin its 120 +20 buffer

from what Gavin has said with regards to Bitcoin is that the network is 100 and this is the minimum maturity and the +20 (has been a few different values) this is for an extra buffer to avoid stales and issues with sending newly matured coins ?

it can be reduced even removed from the wallet as long as the minimum of the network maturity is used which is 120 for Blakecoin, only reason it has been left as +20 is there was no good reason to change it  Embarrassed
Yes, as you said this makes Bitcoin have the 120 confirms everyone knows about and as on the OP you said that BLC had 120 confirms, i used that confirms amount on the pool. But anyway, as you said, it doesn't hurt to have an extra 20 confirms buffer, just try to note about this on the OP so nobody else gets this confusion Smiley
The Bitcoin network protocol was designed to be extremely flexible. It can be used to create timed transactions, escrow transactions, multi-signature transactions, etc. The current features of the client only hint at what will be possible in the future.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711651578
Hero Member
*
Offline Offline

Posts: 1711651578

View Profile Personal Message (Offline)

Ignore
1711651578
Reply with quote  #2

1711651578
Report to moderator
1711651578
Hero Member
*
Offline Offline

Posts: 1711651578

View Profile Personal Message (Offline)

Ignore
1711651578
Reply with quote  #2

1711651578
Report to moderator
BlueDragon747 (OP)
Legendary
*
Offline Offline

Activity: 1509
Merit: 1030


Solutions Architect


View Profile WWW
December 14, 2013, 04:23:45 AM
Last edit: December 14, 2013, 05:19:32 AM by BlueDragon747
 #802

I just found another "feature". The coinbase confirm at 140 blocks, not 120 as stated on the OP.

https://github.com/BlueDragon747/Blakecoin/blob/bf4339873ef0c50c98581905ae9f510bc1707384/src/main.cpp#L927

I noticed this because the pool balance went negative, and I started poking around and I found this. This seems to be how Bitcoin handled coinbase maturity in the past, and they changed it here: https://github.com/bitcoin/bitcoin/pull/2947/commits

Well, anyway, the pool balance should stabilize in the coming blocks!

Bitcoin 0.8.5 and 0.8.6
https://github.com/bitcoin/bitcoin/blob/0.8.6/src/main.cpp#L934

still uses +20 for coinbase maturity  Undecided

so with Bitcoin its 100 +20 buffer
and with Blakecoin its 120 +20 buffer

from what Gavin has said with regards to Bitcoin is that the network is 100 and this is the minimum maturity and the +20 (has been a few different values) this is for an extra buffer to avoid stales and issues with sending newly matured coins ?

it can be reduced even removed from the wallet as long as the minimum of the network maturity is used which is 120 for Blakecoin, only reason it has been left as +20 is there was no good reason to change it  Embarrassed
Yes, as you said this makes Bitcoin have the 120 confirms everyone knows about and as on the OP you said that BLC had 120 confirms, i used that confirms amount on the pool. But anyway, as you said, it doesn't hurt to have an extra 20 confirms buffer, just try to note about this on the OP so nobody else gets this confusion Smiley

made a reference to the +20 buffer, 140 total maturity in OP Smiley

Gavin did also say that it was mainly for the main stream end user wallets and not a pool or network level service so you can compile it with a lower value if you wish but also take the chance of any issues Wink

btw great work on the pool very smooth and it was upto 21GH/s  Grin

for the pool this is my cgminer.conf:

{
"pools" : [
   {
      "url" : "stratum+tcp://stratum.blakecoinpool.org:3333",
      "user" : "UserName.Worker",
      "pass" : "WorkerPassword"
   }
],

"intensity" : "9",
"auto-gpu" : true,
"expiry" : "120",
"failover-only" : true,
"gpu-threads" : "2",
"log" : "5",
"no-restart" : true,
"queue" : "5",
"scan-time" : "10",
"worksize" : "128",
"temp-hysteresis" : "4",
"blake256" : true,
"vectors" : "1",
"no-submit-stale": true,
"kernel-path" : "/"
}

Info: GithubBlakecoin.org - BCT Blakecoin thread - Twitter - BCS - BlakeZone  Trade Blakecoin: Xeggex.com Merged Mining Pools: EU3 - NY2/AT1 - LA1
Donation Addresses: BLC: Bd3jJftFbwxWSKNSNz35vkDd57kG6jHAjt PHO: BZXPMc8eF9YZcJStskkP2bVia38fv9VmuT BBTC: 2h8c4NbzXJXk6QQ89r7YYMGhe13gQUC2ajD ELT: e7cm6cAgpfhvk3Myh2Jkmi1nqaHtDHnxXb 
UMO: uQH9H17t7kz3eVQ3vKDzMsWCK4hn5nh2gC LIT: 8p8Z4h5fkZ8SCoyEtihKcjzZLA7gFjTdmL BTC: 1Q6kgcNqhKh8u67m6Gj73T2LMgGseETwR6
kramble
Sr. Member
****
Offline Offline

Activity: 384
Merit: 250



View Profile WWW
December 14, 2013, 10:06:29 AM
 #803

Is the system still working?
All of my blocks mined last night are shown as "Generated but not accepted"...
Any hints?
Try with my version of cgminer, even on solo.
I'm using kramble's blakefpga version. Worked perfectly until yesterday... Strange...

I have this issue often. Diff changes seem to knock wallet off network and all blocks mined become orphaned and block count fails to rise. I have to close and relaunch wallet. No prob in miner but in wallet.

cgminer has been known to crash the wallet and I notice that when you connect to the pool with diff 2, cgminer does the difficult @ 2.000397 maybe this has issues?

if someone can find this bug in the wallet then I can patch it, atm the only way i have seen this bug is to overload the wallet with cgminer rigs and it starts to lose connections and eventually locks up and needs to reset

cgminer 3.1.1 with kramble's fpga mod (ztex/cm1) is better but does occasionally lock the wallet

I did not get this problem with reaper when solo mining nor did I need to reset my wallet when using reaper Huh  

I run the wallet on raspberry pi, and the problem I have is the pi completely locking up. It just hangs, nothing in the logs, nothing running (I have a watchdog that flashes a LED on the GPIO once a second via a bash script, and it just stops). Need to power cycle to reset. This happens with both cgminer and the old python miner, so its not just cgminer. Its very intermittent, originally happening perhaps once every day or so, then I had a good stretch where it was stable for a whole week (after diff had dropped off from its peak, so maybe the Mr Big miner had given up), and recently its been crashing every few hours (so much so that I switched over to litecoin mining overnight for the last week). This makes me think its more to do with what's happening on the network side rather than the miner.

PS I don't see any orphaned blocks when this happens, after restarting everything is fine and the blocks continue to confirm, but as the whole box is locking up rather than just the wallet, I guess this is a different sort of bug.

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
BlueDragon747 (OP)
Legendary
*
Offline Offline

Activity: 1509
Merit: 1030


Solutions Architect


View Profile WWW
December 14, 2013, 12:43:08 PM
 #804

Problem with this error(s)/bug(s) that are getting described is they are very hard to bug hunt and it is not easy for me here to replicate the issue so that I can find the line of code creating any problem and then fix it  Embarrassed

The only thing I could even guess at that would effect the whole network is that maybe the close 20 block retarget causes an issue?, any one else have any ideas about the cause or a way of getting more repeatable results to narrow down the possible cause  Undecided

on the cgminer overload method there are two ways of getting the wallet working, kill a few cgminer instances and often the wallet would just start working again but sometimes it would need a close and restart of the wallet, this issue I can recreate but this does not result in finding a bug in the code as it just hangs or locks  Cry

Info: GithubBlakecoin.org - BCT Blakecoin thread - Twitter - BCS - BlakeZone  Trade Blakecoin: Xeggex.com Merged Mining Pools: EU3 - NY2/AT1 - LA1
Donation Addresses: BLC: Bd3jJftFbwxWSKNSNz35vkDd57kG6jHAjt PHO: BZXPMc8eF9YZcJStskkP2bVia38fv9VmuT BBTC: 2h8c4NbzXJXk6QQ89r7YYMGhe13gQUC2ajD ELT: e7cm6cAgpfhvk3Myh2Jkmi1nqaHtDHnxXb 
UMO: uQH9H17t7kz3eVQ3vKDzMsWCK4hn5nh2gC LIT: 8p8Z4h5fkZ8SCoyEtihKcjzZLA7gFjTdmL BTC: 1Q6kgcNqhKh8u67m6Gj73T2LMgGseETwR6
kramble
Sr. Member
****
Offline Offline

Activity: 384
Merit: 250



View Profile WWW
December 14, 2013, 01:02:30 PM
Last edit: December 14, 2013, 02:30:02 PM by kramble
 #805

Problem with this error(s)/bug(s) that are getting described is they are very hard to bug hunt and it is not easy for me here to replicate the issue so that I can find the line of code creating any problem and then fix it  Embarrassed

Yeah, agreed. I'm not even sure my raspi problems are due to the wallet. It could just be a buggy network stack eg the raspi wired ethernet port is connected via the internal USB hub, which could be causing random network hangs. It could just be that the wallet traffic is sufficient to trigger this, even though its stable in normal use. I have tried swapping to a different board (I have two pies), but the problem still occurs. I am on an old wheezy debian though, so the next thing to try would be an update to a more recent version, but I'm a bit loath to do this as there is a lot of customization I'd need to redo.

Anyway if I can get it mining on the pool, this won't be an issue any more Cheesy

EDIT. Yep mining on pool with 3.1.1, just needed to change a couple of lines of code. Found a block at 16k diff within 10 minutes too (I seem to be good at finding blocks on pools, I managed a 1.6G bitcoin block on only 50MH/s a few months back). I just need to check it out solo in case the diff change has broken that and I'll get it up on github.

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
BlueDragon747 (OP)
Legendary
*
Offline Offline

Activity: 1509
Merit: 1030


Solutions Architect


View Profile WWW
December 14, 2013, 02:48:11 PM
 #806

Problem with this error(s)/bug(s) that are getting described is they are very hard to bug hunt and it is not easy for me here to replicate the issue so that I can find the line of code creating any problem and then fix it  Embarrassed

Yeah, agreed. I'm not even sure my raspi problems are due to the wallet. It could just be a buggy network stack eg the raspi wired ethernet port is connected via the internal USB hub, which could be causing random network hangs. It could just be that the wallet traffic is sufficient to trigger this, even though its stable in normal use. I have tried swapping to a different board (I have two pies), but the problem still occurs. I am on an old wheezy debian though, so the next thing to try would be an update to a more recent version, but I'm a bit loath to do this as there is a lot of customization I'd need to redo.

Anyway if I can get it mining on the pool, this won't be an issue any more Cheesy

EDIT. Yep mining on pool with 3.1.1, just needed to change a couple of lines of code. Found a block at 16k diff within 10 minutes too (I seem to be good at finding blocks on pools, I managed a 1.6G bitcoin block on only 50MH/s a few months back). I just need to check it out solo in case the diff change has broken that and I'll get it up on github.

lol 10 minutes yeah I would say that is almost showing off  Tongue

on the cm1 have had a 1.2M share when soloing last week and a 723k share on the ztex few days ago  Grin

great work are you going to do a build for cm1 and ztex?

Info: GithubBlakecoin.org - BCT Blakecoin thread - Twitter - BCS - BlakeZone  Trade Blakecoin: Xeggex.com Merged Mining Pools: EU3 - NY2/AT1 - LA1
Donation Addresses: BLC: Bd3jJftFbwxWSKNSNz35vkDd57kG6jHAjt PHO: BZXPMc8eF9YZcJStskkP2bVia38fv9VmuT BBTC: 2h8c4NbzXJXk6QQ89r7YYMGhe13gQUC2ajD ELT: e7cm6cAgpfhvk3Myh2Jkmi1nqaHtDHnxXb 
UMO: uQH9H17t7kz3eVQ3vKDzMsWCK4hn5nh2gC LIT: 8p8Z4h5fkZ8SCoyEtihKcjzZLA7gFjTdmL BTC: 1Q6kgcNqhKh8u67m6Gj73T2LMgGseETwR6
kramble
Sr. Member
****
Offline Offline

Activity: 384
Merit: 250



View Profile WWW
December 14, 2013, 03:06:36 PM
 #807

great work are you going to do a build for cm1 and ztex?

Its a common build so it should work on CM1, ztex and lancelot. I've just been testing it on windows today (since the CM1 is currently powered off my win7/64 PC), but I'll do the raspi build and check it out for the ztex and lancelot there (its all a bit tedious shuffling devices and power supplies to check all the combinations, plus for some reason I can't seem to get the CM1 to run on raspi with 3.1.1 though the 3.7 build did work, but wasn't submitting shares). Plenty to fiddle with. Anyway I'll try to get the initial version up on githib today and worry about fully testing all the combinations later.

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
kramble
Sr. Member
****
Offline Offline

Activity: 384
Merit: 250



View Profile WWW
December 14, 2013, 03:18:12 PM
 #808

Awesome  Grin

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

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
BlueDragon747 (OP)
Legendary
*
Offline Offline

Activity: 1509
Merit: 1030


Solutions Architect


View Profile WWW
December 14, 2013, 03:21:33 PM
 #809

Awesome  Grin

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

Info: GithubBlakecoin.org - BCT Blakecoin thread - Twitter - BCS - BlakeZone  Trade Blakecoin: Xeggex.com Merged Mining Pools: EU3 - NY2/AT1 - LA1
Donation Addresses: BLC: Bd3jJftFbwxWSKNSNz35vkDd57kG6jHAjt PHO: BZXPMc8eF9YZcJStskkP2bVia38fv9VmuT BBTC: 2h8c4NbzXJXk6QQ89r7YYMGhe13gQUC2ajD ELT: e7cm6cAgpfhvk3Myh2Jkmi1nqaHtDHnxXb 
UMO: uQH9H17t7kz3eVQ3vKDzMsWCK4hn5nh2gC LIT: 8p8Z4h5fkZ8SCoyEtihKcjzZLA7gFjTdmL BTC: 1Q6kgcNqhKh8u67m6Gj73T2LMgGseETwR6
kramble
Sr. Member
****
Offline Offline

Activity: 384
Merit: 250



View Profile WWW
December 14, 2013, 03:24:09 PM
 #810

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.

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
BlueDragon747 (OP)
Legendary
*
Offline Offline

Activity: 1509
Merit: 1030


Solutions Architect


View Profile WWW
December 14, 2013, 03:27:09 PM
 #811

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.

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

Info: GithubBlakecoin.org - BCT Blakecoin thread - Twitter - BCS - BlakeZone  Trade Blakecoin: Xeggex.com Merged Mining Pools: EU3 - NY2/AT1 - LA1
Donation Addresses: BLC: Bd3jJftFbwxWSKNSNz35vkDd57kG6jHAjt PHO: BZXPMc8eF9YZcJStskkP2bVia38fv9VmuT BBTC: 2h8c4NbzXJXk6QQ89r7YYMGhe13gQUC2ajD ELT: e7cm6cAgpfhvk3Myh2Jkmi1nqaHtDHnxXb 
UMO: uQH9H17t7kz3eVQ3vKDzMsWCK4hn5nh2gC LIT: 8p8Z4h5fkZ8SCoyEtihKcjzZLA7gFjTdmL BTC: 1Q6kgcNqhKh8u67m6Gj73T2LMgGseETwR6
kramble
Sr. Member
****
Offline Offline

Activity: 384
Merit: 250



View Profile WWW
December 14, 2013, 03:30:35 PM
Last edit: December 14, 2013, 03:43:24 PM by kramble
 #812

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

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
kr105
Hero Member
*****
Offline Offline

Activity: 938
Merit: 501


View Profile
December 14, 2013, 03:46:39 PM
 #813

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.
BlueDragon747 (OP)
Legendary
*
Offline Offline

Activity: 1509
Merit: 1030


Solutions Architect


View Profile WWW
December 14, 2013, 03:53:44 PM
 #814

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

Info: GithubBlakecoin.org - BCT Blakecoin thread - Twitter - BCS - BlakeZone  Trade Blakecoin: Xeggex.com Merged Mining Pools: EU3 - NY2/AT1 - LA1
Donation Addresses: BLC: Bd3jJftFbwxWSKNSNz35vkDd57kG6jHAjt PHO: BZXPMc8eF9YZcJStskkP2bVia38fv9VmuT BBTC: 2h8c4NbzXJXk6QQ89r7YYMGhe13gQUC2ajD ELT: e7cm6cAgpfhvk3Myh2Jkmi1nqaHtDHnxXb 
UMO: uQH9H17t7kz3eVQ3vKDzMsWCK4hn5nh2gC LIT: 8p8Z4h5fkZ8SCoyEtihKcjzZLA7gFjTdmL BTC: 1Q6kgcNqhKh8u67m6Gj73T2LMgGseETwR6
kramble
Sr. Member
****
Offline Offline

Activity: 384
Merit: 250



View Profile WWW
December 14, 2013, 03:55:54 PM
 #815

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?

Github https://github.com/kramble BLC BkRaMaRkw3NeyzsZ2zUgXsNLogVVkQ1iPV
kr105
Hero Member
*****
Offline Offline

Activity: 938
Merit: 501


View Profile
December 14, 2013, 04:09:45 PM
 #816

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
psyc
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250


View Profile
December 14, 2013, 04:12:01 PM
 #817

hi, I'm trying to undermine, but I get only reject H-NOT-ZERO: (
BlueDragon747 (OP)
Legendary
*
Offline Offline

Activity: 1509
Merit: 1030


Solutions Architect


View Profile WWW
December 14, 2013, 04:18:39 PM
 #818

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?

Info: GithubBlakecoin.org - BCT Blakecoin thread - Twitter - BCS - BlakeZone  Trade Blakecoin: Xeggex.com Merged Mining Pools: EU3 - NY2/AT1 - LA1
Donation Addresses: BLC: Bd3jJftFbwxWSKNSNz35vkDd57kG6jHAjt PHO: BZXPMc8eF9YZcJStskkP2bVia38fv9VmuT BBTC: 2h8c4NbzXJXk6QQ89r7YYMGhe13gQUC2ajD ELT: e7cm6cAgpfhvk3Myh2Jkmi1nqaHtDHnxXb 
UMO: uQH9H17t7kz3eVQ3vKDzMsWCK4hn5nh2gC LIT: 8p8Z4h5fkZ8SCoyEtihKcjzZLA7gFjTdmL BTC: 1Q6kgcNqhKh8u67m6Gj73T2LMgGseETwR6
kr105
Hero Member
*****
Offline Offline

Activity: 938
Merit: 501


View Profile
December 14, 2013, 04:23:05 PM
 #819

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.
kr105
Hero Member
*****
Offline Offline

Activity: 938
Merit: 501


View Profile
December 14, 2013, 04:23:43 PM
 #820

Bluedragon, what bitcoin version did you use as base?
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 [41] 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 ... 204 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!