[ANN] [SHA256]+[CPU] MediterraneanCoin (MED) - REUSE your ERUPTER!!

[digit]

Will the mining work with GPUs instead of Asics?

yes, you should use the modified bfgminer.

Thank you. Do you know if there are any compiled binaries for the modified bfgminer ?

not at the moment; but we can prepare them.

for what platform do you need them?

Windows please. Thank you!

Win32 version as well please
Still mining i found a couple more blocks over past 24 hours with just 1 BE after finding none for over 12 hours before that, i'm guess the diff must have dropped during this period or i just got lucky
I assume i can point the gpu on bfgminer at the proxy and it work harmonious with the BE on cgminer, or is it limited to one or the other?

[subSTRATA]

Still mining i found a couple more blocks over past 24 hours with just 1 BE after finding none for over 12 hours before that, i'm guess the diff must have dropped during this period or i just got lucky

Solo mining is very dependant on luck. One can find 10 blocks in a row or none for 10 days. Beside luck there is also a variance
that is almost synewave like, if you are at the top of wave you are very likely to get block(s) but if you are at the bottom than
even luck seem not to help. At the bottom, even getting diff 1 shares becomes slow. At top of wave it can go really crazy. While
mining on Bitcoin TestNet I had situations when, at the top of wave, I was almost orphaning my own blocks, LOL!

One could argue that variance with mining (a synewave) is actualy graphical representation of luck. A sort of like Biorhythm works
but I'm not sure if there is any connection there.

[smallplatf]

Will the mining work with GPUs instead of Asics?

yes, you should use the modified bfgminer.

Thank you. Do you know if there are any compiled binaries for the modified bfgminer ?

not at the moment; but we can prepare them.

for what platform do you need them?

Windows please. Thank you!

Win32 version as well please
Still mining i found a couple more blocks over past 24 hours with just 1 BE after finding none for over 12 hours before that, i'm guess the diff must have dropped during this period or i just got lucky
I assume i can point the gpu on bfgminer at the proxy and it work harmonious with the BE on cgminer, or is it limited to one or the other?

hi,
we have prepared a win32 build of modified bfgminer following the instructions provided here: https://github.com/mrtexaznl/bfgminer/blob/201311-doc-updates/windows-build.txt

Note: this bfgminer build starts in benchmark mode inside a msdos prompt, but we have not checked yet how it works with an ASIC. Please test it and report back.


Visit this page for build configuration and download of binaries:

https://github.com/mrtexaznl/bfgminer/releases/tag/v3.9.0.1-med

[eestimees]

whats with that:

Code:

 
cgminer version 3.9.0 - Started: [2014-01-07 16:30:49]
-------------------------------------------------------------------------------
 (5s):200.0M (avg):289.2Mh/s | A:0  R:0  HW:0  WU:3.2/m
 ST: 4  SS: 0  NB: 0  LW: 0  GF: 0  RF: 0
 Connected to localhost diff 1.37K without LP as user mediterraneancoinrpc
 Block: ...  Diff:  Started:   Best share: 10
-------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 AMU 1:                | 335.4M/332.9Mh/s | A:0 R:0 HW:0 WU: 2.7/m
-------------------------------------------------------------------------------

 [2014-01-07 16:34:47] (5s):286.7M (avg):283.1Mh/s | A:0  R:0  HW:0  WU:3.5/m
 [2014-01-07 16:34:53] (5s):168.8M (avg):276.1Mh/s | A:0  R:0  HW:0  WU:3.4/m
 [2014-01-07 16:34:59] (5s):388.9M (avg):286.4Mh/s | A:0  R:0  HW:0  WU:3.4/m
 [2014-01-07 16:35:05] (5s):228.9M (avg):279.7Mh/s | A:0  R:0  HW:0  WU:3.3/m
 [2014-01-07 16:35:08] Share above target
 [2014-01-07 16:35:11] (5s):477.4M (avg):292.4Mh/s | A:0  R:0  HW:0  WU:3.4/m
 [2014-01-07 16:35:17] (5s):281.0M (avg):285.8Mh/s | A:0  R:0  HW:0  WU:3.4/m
 [2014-01-07 16:35:23] (5s):456.1M (avg):295.0Mh/s | A:0  R:0  HW:0  WU:3.3/m
 [2014-01-07 16:35:29] (5s):268.4M (avg):288.7Mh/s | A:0  R:0  HW:0  WU:3.2/m
 [2014-01-07 16:35:35] (5s):448.8M (avg):297.5Mh/s | A:0  R:0  HW:0  WU:3.1/m
 [2014-01-07 16:35:37] Share above target
 [2014-01-07 16:35:41] (5s):339.9M (avg):295.2Mh/s | A:0  R:0  HW:0  WU:3.3/m
 [2014-01-07 16:35:47] (5s):200.0M (avg):289.2Mh/s | A:0  R:0  HW:0  WU:3.2/m

