Just to clarify, this and the shared pool are compatible with the upcoming segwit component of the New York Agreement AKA segwit2x soft fork and any blocks we find will be valid and accepted.
Can ck signal bit 1 and bit 4 both? Yes we're signalling BIP91 and BIP141. |
|
|
|
|
Both of my ckpools are on BIP91.
|
|
|
|
Keep using core 0.14.2 and wait till segwit is locked in and wait for many confirms on any transactions until then in case of chain reorganisations.
I'd like to add: ... and for the love of all that is Bitcoin, take all of your BTC out of anywhere where you don't control the keys..... Definitely do this too. Right now everyone should be pulling everything out of the exchanges they've been treating as banks. |
|
|
|
OK - looks like miners colluded (intention) down to about 90% and choose SW2x - question: what have nodes to do now ? Keep using core 0.14.2 and wait till segwit is locked in and wait for many confirms on any transactions until then in case of chain reorganisations. |
|
|
|
No. The only evidence of mining activity is everyone switching to a BIP91 compatible client. Does anyone have links or information concerning the supposed large number of BIP91 renditions? Is there really a possibility that some might be more inclusive of the 2x portion of segwit 2x and others do not have that 2x portion in their code? There's no way to tell from the blocks alone, but I can speak for at least 4 pools I know of that are running BIP91 only clients  |
|
|
|
Would there be a UAHF on August 1? 1. UAHF on August 1. 2. Segwit2x hard fork by November. This UAHF wouldn't fork the complete network, right? Miners could opt to mine on BCC (altcoin) chain. This is a bit confusing, why go through the whole Segwit2x drama when they still want to deploy UAHF? Maybe because they know there wouldn't be a majority for the hard fork on November? https://medium.com/@ViaBTC/statement-on-bitcoin-user-activated-hard-fork-6e7aebb67e67There won't be a UAHF because segwit will get activated before then. |
|
|
|
No. The only evidence of mining activity is everyone switching to a BIP91 compatible client. |
|
|
|
I lol so hard at the BU blocks. Why? Why oh why! -edit- looks like the BU blocks are slowly dying so whoever was running BU nodes is slowly migrating.
Never fear, the big blockers will be back with their next hard fork coup attempt in the guise of bitcoinABC. |
|
|
|
|
Just to clarify, this and the shared pool are compatible with the upcoming segwit component of the New York Agreement AKA segwit2x soft fork and any blocks we find will be valid and accepted.
|
|
|
|
I have a question,
Since I've read an article that bitmain will split BTC and all the pools they are managing are signaling all blocks with segwitx2
What we will get if we find a block after the split?
This and the solo pool are compatible with the upcoming segwit component of the New York Agreement AKA segwit2x soft fork and any blocks we find will be valid and accepted. Of course we need to actually have a hashrate to find blocks... |
|
|
|
Hopefully it shall help us crack this elusive block. . .
In ck's [BETA] pool, elusive block cracks the pool! - sorry ck, I couldn't resist .earl Dammit I should be annoyed but that's funny. |
|
|
|
|
One by one the pools are starting to solve BIP91 blocks so there is no sign of any of them pulling out now. This of course doesn't mean they're running the btc1 branch as there is a popular BIP91 only branch available too that has only the segwit component of segwit2x...
|
|
|
|
If you want to run a pruned node but have the storage capacity to download the whole blockchain it is indeed much faster to download the whole blockchain and then restart bitcoind in pruned mode to do the pruning afterwards since it is constantly being pruned during the download process otherwise.
Have you actually measured that? If it's true-- it's a bug. the pruning should delete a whole blockfile at a time (128MB) and shouldn't take much time at all. It's totally plausible to me that there is a bug here, but I've not noticed it myself or heard it reported before. Only when pruning was first available did I experience this and I did not do a fair comparison of identical hardware so no I cannot say for certain. I've not downloaded the whole blockchain since. |
|
|
|
Sorry, not completely sure I follow you here. You want me to rebuild with debugging and send you the logs, or you want me to sign up for backtrace service? Can I please ask you to elaborate? Rebuild with debugging and get backtrace output as described in the README-debug I linked above. |
|
|
|
You're all my heroes and you shall be nicely rewarded for your dedication in time.  |
|
|
|
Taking the pool down yet again, sorry I'm unhappy with how it's running.  Hopefully the downtime won't be too long. I still have hope we will find that block! Good luck ck fixing the pool! Thanks. Found some showstopper bugs now that there is a decent hashrate and a lot of users in the pool and have corrected them. This is all the usual level of embarrassment with major bugs in production code but always the danger with beta code. I apologise profusely for this. Pool is back online and I'm doing a lot of regression testing in the meantime still... Wetsuit's rental is a very substantial contribution to the pool and greatly appreciated. Hopefully it shall help us crack this elusive block and put this behind us. |
|
|
|
Taking the pool down yet again, sorry I'm unhappy with how it's running. Hopefully the downtime won't be too long. |
|
|
|
Dear CK,
I am experiencing a Segmentation Fault (core dumped) error when trying to write config file in version 4.10.0. (I do not have this error with version 4.9.2).
(it seems to write over cgminer.conf with an empty file, then crash)
I am running on R-PI, ARCH.
Any advice?
Thanks!
This didn't seem to get any kind of acknowledgement. I'm following it up here to see if anyone can help?? Any chance you could get a backtrace? Google's gone crazy with blocking my website again so you may have to override security settings if you're on chrome. http://ck.kolivas.org/apps/cgminer/debug/README-debug |
|
|
|
Code exploded with that and didn't find a block so I'm gonna take the pool down for a bit to resuscitate it. None of your share counts will be lost. EDIT: Back online with fixes, and changed minimum diff to 16k to appease NH. |
|
|
|
Is there any way to set the minimum difficulty for the pool? I would like to help out with some rentals to crack the first block.
Not really with rentals, no. But then people have rented up to 16PH without a problem on this pool. It's designed to cope easily with massive hashrates (though it hasn't seen that much of them yet.) I tried renting at Nice Hash but it stopped my order because they need a minimum starting difficulty of 16384. No way to get around this? Most nicehash rentals haven't had a problem before. Because nicehash intermittently drops and reconnects the pool is repeatedly adjusting diff. Just try stopping the rental and starting again, or set it at a low hashrate to start with and then bump it up. |
|
|
|
|
Show Posts
