|
There's so much wrong with this...
Current bitcoin does not support mining with getwork or stratum. It only supports giving you GBT templates. Which means you need a full featured miner that can read the GBT templates and create work out of them. Plain CPU mining software cannot do it. Cgminer can, but it is only designed to support ASIC mining hardware. Alternatively you need to add full pool software, like ckpool, between bitcoin and your mining software, and even then, your mining software must also support stratum mining.
Short version: You cannot use bitcoin qt/core as a mining server which is what you're trying to do. You need full featured mining software or pool software to generate the mining work.
|
|
|
|
While running some tests on the pool software, I see lots of clients being dropped.
What do you make of this:
[2015-07-17 02:33:05.328] Client id 753 fd 22 RDHUP in epoll
[2015-07-17 02:33:05.329] Connector dropped client 753 fd 22
[2015-07-17 02:33:05.329] Opened client path /tmp/ckpool/stratifier successfully on socket 14
[2015-07-17 02:33:05.329] Closing file handle 14
[2015-07-17 02:33:05.329] Closing file handle 9
[2015-07-17 02:33:05.329] Connector recycling client 750
[2015-07-17 02:33:05.329] Closing file handle 744
[2015-07-17 02:33:05.329] Stratifier received request: dropclient=753
[2015-07-17 02:33:05.329] Stratifier asked to drop client 753
[2015-07-17 02:33:05.329] Dropped client 753 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Is this normal behavior or a problem?
If your clients are disconnecting, they're disconnecting from their end... there's nothing a pool can do to force them to stay connected. |
|
|
|
Luck it is then......  Yes |
|
|
|
Wow guys - that's some blocktastic green run you've got going on there, well done! Do you think it's because of your modifications -ck mentioned earlier?: Gimme gimme........  The modifications are custom and private, sorry  Pools need to have some advantage. I'm intrigued...... No |
|
|
|
Even if the math does work out (which I'm having trouble believing), in all honesty I think you're grossly overestimating the capabilities of the two pools that could possibly be doing this... and their own block size handling is working against such an "attack" with regular (transaction) empty block solves  |
|
|
|
Does no one use it any more?
Does it still work?
I've not been able to get it working since upgrading to Bitcoind v11 a few days ago..........  I'm on 0.11 as of recently as well. Perhaps that's the common issue... |
|
|
|
My relay said Relay network is using a later version (PLEASE UPGRADE) So I obediently upgraded. I can't see any blocks being propagated in the messages any more. |
|
|
|
So what kind of upgrade did you do? Hardware? Software? Both?
VPS was upgraded to a KVM instance, for what it's worth Ckpool is unchanged for quite a while now, though I'm constantly updating and tweaking bitcoind - but that happens seamlessly without miners noticing anything. |
|
|
|
Pool going down as scheduled, will post as soon as it's back up...
Pool back online. It only took <15 minutes. Sorry about any inconvenience; the server is faster now as a result. Small blip for a restart just now. |
|
|
|
|
Pool going down as scheduled, will post as soon as it's back up...
|
|
|
|
I want to give you advanced notification that there will be ~30 minutes of downtime 24 hours from now while the server this pool resides on is upgraded.
There will be 30 minutes of pool downtime at 00:00 UTC time on 15th July 2015.
Make sure to have backup pools enabled during this time. If you have a contract for a large hashrate already paid for that goes over that period please tell me and I can reschedule the downtime.
A reminder that the pool downtime is scheduled for 2 hours from now. |
|
|
|
It's almost too bad that there's any BTC awarded for finding a block. Those pools would change their tunes very quickly if they got nothing from finding a block. You can bet they'd stuff every transaction they could into a block.
As the block reward halves and transactions become a more significant proportion of the income they will need a different approach but for the time being the transaction rewards add only a little, though it's getting more every day. In a year when the reward is only 12.5 BTC, then the current transaction rewards of .25+ will regularly amount to 2%. It can only but rise with time, but not soon enough for the existing pools to give a shit about their empty blocks if people keep mining there. |
|
|
|
Cool. Look for a correlation between percentage of empty blocks and hashrate.
Why's that? It's just that most of them use the same software that takes the same shortcut to cope with its lack of scalability by building transaction free blocks first every time and what you're seeing is the larger the pool, the more that scalability problem becomes pronounced thereby mining more transaction free blocks.
Strictly speaking, with stratum mining the "load" is proportional to the number of miners, not the absolute hashrate but hashrate is a surrogate marker of number of miners. |
|
|
|
This is interesting. Data has been kernel smoothed against blocks solved, but plotted against time.
Cool. Look for a correlation between percentage of empty blocks and hashrate. |
|
|
|
megabigpower,
antpool,
kncminer, and
discussfish
are so far above the average with their number of
coinbase-only blocks that it might be safe to say
that they a sabotaging the Bitcoin PoW deliberately?
They're not trying to sabotage PoW deliberately. It's just that most of them use the same software that takes the same shortcut to cope with its lack of scalability by building transaction free blocks first every time and what you're seeing is the larger the pool, the more that scalability problem becomes pronounced thereby mining more transaction free blocks. |
|
|
|
How about listing those pools that are churning out empty blocks & therefor not contributing to the Bitcoin Network? We will continue do SPV mining despite the incident, and I think so will AntPool and BTC China.
Another very good reason people should not mine on Chinese pools. This is EXTREMELY bad for the Bitcoin network.It would help miners make a more ethical decision about what pool to use & also help decentralize the hash power away from the bigger pools who aren't towing the line Do you have any data on percentage of empty blocks per pool? I think these are both valuable to disclose - SPV mining and empty blocks. Empty blocks at least someone has already done an analysis on this thread: https://bitcointalk.org/index.php?topic=1085800.0Updated for blocks in 2015 up to block 365,401:  |
|
|
|
Tricky. I wouldn't include anything that wasn't either provably correct or only from your own experience, or start up a thread that discusses your experiences with various pools.
I'd go further and say just include objective information. That table is all subjective stuff. |
|
|
|
Congrats to 1L2gJpLMsmRr3wuP6zqiTCcX2UzLDEmFz! The blocks are flowing today "hashrate1m": "468T", "hashrate5m": "476T", "hashrate1hr": "481T", "hashrate1d": "232T", "hashrate7d": "43T" https://blockchain.info/tx/fca207f95153cdda4ae67e20e93ebf55636b38f178b210b7bdcf4120198e031b[2015-07-12 01:58:39] Possible block solve diff 1009643823403.144043 !
[2015-07-12 01:58:39] BLOCK ACCEPTED!
[2015-07-12 01:58:39] Solved and confirmed block 364927
Nice big fat block amidst all the transaction flood too (of course we never mine transaction free blocks) Number Of Transactions 2079 Size 965.9541015625 KB Transaction Fees 0.55827336 BTC |
|
|
|
|
Show Posts