does not seem to be hashing.. when running awhile, only HW count increments...

from cgminer manual:

Also many issues and FAQs are covered in the forum thread
dedicated to this program,
        http://forum.bitcoin.org/index.php?topic=28402.0

The output line shows the following:
(5s):1713.6 (avg):1707.8 Mh/s | A:729 R:8 HW:0 WU:22.53/m

Each column is as follows:
5s: A 5 second exponentially decaying average hash rate
avg: An all time average hash rate
A: The total difficulty of Accepted shares
R: The total difficulty of Rejected shares
HW: The number of HardWare errors
WU: The Work Utility defined as the number of diff1 shares work / minute
     (accepted or rejected).

from your log:
it looks like your device has WU > 0, and also the hash rate looks good, it seems that the device is working and hashing.

my bad, let me try to ask differently. It seems like hashing, but besides those "(5s)..." lines in output only

"Share above target" - is displayed. On normal cgminer screen I have used to see something different. And what got my attention was that only HW number increased not accept nor reject.. While running 3 usb erupters about 2 hours (do not remeber exactly) first line was:

A:0  R:0  HW:17 - is that normal?

also  

 Block: ...  Diff:  Started:   - were empy as well..

[Easy2Mine]

This reminds me the days of Solidcoins.
I hope I am wrong, but this one is also dead before it take height.

[smallplatf]

whats with that:

Code:

 
cgminer version 3.9.0 - Started: [2014-01-07 16:30:49]
-------------------------------------------------------------------------------
 (5s):200.0M (avg):289.2Mh/s | A:0  R:0  HW:0  WU:3.2/m
 ST: 4  SS: 0  NB: 0  LW: 0  GF: 0  RF: 0
 Connected to localhost diff 1.37K without LP as user mediterraneancoinrpc
 Block: ...  Diff:  Started:   Best share: 10
-------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 AMU 1:                | 335.4M/332.9Mh/s | A:0 R:0 HW:0 WU: 2.7/m
-------------------------------------------------------------------------------

 [2014-01-07 16:34:47] (5s):286.7M (avg):283.1Mh/s | A:0  R:0  HW:0  WU:3.5/m
 [2014-01-07 16:34:53] (5s):168.8M (avg):276.1Mh/s | A:0  R:0  HW:0  WU:3.4/m
 [2014-01-07 16:34:59] (5s):388.9M (avg):286.4Mh/s | A:0  R:0  HW:0  WU:3.4/m
 [2014-01-07 16:35:05] (5s):228.9M (avg):279.7Mh/s | A:0  R:0  HW:0  WU:3.3/m
 [2014-01-07 16:35:08] Share above target
 [2014-01-07 16:35:11] (5s):477.4M (avg):292.4Mh/s | A:0  R:0  HW:0  WU:3.4/m
 [2014-01-07 16:35:17] (5s):281.0M (avg):285.8Mh/s | A:0  R:0  HW:0  WU:3.4/m
 [2014-01-07 16:35:23] (5s):456.1M (avg):295.0Mh/s | A:0  R:0  HW:0  WU:3.3/m
 [2014-01-07 16:35:29] (5s):268.4M (avg):288.7Mh/s | A:0  R:0  HW:0  WU:3.2/m
 [2014-01-07 16:35:35] (5s):448.8M (avg):297.5Mh/s | A:0  R:0  HW:0  WU:3.1/m
 [2014-01-07 16:35:37] Share above target
 [2014-01-07 16:35:41] (5s):339.9M (avg):295.2Mh/s | A:0  R:0  HW:0  WU:3.3/m
 [2014-01-07 16:35:47] (5s):200.0M (avg):289.2Mh/s | A:0  R:0  HW:0  WU:3.2/m

