If -- no WHEN I solve a block, will the good news appear in my stats at http://solo.ckpool.org/users/? Other than monitoring cgminer, is there anyway to know that I hit the jackpot? Or do 12.5 BTC just magically appear in my wallet? The money will magically appear in your wallet before any other notification since you get it as soon as it's solved directly to your wallet address. I wonder if there'd be a demand for a no-frills pool like this one for regular miners that does ordinary PPLNS payments? There seems to be little demand for new pools these days but perhaps there is a need for something people can set and forget like this solo pool that will take miners of any size and create coinbase payments like the solo pool does with a baseline ckpool code fee like 0.5%. I'd rather not take any hashrate away from the existing small pools but perhaps it might encourage more people to not automatically choose large pools if they have small hashrates, and might go some more way towards helping activate bitcoin core changes. What do miners think? |
|
|
|
Do you have any other suggestion for me?
Yes - ask in the altcoin mining section. |
|
|
|
Might have a memory leak when running ckproxy. Had a Pi start acting up this morning after running fine for about 3 weeks. Turned out it ran out of free memory and the watchdog had trouble killing it and killed some system processes instead. Checked the other Pis and the ckproxy process was using high amounts of memory. Percentage-wise the memory on most of them had gone over 60%, where on a fresh start it's more around 6-7%.
There could well be, especially if you're running older code. Try running latest git if you haven't upgraded lately as the code has been dramatically updated. When time permits I'll do a more extensive search for memleaks with the proxy code. |
|
|
|
|
Why the hell do all these radical proposals always come from new accounts? Are you all so scared of associating coordinating radical change with your existing online personas?
|
|
|
|
|
Will be restarting the pool shortly to reset the pool's best share values and incorporate a minor bugfix. Your best diff values will be reset along with this. It turns out that it resets the shares after a block is found but because of DE's remote shares being sent after the block solve data, the remote share may be seen after the blocksolve setting the best share again. This happened since I sped up the block propagation code between the pools dramatically. This means I may have to manually reset it when a DE block occurs again in the future, but I've built provision for manually resetting best shares to be able to do it without restarting now.
EDIT: All complete.
|
|
|
|
|
Why not? An internet connection is an internet connection, and mining doesn't require much bandwidth. It's been done before but adding latency to mining is a bad idea since you lose proportionately more shares as stale depending on the latency of the connection. However if electricity costs offset the share loss (which is likely) then it'd be worth it. Additionally 3G connections tend not to be very stable so disconnections are common but mining software reconnects pretty quickly. Certainly being far from a network tower would be a bad idea.
|
|
|
|
The statistical data have shown that bitcoin unlimited has more supporters than the core developers.
I assume you mean more mining hashrate, not "more supporters" since the core deployment is almost ten times larger than the BU deployment by node count. Mining hashrate comes down to an extremely small number of people with extremely large mining hashrate in their power. |
|
|
|
the problem is that LN alternative are also centralized with their HUB, at least from what i understood, it seems that you can't preserve the current decentralization if you want to fix the block limit/scaling issue
if they cna coem up with something better would be better but there is no time anymore, now the choice is based on what is less worse, not on what is ideal
I didn't say anything about LN. Most people think all the transactions will go to LN which is also completely wrong. To start a lightning channel one must create a regular transaction and then only can LN transactions occur, BUT LN will only work for microtransactions. It's not going to be possible to use it for transactions larger than .042 btc. There will still be heaps of on-chain transactions and consequently transaction fees for miners. If LN increases the userbase of bitcoin dramatically by making the proverbial 'cup of coffee transactions' possible by the general public without dumping them all into the blockchain, the overall transaction fees ending up in miners' pockets will go up substantially anyway. Furthermore, most types of LN transactions can still be implemented even without segwit so it's not like signalling segwit is voting for LN. Even if segwit doesn't get activated, LN will be implemented. Read more about some of the most common misconceptions about LN and mining here: https://medium.com/@rusty_lightning/miners-and-bitcoin-lightning-a133cd550310#.skccp131tIf miners weren't so quick to jump to conclusions and make wild accusations BU would never have even been considered and subsequently the threat of a hard fork and PoW change wouldn't ever have been discussed. Either way I doubt a hard fork and PoW change are going to happen anyway. |
|
|
|
|
You cannot meaningfully mine bitcoin with a PC by itself. The fastest PCs are 1000 times slower than the average modern ASIC and 500 times less efficient. So laptop or PC makes no difference, you cannot meaningfully mine bitcoin.
If you're talking about altcoin mining though, that's a different story.
|
|
|
|
My understanding after 6 months involved in the space is that bigger blocks lend towards greater centralization due to increased costs of running nodes etc (storage, bandwidth).
For this fact alone I would never support a block size increase if there were other viable options available.
That certainly would be a problem with a substantial size increase, but there is another more immediate problem even at only 2MB blocks - the quadratic sighash scaling problem. It's possible to DoS the network with transactions that are very heavy handed in input/outputs for their size leading to block verification that can take a very long time to complete. The 1MB block that took 25 seconds to verify a while back on fast hardware was an example of that in action at only 1MB blocksizes. The code that does the verification is much more efficient now but still would have taken 11 seconds to verify. Double the size of that and you have a block that takes almost 45 seconds to verify. 6MB blocks and you have blocks that can take longer than the average time between blocks of 10 minutes. Slower hardware would hit that limit at even smaller block sizes. Segwit transactions scale linearly with signature hashes so 1MB of signatures for segwit transactions are a lot faster than 1MB of normal transactions, and linearly for 4MB of transactions, which is the maximum possible allowed with segwit as currently coded. That 4MB of transactions would take less than 1MB of normal transactions to verify. Note that most blocks are NOT that sighash heavy but the fact remains that it is a mechanism to DoS the network. |
|
|
|
the same pools that were mining segwit before are still mining it now, so there doesn't appear to be any increase in support and this is just variance related to pool luck.
It could be those pools (BCC and Bitfury) have increased their share of the hashrate. Which of course is also temporary The downturn back to the same level of ~26% suggests not. It was just variance. Now if f2pool is actually considering signalling segwit, that would be a totally different story. |
|
|
|
Congratulations, another DE block! [2017-03-26 23:14:44.748] Possible block solve diff 642177867894.756592 !
[2017-03-26 23:14:44.861] BLOCK ACCEPTED!
[2017-03-26 23:14:44.911] Solved and confirmed block 459083 by 1JfDwdSURAxgWqbQRQz4sY12wniGY3Sxtj
[2017-03-26 23:14:44.911] User 1JfDwdSURAxgWqbQRQz4sY12wniGY3Sxtj:{"hashrate1m": "897T", "hashrate5m": "961T", "hashrate1hr": "947T", "hashrate1d": "228T", "hashrate7d": "146T"}
[2017-03-26 23:14:44.911] Worker 1JfDwdSURAxgWqbQRQz4sY12wniGY3Sxtj:{"hashrate1m": "508T", "hashrate5m": "507T", "hashrate1hr": "488T", "hashrate1d": "104T", "hashrate7d": "72.4T"}
[2017-03-26 23:14:44.911] Block solved at 392% diff @ de.ckpool.org!
For those wondering about the pool's best share value, it is now showing the best share of the last block found. If most people prefer to have the old functionality back, please tell me and I'll code it in and restart the pool to adopt that. |
|
|
|
Judging solely by mores law, it would probably be safe to have a max block size of 8 MB 2 years ago if 1 MB was safe 7 years ago.
Except that we fell off the curve for Moore's law years ago. Technology is struggling to grow at even 1/4 the rate Moore's law predicted now. |
|
|
|
in the past i remember they said that they were prone to increase the size of the block to 2mb, apparently they changed their mind later...
It's okay to change your mind once you investigate the change and see that it is actually a bad idea to implement it. Too many people are obsessed with a plain block size increase as being some kind of simple change that carries with it no dangers, which we know now is actually completely wrong. |
|
|
|
I'm waiting for the BU supporters to chime in and say I'm interpreting these charts wrong or something  Maybe my mention of the 4 special trolls forum members has made them NOT post as a way of trying to prove... something? |
|
|
|
Yet we will still continue to see new "BU is winning, hard fork imminent!!" threads spamming the board every 4 hours for the next week probably. Facts no longer matter, only the loudest proclamation matters it would seem. It's a wonder how some people can still tie their shoes.
If you put precisely 4 people on ignore, you'll see absolutely no threads or responses in this regard and would wonder why anyone would consider BU a realistic topic of discussion. Hint none of them have posted in this thread yet, but they'll be here shortly. |
|
|
|
|
This is a private forum. There is no guarantee of freedom of speech, and there are forum rules. There's a 100% chance that your post was deleted because you broke forum rules, not because your opinion was against that of the forum admins.
|
|
|
|
I think the decision to ignore mining in the reference client, was the wrong one. This, I wholeheartedly agree with. Two years ago core devs were saying mining had almost nothing to do with the core implementation which was a very shortsighted view. The lack of emphasis on the delicate interplay between mining and the reference implementation of the bitcoin network protocol and the block chain was a major setback. Of course one could ask why I didn't get involved then since I was busy hacking on mining code and the answer is a simple one: I don't have any faith in my c++ coding skills so it would have been presumptuous of me to try and hack on bitcoin core. |
|
|
|
|
Show Posts
