Topic: [∞ YH] solo.ckpool.org 2% fee solo mining 256 blocks solved! - page 173. (Read 89163 times)

you will know you you mined a block when your best share is > than what is needed to mine a block.

I am using cgminer for my R606's - I don't see anywhere it would say I found a block - but I do check it regularly so if the best share was greater than the diff required, I would know I found one.

for my larger asics, they have a field in the UI where it shows the number of blocks found, if any.

Okay makes sense. So to obtain a block my difficulty must surpass the base difficulty of the block and for that to happen is entirely by chance/luck. When a share is expected, that doesn't mean a block is mined but means that the minimum mining diff was surpassed and a share was accepted by the pool in an attempt to mine the block. Sorry if I'm being an inconvenience, I'm trying to learn about it. I'm curious, how can you tell if you mined a block, Eth or BTC or any to be frank.

a share does not mean you hit a block. With the difficulty of your share (11.7k) and I would assume 10k was the lowest diff the pool would accept so your miner hit a share with a diff high enough for the pool to accept - not to get a block though. not sure when you hit this share of 11.7k but right now diff is 23.58 th - and your share was 11.7k - or you need higher than 23,581,981,443,663 and you got 11,700

i was mining with the SHA256 on ck pool. And my diff showed as 11.7k over 10k meaning that there was a block mined or I'm missing some crucial piece of information.

to be simple - a block erupter is an asic and can only mine SHA-256 so if you were trying to mine scrypt with it, there is no way you would have gotten a share on scrypt - someone correct me on that if I am wrong, but about 99.9% sure that I am not.

If you were mining sha-256 and got a share, then that would be expected - but if you were pointing it at ckpool, a share means nothing unless it exceeds the diff required to find a block --- you can have shares but not find any blocks, in other words.

I need help understanding what happened on my BFGminer. I'm experimenting with crypto and getting into ETH mining. But I have a usb block erupter i was toying with and trying to see if I can get it to script mine. But I left the bfg miner for ck pool running just for the hell of it and I ended up getting an accepted share which I have no idea what it is. My Efficiency reads at 12.66 and my Accepted share is at 1.

Left him all night... I have seen from the log, that he started to accept at 3 am, Spanish time.

For power consumption, the usb miner consumes hardly anything, right now it's at 67Gh/s... we'll see how long it lasts.

I still don't understand the statistics very well....
Thank you very much!


## Update, I have made some changes, we will see how it goes....
I am using cgmienr v4.9.2 compiled with redfury and u3 (icarus) support.

I have added the --suggested-diff parameter with value 128, and now it runs faster.
Is it advisable to add this parameter?
What I notice, with respect to bfgminer v5.5.0 is that the hashrate is slightly lower, with bfgminer, it was around 68Gh/s, with cgminer it's around 60Gh/s.



## Update 2, It has happened again... it has been going on for quite a while now.

Well these are your stats as of right now,  so its all up to you if you want to leave them solo, lottery or not

{
 "hashrate1m": "5.42G",
 "hashrate5m": "4.86G",
 "hashrate1hr": "5.17G",
 "hashrate1d": "4.03G",
 "hashrate7d": "1.41G",
 "lastshare": 1619502667,
 "workers": 1,
 "shares": 254478,
 "bestshare": 601946.0725657769,
 "bestever": 601946,
 "worker": [
  {
   "workername": "1DCRu4pnnwtbUYRy1evVw7TzXGW8XMwMNc.azagramac",
   "hashrate1m": "5.42G",
   "hashrate5m": "4.86G",
   "hashrate1hr": "5.17G",
   "hashrate1d": "4.03G",
   "hashrate7d": "1.41G",
   "lastshare": 1619502667,
   "shares": 254478,
   "bestshare": 601946.0725657769,
   "bestever": 601946
  }
 ]
}

Hi, I've been using a couple of RedFury and an Antminer U3 for a few days now, using bfgminer v5.5.0-28.

I don't understand very well the data, this morning the whole bfgminer console was showing many messages "Accepted XXXXXXXXX BPM X Diff x/x" and now it only shows "Network difficulty changed to 23.6T (168.8E)" and many "Stratum from pool 0 detected new block".

If you look at the statistics, now it shows 0 in hashrate1m and hashrate5m, I tried to reboot and nothing.  

Thanks.