does not seem to be hashing.. when running awhile, only HW count increments...

from cgminer manual:

Also many issues and FAQs are covered in the forum thread
dedicated to this program,
        http://forum.bitcoin.org/index.php?topic=28402.0

The output line shows the following:
(5s):1713.6 (avg):1707.8 Mh/s | A:729 R:8 HW:0 WU:22.53/m

Each column is as follows:
5s: A 5 second exponentially decaying average hash rate
avg: An all time average hash rate
A: The total difficulty of Accepted shares
R: The total difficulty of Rejected shares
HW: The number of HardWare errors
WU: The Work Utility defined as the number of diff1 shares work / minute
     (accepted or rejected).

from your log:
it looks like your device has WU > 0, and also the hash rate looks good, it seems that the device is working and hashing.

my bad, let me try to ask differently. It seems like hashing, but besides those "(5s)..." lines in output only

"Share above target" - is displayed. On normal cgminer screen I have used to see something different. And what got my attention was that only HW number increased not accept nor reject.. While running 3 usb erupters about 2 hours (do not remeber exactly) first line was:

A:0  R:0  HW:17 - is that normal?

also  

 Block: ...  Diff:  Started:   - were empy as well..

The condition to have "luck" (and thus to probably have mined a new block) is hash < target.
"Share above target" is reported by the miner when the hash (calculated on the result given back by the ASIC) is greater than the target (hash > target), thus is not good and is discarded without reporting back to mcproxy, since there is no need to send back a solution which is not valid (thus A and R values are not modified).
 
When solo mining, this "unluck" happens quite often, so what we see is ok.

The fact the HW (Hardare Errors) is > 0, means that your devices (or your device drivers, or your OS....) has some problems and so your ASICs stop responding for a while/they need to be reset. Maybe they are getting too hot. There could be several reasons.


Instead, when pool mining (and I give you an example below with the testing p2pool of MED), you will see a lot of "Accepted" block; but that does not translate in mined block, because the mechanism beyond pool mining is quite different.

So, I would say that your devices are solo mining correctly (apart for the HW errors which should be understood better).


ICA3       | 5s:335.7 avg:335.8 u:326.6 Mh/s | A:3530 R:0+0(none) HW:23/.65%
 [2014-01-07 16:45:46] ICA3       | 5s:335.7 avg:335.8 u:326.6 Mh/s | A:3530 R:0+0(none) HW:23/.65%                    
 [2014-01-07 16:45:53] Accepted 7721706c ICA 3  Diff 2/0                    
ICA3       | 5s:335.5 avg:335.8 u:326.6 Mh/s | A:3531 R:0+0(none) HW:23/.65%
 [2014-01-07 16:45:53] ICA3       | 5s:335.5 avg:335.8 u:326.6 Mh/s | A:3531 R:0+0(none) HW:23/.65%                    
 [2014-01-07 16:45:54] Accepted ae16247b ICA 1  Diff 1/0                    
ICA1       | 5s:335.5 avg:335.8 u:333.3 Mh/s | A:3603 R:0+0(none) HW:38/1.0%
 [2014-01-07 16:45:54] ICA1       | 5s:335.5 avg:335.8 u:333.3 Mh/s | A:3603 R:0+0(none) HW:38/1.0%                    
 [2014-01-07 16:45:57] Accepted 947b149e ICA 2  Diff 1/0                    
ICA2       | 5s:335.6 avg:335.7 u:341.2 Mh/s | A:3689 R:0+0(none) HW:28/.75%
 [2014-01-07 16:45:57] ICA2       | 5s:335.6 avg:335.7 u:341.2 Mh/s | A:3689 R:0+0(none) HW:28/.75%                    
 [2014-01-07 16:45:57] Accepted 41b69298 ICA 0  Diff 3/0                    
