Bitcoin Classic is not an altcoin Some people, not a million miles away from being the owner of this forum, may disagree. Thanks for the info re timer, didn't know that. Yeah. I know. The funny thing is, if he really believes that stance, then technically it isn't true until a hardfork happens. Up until then all the classic nodes are running on and helping strengthen the one true Scotsman's bitcoin network. |
|
|
|
|
Edit: please see OP for info about using worker names in addition to your username. It works the same way as ckpool.
|
|
|
|
Shouldn't this thread be in "Altcoins"?  Can't tell if making a joke. Some make that argument, but Bitcoin Classic is not an altcoin. Classic Nodes still act exactly the same as Core nodes (or btcd nodes or any other bitcoin node) until 75% of the last 1000 blocks are mined by Classic nodes. At that point a 28 day timer starts. If that 75% level is maintained for that 28 days then on day 29 the Classic nodes can start processing, mining, and relaying blocks larger than 1 MB. |
|
|
|
so basically, we can just enter our current bitcoin address, and in case we hit a block, export the private key and import it in bitcoin classic? Sounds cool... I'm going to fire up my sidehack stick when i get home this evening  My only question is "why?"
Why should anybody use your pool instead of ck?
Why should anybody believe you 25btc if your pool find a block?
Why do you not know anything about orphans?
and etc.
Is the ck solo mining pool also mining for the classic chain? Lol, no, I doubt CK's pool will support Classic. He said he will switch if the hardfork happens. Note that if the hardfork happens and is permanent, it is in a miners or pools best interest to switch. There is a 28 day grace period for people to switch. If the initial fork is with around 75% of hashing power as planned, then mining on the old chain will become a waste of hash power AND blocks will be found very slowly on that chain, making propagation of blocks on the new chain even more prevalent. |
|
|
|
so basically, we can just enter our current bitcoin address, and in case we hit a block, export the private key and import it in bitcoin classic? Sounds cool... I'm going to fire up my sidehack stick when i get home this evening That might work. I'm honestly not 100% sure how it all works when the hardfork happens. Pre-hardfork coins will still be valid on both chains I think. I don't think wallets need to change unless the wallet you're using is bitcoind or bitcoin-qt. Even then, it might still be OK. All that matters is if your transactions end up in a block on the new chain and not the old. I believe If all goes as planned, all miners and pools will switch and it won't be an issue. |
|
|
|
My only question is "why?"
Why should anybody use your pool instead of ck?
Why should anybody believe you 25btc if your pool find a block?
Why do you not know anything about orphans?
and etc.
Why? Because there wasn't already a "solo pool" running on Bitcoin Classic. Also because by the nature of my mining setup I needed to put an instance of ckpool up, so I figured I would open it up to whoever else wanted to use it. Why instead of -ck's pool? If you want to support the Bitcoin Classic hardfork effort with your hashrate. Why should anyone believe me 25btc? I guess you mean why should anyone believe I will actually pay out? I suppose I can't prove that I will until we actually hit a block. I consider myself trustworthy and have done business with a number of forum members here over the past year or two with not a hint of untruthful actions or words. Other than that you just have to take my word. Why do I not know anything about orphans? I do actually know things about orphans. I'm using -ck's own open source pool software in a minimal setup on modest hardware. The only added risk of orphans over -ck's pool is that he probably runs on better hardware and may have direct connections to other fast nodes or the relay network. I'm considering connecting to the relay network, but it appears it is no longer maintained. |
|
|
|
|
Thanks for the quick replies.
|
|
|
|
Ah okay I wasn't sure when the block notify was triggered by bitcoind. Thanks for that info.
I have a follow up, seemingly basic question that I couldn't find an answer to elsewhere... Do all miners everywhere concurrently work on the same block with the same transactions in it, or are the contents of a block at the discretion of each miner (assuming there are more than enough transactions on the mempool to cover more than one block worth)?
Sorry for getting a bit off topic...
Same workinfo, same transactions for everyone. So I think I phrased that wrong or confusingly. By miners I didn't mean miners on the same pool. I meant I guess pools as mining entities, or maybe more accurately mining nodes. Wouldn't each node or pool potentially include a different transaction set per the block they are working on? Sorry these are probably really basic questions I can answer by re-reading the white paper or some other source. I do have a more ckpool-specific question... Before I had the notifier and blocknotify setup on my bitcoind, there were times my miners were working on work that appears to be from previous blocks. It also seemed that ckpool would timeout when trying to get work from bitcoind. None of this happens anymore. Is that because the "blockpoll" method is taxing on bitcoind? Or is it because requesting a new blocktemplate during verification causes slowdowns? Or both? |
|
|
|
|
Ah okay I wasn't sure when the block notify was triggered by bitcoind. Thanks for that info.
I have a follow up, seemingly basic question that I couldn't find an answer to elsewhere... Do all miners everywhere concurrently work on the same block with the same transactions in it, or are the contents of a block at the discretion of each miner (assuming there are more than enough transactions on the mempool to cover more than one block worth)?
Sorry for getting a bit off topic...
|
|
|
|
|
@ -ck
Can you elaborate from a high level what exactly happens when ckpool is notified by the notifier? I can see that it seems like miners start in on a new block immediately. How does ckpool decide which transactions to put in that new block? (I ask because it seems like miners start on the new block before the last one is fully downloaded and verified... But I could be mistaken on that). I'm guessing since all we really need is the hash of the previous block we can start with that before its fully verified? Or am I really wrong in thinking that we are working on the next block before the last one is fully verified?
I see this on the first post:
"New work generation on block changes incorporate full bitcoind transaction
set without delay"
But from experience, I don't see the delay surrounding block changes that seemed to be present when mining directly to a node via GBT, so just a little curious how this works.
And yeah I know I can probably figure this all out by diving into the code, but I don't read code very well and was hoping a high level explanation wouldn't be too much of an ask.
|
|
|
|
|
Interestingly, it may actually have been working fine. I got similar errors on 64-bit as well. Issue seemed to be hangups with bitcoind. Adding more RAM and setting bitcoind to properly use the notifier seems to made it all work a lot smoother. Still running it on 64-bit.
|
|
|
|
|
I have to restart for some changes/upgrades. Standby...
Restart done @ 9:45 PM EST: doubled RAM and tweaked some settings.
|
|
|
|
What is a valid address?
1. using old bitcoin 11.2 wallet address?
2. using a brand new address created with the new classic wallet?
There is no difference. Bitcoin Classic does not create a new form of wallet addresses. |
|
|
|
|
Cool. Just keep in mind this is beta quality at best. Payouts if a block is hit will be extremely manual... as in I'll search through the logs by hand to verify then manually process the payment.
|
|
|
|
Environment is 32-bit ... Ckpool demands a 64 bit environment and I have no interest in creating support for 32 bits sorry. Interesting. Thanks for clearing that up. |
|
|
|
Hi ck I'm getting the same errors over and over. I cloned and built from commit db42a13. Built with all dependencies satisfied. No build problems that I can remember. Running from build directory, not installed. Environment is 32-bit Arch Linux Arm running on a Raspberry Pi2. I haven't yet taken a dive into the lines of code specified here. Was hoping maybe this is something you've encountered before with an easy fix. Any help/pointers would be much appreciated. Looks to me like stratifier and generator are not starting. I checked and all the sockets and such are getting successfully created in /tmp/ckpool. bitcoind is slow in responding sometimes on this box. Not sure if that could cause this issue. command line: ./ckpool -k -A -c ../ckproxy2.conf ckproxy2.conf: {
"btcd" : [
{
"url" : "localhost:8332",
"auth" : "[user]",
"pass" : "[pass]"
}
],
"update_interval" : 30,
"serverurl" : [
"127.0.0.1:3334"
],
"mindiff" : 1,
"startdiff" : 1000,
"maxdiff" : 0,
"logdir" : "logs",
"btcaddress" : "[address]",
"btcsig" : "[sig]"
}console output: [2016-02-14 07:35:22.481] ckpool stratifier starting
[2016-02-14 07:35:22.481] ckpool generator starting
[2016-02-14 07:35:22.482] ckpool connector starting
[2016-02-14 07:35:22.483] ckpool connector ready
[2016-02-14 07:35:27.484] Select1 failed in recv_unix_msg (2) with errno 2: No such file or directory
[2016-02-14 07:35:27.485] Failure in recv_unix_msg from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:27.485] Failure in send_recv_proc from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:32.487] Select1 failed in recv_unix_msg (2) with errno 2: No such file or directory
[2016-02-14 07:35:32.488] Failure in recv_unix_msg from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:32.488] Failure in send_recv_proc from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:37.490] Select1 failed in recv_unix_msg (2) with errno 2: No such file or directory log output: [2016-02-14 07:35:22.475] Setting maxclients to 921 due to max open file limit of 1024
[2016-02-14 07:35:22.481] ckpool stratifier starting
[2016-02-14 07:35:22.475] Setting maxclients to 921 due to max open file limit of 1024
[2016-02-14 07:35:22.481] ckpool generator starting
[2016-02-14 07:35:22.482] ckpool connector starting
[2016-02-14 07:35:22.483] ckpool connector ready
[2016-02-14 07:35:27.484] Select1 failed in recv_unix_msg (2) with errno 2: No such file or directory
[2016-02-14 07:35:27.485] Failure in recv_unix_msg from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:27.485] Failure in send_recv_proc from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:32.487] Select1 failed in recv_unix_msg (2) with errno 2: No such file or directory
[2016-02-14 07:35:32.488] Failure in recv_unix_msg from stratifier.c stratifier:7546 with errno 2: No such file or directory
[2016-02-14 07:35:32.488] Failure in send_recv_proc from stratifier.c stratifier:7546 with errno 2: No such file or directory |
|
|
|
Hmm that reminds me I've had this problem before. If you authed first on the DE pool you cannot auth on the main pool later on. I thought I'd fixed this bug but it seems to have returned. That would explain it. I'll look into it.
Is this related to a bug I posted about a couple weeks ago? Well, I guess I don't know if it's a bug or a flaw in the way the miner operates, but just wondering. The IP address of solo.ckpool.org changes after a DDoS and perhaps these devices almost never look up the IP address using a cached result for ages. In which case a restart might be required, either of cgminer or the whole device.
I have restarted the whole device 3 times (one of those was power off for 20+ minutes) and it still is in failover, I'll see if I can't flush its dns cache or something, thanks. I had the same bug a couple of weeks back, all I had to do was change the address I was mining to.
I could not locate any sort of dns reset in the S3 interface so I tried changing addresses and the pool was ALIVE again. I changed back to the old address thinking maybe I had cleared up the issue, but the old address reports the pool as DEAD. A new solo address for the US node it is then! Problem solved, thanks. Changed mining to a new address and all seems to be well. Note that it had to be an entire new address, not just worker name. (so now I have different addresses for DE and main, but I suppose that's OK) |
|
|
|
|
Show Posts