Do you see it viable to leave this equipment playing the lottery... or is it completely useless?
It gives me peaks of 68Gh/s and troughs of 65Gh/s.

Rebooted and relaunched...

BTC 1DCRu4pnnwtbUYRy1evVw7TzXGW8XMwMNc

Guys! What is the best and most correct way to ping a stratum on osx?

Thank you very much

Your miners submitted 78075 shares with hashes below the pool's difficulty and they were accepted as valid shares by the pool, but they were not good enough to hit a block, the only thing to take out from the status is that your miners did connect and are doing "okay". until and unless they hit a block, the number of shares accepted means exactly nothing.

Hi Everybody, I'm a newbie, I found a couple of asic usb block erupter that I purchase in 2014, and just to see if they still work, I put them to mine in solo.ckpool.org with cgminer 4.10.0 which is the only one  software I found that works in Windows 10 and this old usb, I know if pointless because they don't have enought hash power, but for my surprise, in some point start to found something that I never saw in the past,  I saw some Accepted in the text screen, it was doing this for a couple of hours giving several Acepted, also take some pictures with my phone, until the cgminer stop to run, I am to figure what happend but I really don't understand what the stats means, if somebody can help me please.

Thanks in Advance

{
 "hashrate1m": "0",
 "hashrate5m": "0",
 "hashrate1hr": "654M",
 "hashrate1d": "756M",
 "hashrate7d": "353M",
 "lastshare": 1618539680,
 "workers": 2,
 "shares": 78075,
 "bestshare": 478709.6423020818,
 "bestever": 478709,
 "worker": [
  {
   "workername": "36zuYSiD44yKZEwDbPeMHcEXMuC9yaCQ69.0",
   "hashrate1m": "0",
   "hashrate5m": "0",
   "hashrate1hr": "654M",
   "hashrate1d": "711M",
   "hashrate7d": "219M",
   "lastshare": 1618539680,
   "shares": 46590,
   "bestshare": 16264.64072211665,
   "bestever": 16264
  },
  {
   "workername": "36zuYSiD44yKZEwDbPeMHcEXMuC9yaCQ69.1",
   "hashrate1m": "0",
   "hashrate5m": "0",
   "hashrate1hr": "0",
   "hashrate1d": "33.2M",
   "hashrate7d": "92.8M",
   "lastshare": 1618275277,
   "shares": 31485,
   "bestshare": 478709.6423020818,
   "bestever": 478709
  }
 ]
}

Regards

Sigh....
Please ref https://bitcointalksearch.org/topic/m.24714338
It would be a very very pointless enterprise.... Your share rate would be so incredibly low most pools would treat it as a dropped or offline connection 

In the news today
https://www.hackster.io/news/you-can-now-mine-bitcoin-using-your-vintage-commodore-64-49057d732c47
I know a pool I can test this out on (not ck's)
 

Thanx dude!

The pool no longer has a server in Germany, only one in the U.S, however, o_solo_miner has a passthrough located in Germany


108ms is more than good, there is nothing to worry about.

Why is there no Germany: mine to de.ckpool.org:3333 on this new page?
And i did a ping test to both germany and us pool and both gives me 108 ms, is that good?

I quoted you both because you two have the same concern, don't worry about the timestamp at all, NO, you won't lose a block because your clock is half a minute late/early, you can even mine blocks with a timestamp in that past.

If block 100 is mined at 2:00 AM and you manage to solve block 101 with a timestamp of 1:50 AM, it will still be accepted, there are basically two rules for the timestamp of a block, it can't be more than 2 hours into the future based on your node network adjusted time, and it can't be lower than the median time of the last 11 blocks.

As for the online explorers, some might be showing the timestamp on which they received the block based on their own clock, some will show the timestamp that is in the block itself, clocks are never 100% synced so all this variation is completely normal.

That's true. On the other hand, the timestamps correlate with the data from https://live.blockcypher.com/btc/
I cannot tell which source is more to be trusted to be accurate.

In regards to the deviating timestamps I think there would only be an issue if these were the consequence of the propagation of new blocks to/from the network being too slow, potentially giving another found block precedence.

The timestamp that is used for the mining process is anyway provided by the client and added to the mined block header. If I understood the stratum protocol spec correctly, any timestamp within about a minute is considered valid from the Bitcoin network's perspective.