ICA0       | 5s:335.7 avg:335.8 u:324.6 Mh/s | A:3510 R:0+0(none) HW:27/.76%
 [2014-01-07 16:45:57] ICA0       | 5s:335.7 avg:335.8 u:324.6 Mh/s | A:3510 R:0+0(none) HW:27/.76%                    
 [2014-01-07 16:46:02] Accepted 079e3c63 ICA 1  Diff 33/0                    
ICA1       | 5s:335.6 avg:335.8 u:333.3 Mh/s | A:3604 R:0+0(none) HW:38/1.0%
 [2014-01-07 16:46:02] ICA1       | 5s:335.6 avg:335.8 u:333.3 Mh/s | A:3604 R:0+0(none) HW:38/1.0%                    
 [2014-01-07 16:46:04] Accepted 91c068a8 ICA 2  Diff 1/0                    
ICA2       | 5s:335.6 avg:335.7 u:341.2 Mh/s | A:3690 R:0+0(none) HW:28/.75%
 [2014-01-07 16:46:04] ICA2       | 5s:335.6 avg:335.7 u:341.2 Mh/s | A:3690 R:0+0(none) HW:28/.75%                    
 [2014-01-07 16:46:11] Accepted 0e7e3896 ICA 3  Diff 17/0                    
ICA3       | 5s:335.6 avg:335.8 u:326.6 Mh/s | A:3532 R:0+0(none) HW:23/.65%
 [2014-01-07 16:46:11] ICA3       | 5s:335.6 avg:335.8 u:326.6 Mh/s | A:3532 R:0+0(none) HW:23/.65%                    
 [2014-01-07 16:46:21] Accepted 1bbc690f ICA 2  Diff 9/0                    
ICA2       | 5s:335.5 avg:335.7 u:341.2 Mh/s | A:3691 R:0+0(none) HW:28/.75%
 [2014-01-07 16:46:21] ICA2       | 5s:335.5 avg:335.7 u:341.2 Mh/s | A:3691 R:0+0(none) HW:28/.75%                    
 [2014-01-07 16:46:21] Accepted 799ea0ce ICA 3  Diff 2/0                    
ICA3       | 5s:335.6 avg:335.8 u:326.6 Mh/s | A:3533 R:0+0(none) HW:23/.65%

[smallplatf]

....

I assume i can point the gpu on bfgminer at the proxy and it work harmonious with the BE on cgminer, or is it limited to one or the other?

yes, they can work together getting data from the same instance of mcproxy.

[subSTRATA]

This reminds me the days of Solidcoins.
I hope I am wrong, but this one is also dead before it take height.

History teaches that the best things come into existence slowly. All else is trendy crap (see DOGE and MOON) and last very short.

[mtbitcoin]

hi,
we have prepared a win32 build of modified bfgminer following the instructions provided here: https://github.com/mrtexaznl/bfgminer/blob/201311-doc-updates/windows-build.txt

Note: this bfgminer build starts in benchmark mode inside a msdos prompt, but we have not checked yet how it works with an ASIC. Please test it and report back.


Visit this page for build configuration and download of binaries:

https://github.com/mrtexaznl/bfgminer/releases/tag/v3.9.0.1-med

Thank you. Are there any special parameters that need to be included. I've got this up and running however, I am not entirely sure if its running correctly. Solo mining I am getting the "New block detected on network" every 1-2 seconds and there does not appear to be any load on the CPU.

Cheers

[eestimees]

So, I would say that your devices are solo mining correctly (apart for the HW errors which should be understood better).

Thanks.

[subSTRATA]

https://github.com/mrtexaznl/bfgminer/releases/tag/v3.9.0.1-med

Thank you. Are there any special parameters that need to be included. I've got this up and running however, I am not entirely sure if its running correctly. Solo mining I am getting the "New block detected on network" every 1-2 seconds and there does not appear to be any load on the CPU.

Cheers

Same for me. Also, only 3 out of 5 USB Erupters seem to be hashing.

