|
Guiminer only mines CPU and GPU on the old mining protocol. CPUs and GPUs cannot meaningfully mine bitcoin today and the old mining protocol is no longer used either. So you cannot mine with either the hardware or the software you're using.
|
|
|
|
is down  r solo pool  Pool is fine but I have blocked about 5 users who have been trying to log in with invalid usernames repeatedly for days on end. PM me your IP address or post it here and I'll unblock it to see if that's it. |
|
|
|
That is true, Jihad, Antbleed and Asicboost does not mean, Segwit (with blocksize limitation) is good.
Correct, segwit is good absolutely, not relatively. |
|
|
|
Its not a massive percentage just more than i used to get before switching. But if there are a few restarts then that would explain it.
A number of short restarts coming up shortly for some updates.
All the restarts are complete. There are now a number of changes to both appearance and behaviour... Indeed there were 4 restarts in total for progressive updates. That would lead to far more rejects than usual so I wouldn't judge based on that. No restarts are now planned in the near future. |
|
|
|
@ck This is slightly off topic, but I figured here was as good of a place as any... I use CKProxy for all of my alt stuff, so I'm using it for here too (because it's good and I'm lazy). If/when my rigs find a block, does the console for CKProxy show like [date time] Possible block solve diff 1234567890 !
[date time] BLOCK ACCEPTED! when connecting to a BTC pool or just [date time] Possible block solve diff 1234567890 ! like I normally see? In other words, does CKProxy ever show accepted info or is it just that my alt pool software is as shitty as most alts are? I've never used it and found a block in a real pool. Ckproxy can't submit the block locally without the transaction information required to submit the block and stratum does not give that information so you will not see block accepted at any time from a normal ckproxy unless you're mining blocks without any transactions. |
|
|
|
Would 3 antminer S3 and 1 antminer S5 do me any good here? Or would it be waste of time? They just collect dust in a box
If it's worth you running them (and that's a different question) then this pool is the one most likely to get them up to a payout because of the way it accumulates payments till they eventually get a reward. Currently since the pool is still small they would probably get a reward on the first block solved too. Make sure to use the ONE username for all of them, but feel free to use different workernames. |
|
|
|
A number of short restarts coming up shortly for some updates.
All the restarts are complete. There are now a number of changes to both appearance and behaviour. The pool work now shows which users have their reward postponed and how much herp they've accumulated. This means it lists the users who will not receive a payout in the next block solved, but shows how much herp will be accumulated to contribute to one where they meet the threshold requirement to receive a payout. This also means that miners below the dust threshold will eventually get a payout once their cumulative rewards make them meet the dust threshold over enough block solves. Additionally as large coinbase transactions contribute negatively to miners latency, are incompatible with AVA2->7 devices, and contribute to many small miner rewards that end up costing a lot in fees to redeem, I have placed a limit on the number of transactions that will ever be included of 150. The top 100 miners will always receive a coinbase generation transaction with every block solved. The other 50 payouts will be interleaved amongst those who have reached payment threshold and are ordered by who has waited the longest for a payout. Miners will be able to monitor their accumulated herp if they've been postponed in the new user statistic "accumulated" and see how many times they've been postponed by the "postponed" variable. Realistically these limits won't come into effect any time soon as there are currently only ~50 users that have reached payment threshold. Once we get above 150 active users it will start coming into effect - which would also correspond with a larger hashrate so more frequent blocks, however the dust threshold miners will already be counted towards future solves. This concludes all my planned changes required to enable the pool to cope with as many miners of wildly varying sizes as could possibly be aimed at it, including what I think is a very fair offering for very small miners. And now for some blocks... |
|
|
|
Who got that 2PH and how much time?
I know the person responsible and they're trying to get their DERP up as quickly as possible on this first block with as much rental as they can reasonably grab from nicehash without pumping up the rental prices. Hopefully this culminates in us finding a block (or more!) |
|
|
|
Speaking of empty blocks, I recently discovered pools like OneHash (if I recall correctly) mining a number of empty (single transaction) blocks and wondered in fact if this eas deliberate. Why wouldn't they want to include txs in their blocks? Don't they make extra from the fees or does it somehow add to their difficulty?
Been discussed ad nauseam. It's not related to asicboost (though theoretically covert asicboost might need to occasionally make empty blocks): https://bitcointalk.org/index.php?topic=1085800.0 |
|
|
|
|
You left out: Yes - if it restricts what improvements we can make to bitcoin. And by that I'm not referring to segwit (although that's the one everyone's talking about); there are a lot of other features planned that will break asicboost.
|
|
|
|
what i do not understand is that Roger Ver is known to spend money to keep people in his side so that BU has some followers and he is know to be a big whale,but why is he not able to spend those money to get competent developers and testers before boasting about it, after all these failed attemps who is going to believe him.
Some people can't be bought? I joke that I'm bitcoin operated since I code for bitcoin, but I'd never code on BU just because he threw money at me (note I'm a mining/pool software developer, not core code.) so he tried to corrupt you too? all this under the table drama, make me think there is more than meets the eye here Not me personally, no. |
|
|
|
BU has developers?
No, just politicians and lobbyists. |
|
|
|
This just goes to show that we should not rush into options such as BU and segwit.
Lumping BU and segwit together in that same sentence is a terrible mistake. Segwit has 100x more coders that worked and tested it, and it has been LIVE on testnet for a very long time now, having received 1000s of times more testing than BU has. There is no "rush" with segwit. It was developed slowly and meticulously, and has been audited and tested by many very capable coders. The same can NOT be said about BU. |
|
|
|
Looks like bitcoin core is going to become a clone of litecoin core!
While I understand what you're trying to say, that makes no sense since the litecoin changes were all ported from bitcoin core... Bitcoin users in general value decentralization and the lightning network is nothing if not centralization.
And you all keep missing the point that lightning network can be implemented (albeit in a reduced functionality form) even WITHOUT segwit. As this is a recurring complaint about segwit, it shows how strong the FUD is when it's actually a non-argument. |
|
|
|
Bit concerned at the 'No symbol table info available' so maybe I haven't done it quite right. (gdb) bt full
#0 0x00007f589268cd62 in curl_easy_reset ()
from /usr/lib/x86_64-linux-gnu/libcurl.so.4
No symbol table info available.
#1 0x000000000042b432 in json_rpc_call (curl=0x0,
url=0x7ffe5025e208 "http://127.0.0.1:31000", userpass=<optimised out>,
rpc_req=rpc_req@entry=0x7f5889e0ead0 "{\"id\": 0, \"method\": \"getblockcount\"}\n", probe=probe@entry=true, longpoll=longpoll@entry=false,
rolltime=0x7f5889e0e96c, pool=0x1c8e880, share=false) at util.c:779
timeout = 60
all_data = {buf = 0x0, len = 0}
hi = {lp_path = 0x0, rolltime = 0, reason = 0x0, stratum_url = 0x0,
hadrolltime = false, canroll = false, hadexpire = false}
len_hdr = "Content-Length: 37\000\373\000\000\000\000\001\000\000\000\000\000\000\000\300\350\340\211X\177\000\000\n\375@\000\000\000\000\000\300\350\340\211X\177\000\000\333\350\340\211X\177\000"
user_agent_hdr = "User-Agent: cgminer 4.10.0", '\000' <repeats 38 times>, "\020\351\340\211\004\000\000\000\036\aF\000\000\000\000\000\000\000\340\211X\177\000\000\000\000\000\000\000\000\000\000\360\346\340\211X\177\000\000\360\346\340\211X\177\000\000\377\377\377\377\377\377\377\377\000\000\000\000\000\000\000"
curl_err_str = "h\350\340\211X\177\000\000jui\221X\177\000\000\200\350\310\001\000\000\000\000L\002A", '\000' <repeats 13 times>, "\240Č\221X\177\000\000\000\000\000\000\000\000\000\000\320\352\340\211X\177\000\000\320\352\340\211X---\177\000\000\033\353\340\211X\177\000\000\317\353\340\211X\177\000\000\320\352\340\211X\177\000\000\317\353\340\211X\177\000\000\000\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\000\277A\266L\347\004\306\004\000\000\000\000\000\000\000\300\350\340\211X\177\000\000\320\352\340\211X\177\000\000\272\333C\000\000\000\000\000\320\352\340\211X\177\000\000\200\350\310\001", '\000' <repeats 12 times>, "\b\374a\221X\177\000\000\003\b\000\000\000\000\000\000\060"...
headers = 0x7f5874000910
upload_data = {buf = 0x7f5889e0ead0, len = 37}
val = <optimised out>
err_val = <optimised out>
res_val = <optimised out>
probing = false
byte_count = 6.9178205667131595e-310
err = {line = 0, column = 0, position = 0,
source = '\000' <repeats 79 times>,
text = '\000' <repeats 159 times>}
rc = <optimised out>
#2 0x0000000000420a21 in longpoll_thread (userdata=0x1c8e880)
at cgminer.c:8426
val = <optimised out>
res_val = 0x0
cp = 0x1c8e880
start = {tv_sec = 1493105333, tv_usec = 94501}
reply = {tv_sec = 0, tv_usec = 0}
end = {tv_sec = 0, tv_usec = 0}
pool = 0x1c8e880
threadname = "0/Longpoll\000\000\000\000\000"
curl = 0x0
lpreq = "{\"id\": 0, \"method\": \"getblockcount\"}\n\000\060 detection via getblockcount polling", '\000' <repeats 948 times>
lp_url = <optimised out>
rolltime = 0
__func__ = "longpoll_thread"
#3 0x00007f58924496ba in start_thread (arg=0x7f5889e0f700)
at pthread_create.c:333
__res = <optimised out>
pd = 0x7f5889e0f700
now = <optimised out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140018247071488,
-1427088155123090364, 0, 140018255460783, 140018247072192, 0,
1333317430687595588, 1333296848420633668},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0},
data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimised out>
pagesize_m1 = <optimised out>
sp = <optimised out>
freesize = <optimised out>
__PRETTY_FUNCTION__ = "start_thread"
#4 0x00007f589161082d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
No locals.
(gdb)
Thanks for that. Added a change to git master which should address this. |
|
|
|
Bit concerned at the 'No symbol table info available' so maybe I haven't done it quite right. (gdb) bt full
#0 0x00007f589268cd62 in curl_easy_reset ()
from /usr/lib/x86_64-linux-gnu/libcurl.so.4
No symbol table info available.
#1 0x000000000042b432 in json_rpc_call (curl=0x0,
url=0x7ffe5025e208 "http://127.0.0.1:31000", userpass=<optimised out>,
rpc_req=rpc_req@entry=0x7f5889e0ead0 "{\"id\": 0, \"method\": \"getblockcount\"}\n", probe=probe@entry=true, longpoll=longpoll@entry=false,
rolltime=0x7f5889e0e96c, pool=0x1c8e880, share=false) at util.c:779
timeout = 60
all_data = {buf = 0x0, len = 0}
hi = {lp_path = 0x0, rolltime = 0, reason = 0x0, stratum_url = 0x0,
hadrolltime = false, canroll = false, hadexpire = false}
len_hdr = "Content-Length: 37\000\373\000\000\000\000\001\000\000\000\000\000\000\000\300\350\340\211X\177\000\000\n\375@\000\000\000\000\000\300\350\340\211X\177\000\000\333\350\340\211X\177\000"
user_agent_hdr = "User-Agent: cgminer 4.10.0", '\000' <repeats 38 times>, "\020\351\340\211\004\000\000\000\036\aF\000\000\000\000\000\000\000\340\211X\177\000\000\000\000\000\000\000\000\000\000\360\346\340\211X\177\000\000\360\346\340\211X\177\000\000\377\377\377\377\377\377\377\377\000\000\000\000\000\000\000"
curl_err_str = "h\350\340\211X\177\000\000jui\221X\177\000\000\200\350\310\001\000\000\000\000L\002A", '\000' <repeats 13 times>, "\240Č\221X\177\000\000\000\000\000\000\000\000\000\000\320\352\340\211X\177\000\000\320\352\340\211X---Type <return> to continue, or q <return> to quit---
Thanks. Don't worry about the symbol table warning. Need the rest too, after <return> till it stops giving output. |
|
|
|
Pool restart is planned shortly with further upgrades and improvements. Just need to mine some testnet blocks on the new code first.
Restarts complete. Sorry about the inconvenience. You can now monitor the pool's current work in the pool page by clicking on the pool.work link. Separate worker stats have been deprecated and the links will no longer work. Userstats now show workers with their workername first. Workers with zero derp or hashrate will no longer show up - once the pool has been running long enough, idle workers will eventually disappear from stats when they have no herp. |
|
|
|
JSON failed to decode GBT solo mining cgminer segmentation faultHi, I've found a bug in cgminer where it segmentation faults, possibly due to receiving an unexpected GBT format version. I couldn't seem to be able to open a github issue, so i thought I would report it here. The problem was found when attempting to solo mine against bitcoin classic. Issue raised can be found here: https://github.com/bitcoinclassic/bitcoinclassic/issues/259I don't think cgminer should segmentation fault. Thanks for that. It doesn't do it in my environment so can you please reproduce it with debugging enabled to get me a useful backtrace? Instructions here: http://ck.kolivas.org/apps/cgminer/debug/README-debug |
|
|
|
|
Show Posts