I mentioned it over PM but I'll post it here as well, to check what others think on the matter. IMO transaction fees are just too high.
I have just tried to send 0.1 MED (just testing stuff) and wallet was refusing to send unless massive 0.4 MED transaction fee is paid.

[smallplatf]

hi,
we have prepared a win32 build of modified bfgminer following the instructions provided here: https://github.com/mrtexaznl/bfgminer/blob/201311-doc-updates/windows-build.txt

Note: this bfgminer build starts in benchmark mode inside a msdos prompt, but we have not checked yet how it works with an ASIC. Please test it and report back.


Visit this page for build configuration and download of binaries:

https://github.com/mrtexaznl/bfgminer/releases/tag/v3.9.0.1-med

Thank you. Are there any special parameters that need to be included. I've got this up and running however, I am not entirely sure if its running correctly. Solo mining I am getting the "New block detected on network" every 1-2 seconds and there does not appear to be any load on the CPU.

Cheers

Apologies! we built the mainstream bfgminer, instead of the modified one.

Here is the link to the modified bfgminer binary:

https://github.com/mrtexaznl/bfgminer/releases/download/v3.9.0.1-med/win32-bfgminer-1.zip

[smallplatf]

https://github.com/mrtexaznl/bfgminer/releases/tag/v3.9.0.1-med

Thank you. Are there any special parameters that need to be included. I've got this up and running however, I am not entirely sure if its running correctly. Solo mining I am getting the "New block detected on network" every 1-2 seconds and there does not appear to be any load on the CPU.

Cheers

Same for me. Also, only 3 out of 5 USB Erupters seem to be hashing.

I mentioned it over PM but I'll post it here as well, to check what others think on the matter. IMO transaction fees are just too high.
I have just tried to send 0.1 MED (just testing stuff) and wallet was refusing to send unless massive 0.4 MED transaction fee is paid.

Apologies! we built the mainstream bfgminer, instead of the modified one.

Here is the link to the modified bfgminer binary:

https://github.com/mrtexaznl/bfgminer/releases/download/v3.9.0.1-med/win32-bfgminer-1.zip


Yes, of course transaction fees can be changed; we will set them to 0.01 MED. This should be reasonable, considering that we should try to keep away too small transactions from the blockchain.

[subSTRATA]

The way I found to avoid paying such high fees is to send 0.1 MED to one address (giveaway, for example) and 10 to 1000 MED
to myself, in a same transaction. It takes some experimenting with number of coins that are to be send to myself but transaction
fees can be avoided completely.

Apologies! we built the mainstream bfgminer, instead of the modified one.

Here is the link to the modified bfgminer binary:

https://github.com/mrtexaznl/bfgminer/releases/download/v3.9.0.1-med/win32-bfgminer-1.zip

It works fine but issue with shares accepted and no blocks mined remains.

[smallplatf]

The way I found to avoid paying such high fees is to send 0.1 MED to one address (giveaway, for example) and 10 to 1000 MED
to myself, in a same transaction. It takes some experimenting with number of coins that are to be send to myself but transaction
fees can be avoided completely.

Apologies! we built the mainstream bfgminer, instead of the modified one.

Here is the link to the modified bfgminer binary:

https://github.com/mrtexaznl/bfgminer/releases/download/v3.9.0.1-med/win32-bfgminer-1.zip

It works fine but issue with shares accepted and no blocks mined remains.

we are testing the new bfgminer under win32 and it works well with usb block erupter (see screenshot, beyond the first cmd windows you can see mcproxy running).



are you using the last binary? its size is 1028203 bytes with creation date 2014-01-08.

if you solo mine, it is correct to see very few sent blocks (because the miner discover by itself if a solution is valid or not).

[subSTRATA]

are you using the last binary? its size is 1028203 bytes with creation date 2014-01-08.

Looks the same, SHA-256 for bfgminer.exe is 362C886B7E097C4F11B72F459BDD4B73E3D1CD8F6AE50FAAD1476B6ED6695B76

if you solo mine, it is correct to see very few sent blocks (because the miner discover by itself if a solution is valid or not).

It is about miner finding hash that is bellow target (for example 900/799) but no block is generated. At the same time no block is
added to blockchain by other miners. 30 seconds or more can pass till the next block on network. In other words, hash that should
get me some MED do nothing instead. It happens occassionaly with both CG and BFG miners. On screenshot bellow check accepted
hash at 20:56:15. It did nothing, compare it's time with time of transactions in MED wallet. It was not block mined then orphaned.



... and one more happened few seconds ago, while I was posting screenshot. In the end, it's like I'm mining with 3 USB Erupters!  

[vlight]

Download latest Windows binaries for wallet/daemon from here:
https://github.com/mrtexaznl/mediterraneancoin/releases/download/v0.8.5.1-1/medcoin-linux-v0.8.5.1-1.tgz

This is incorrect direct link.

[subSTRATA]

Download latest Windows binaries for wallet/daemon from here:
https://github.com/mrtexaznl/mediterraneancoin/releases/download/v0.8.5.1-1/medcoin-linux-v0.8.5.1-1.tgz

This is incorrect direct link.

Works for me, file size is 18.2 MB

[smallplatf]

are you using the last binary? its size is 1028203 bytes with creation date 2014-01-08.

Looks the same, SHA-256 for bfgminer.exe is 362C886B7E097C4F11B72F459BDD4B73E3D1CD8F6AE50FAAD1476B6ED6695B76

if you solo mine, it is correct to see very few sent blocks (because the miner discover by itself if a solution is valid or not).

It is about miner finding hash that is bellow target (for example 900/799) but no block is generated. At the same time no block is
added to blockchain by other miners. 30 seconds or more can pass till the next block on network. In other words, hash that should
get me some MED do nothing instead. It happens occassionaly with both CG and BFG miners. On screenshot bellow check accepted
hash at 20:56:15. It did nothing, compare it's time with time of transactions in MED wallet. It was not block mined then orphaned.



... and one more happened few seconds ago, while I was posting screenshot. In the end, it's like I'm mining with 3 USB Erupters!  

We are giving a look at the log of some nodes;
assuming that all the clocks are synced, we see:


...
received: block (189 bytes)
received block fdd515c3ef1f7f1279df9ae5410068cd3c23736f24372d6913daa0d9225d25ed
Committing 2 changed transactions to coin database...
SetBestChain: new best=fdd515c3ef1f7f1279df9ae5410068cd3c23736f24372d6913daa0d9225d25ed  height=12071  log2_work=54.651201  tx=12163  date=2014-01-08 20:54:41 progress=0.999947
ProcessBlock: ACCEPTED
...
...
received block a984c4638c5db9f32d9e2c7e0b61c90840a1a8f4f4b963f73078f331feee844e
Committing 1 changed transactions to coin database...
SetBestChain: new best=a984c4638c5db9f32d9e2c7e0b61c90840a1a8f4f4b963f73078f331feee844e  height=12072  log2_work=54.651376  tx=12164  date=2014-01-08 20:55:12 progress=0.999989
ProcessBlock: ACCEPTED
...
...
received block 627d1cbb0f1561c0794ac47d27db7a804243babf56c28457afdb8686e5caa2b4
Committing 2 changed transactions to coin database...
SetBestChain: new best=627d1cbb0f1561c0794ac47d27db7a804243babf56c28457afdb8686e5caa2b4  height=12073  log2_work=54.651551  tx=12165  date=2014-01-08 20:57:42 progress=0.999989
ProcessBlock: ACCEPTED
...

there is no orphaned block in the log; also the other nodes of which we can access the logs show exactly the same accept times.


if possible, would it be possible for you to show the mcproxy log output of when the miner posted that accepted block (that in the end was not accepted)? And also the debug.log file of the wallet?
It would really help to understand the issue. If the file debug.log is not present in the wallet directory, then you should relaunch the wallet with -debug and -debugnet options.

We have now setup a machine similar to yours (with five usb block erupters) with full debug log in order to see some lost blocks.

edit:

it seems that we got one case where the miner got an accepted block but it was not accredited as new block ,so we have the logs to study.... will follow up later.

[Deadalter]

Miners (cgminer or bfgminer) cant detect my ASIC USB Block Erupter.
Im instal driver and my PC see COM device.
Help plz