Code them up together, but allow each component to be activated *separately* thus allowing clients to choose which component they wish to support... I suspect support for BIP102 will be a lot higher now (yes I know about quadratic scaling issue.)
|
|
|
This topic's been done to death, nothing but sigspam haven now so I'm locking it.
|
|
|
There's a good chance you're not aware that your computer doesn't do the mining; you need ASIC MINING HARDWARE to mine bitcoin. Slush support thread if you are actually mining, please use it: https://bitcointalk.org/index.php?topic=1976.0/locked
|
|
|
Until I can figure which column to remove to fit in a new one, I've pasted in the OP pie charts which label pools and preferences (from coin.dance).
Thanks... ironically you left out the graph for segwit blocks. Freudian?
|
|
|
Tried to set up ckproxy on a Raspberry Pi. Threw these errors while making stratifier.c: In function ‘read_userstats’: stratifier.c:5126:2: warning: passing argument 1 of ‘json_get_int64’ from incompatible pointer type [enabled by default] ckpool.h:371:6: note: expected ‘int64_t *’ but argument is of type ‘__time_t *’ stratifier.c: In function ‘read_workerstats’: stratifier.c:5179:2: warning: passing argument 1 of ‘json_get_int64’ from incompatible pointer type [enabled by default] ckpool.h:371:6: note: expected ‘int64_t *’ but argument is of type ‘__time_t *’ stratifier.c: In function ‘read_poolstats’: stratifier.c:8487:2: warning: passing argument 1 of ‘json_get_int64’ from incompatible pointer type [enabled by default] ckpool.h:371:6: note: expected ‘int64_t *’ but argument is of type ‘__time_t *’
ckpool/proxy is 64bit only. Did you compile it on a 32 bit environment?
|
|
|
All tx paying 0.0001btc fee, All are straight into a block - no waiting, (are they even in the mempool numbers?) All blocks found by bitfury.
There's a good chance they were lingering for a very long time before being mined by bitfury. Just because they're not seen elsewhere doesn't mean they were just sent that instant. Many nodes will simply not have had the transaction in their mempool but they could have even been sent a week ago. While most nodes tends to have the same high fee transactions in their mempool, when the network is busy the lower fee transactions visible on each node are wildly different. There must be at least an equally good chance they were not lingering in the mempool. This clearly needs further investigation. Funny if they are all shown to be in bitfury blocks, unseen by other nodes. (queue jumping) I haven't got time tonight, maybe you, or someone else will look properly? No worries, it's all on the blockchain. Definitely looking into it... I see other pools have mined transactions to the same address; only the ones that were mined on the same block coincided with the same pool (obviously.)
|
|
|
This is hardly the place to argue your opinion. I'm simply asking OOC to list what the pool supports. The terminology is up to him, I don't care what you call it, legacy or whatever you want... "current" maybe?
|
|
|
All tx paying 0.0001btc fee, All are straight into a block - no waiting, (are they even in the mempool numbers?) All blocks found by bitfury.
There's a good chance they were lingering for a very long time before being mined by bitfury. Just because they're not seen elsewhere doesn't mean they were just sent that instant. Many nodes will simply not have had the transaction in their mempool but they could have even been sent a week ago. While most nodes tends to have the same high fee transactions in their mempool, when the network is busy the lower fee transactions visible on each node are wildly different.
|
|
|
OOC, given the block size debate is currently an issue, would it be too much to ask to signify what pools are running? legacy, segwit, BU or miner's choice?
Sure, is there an already existing list available that I can add to the tables? Not as far as I know, but I think the following is what I see from signalling (of the public pools): Segwit: BTCC, Bitcoin India, Bitclub Network, Solo ckpool, Bitminter BU: btc.top, bitcoin.com, gbminers, ViaBTC Option: Slush Legacy: Everyone else? EDIT: Check here: https://coin.dance/blocks
|
|
|
Finally got the block. I was just perusing which pools are signalling segwit yet and notice this one is still not signalling segwit (though I recall you saying something about doing it at some stage in the future?) And it's an empty block despite being almost 2 minutes after the previous block D:
|
|
|
Does solo.ckpool work with usb asic with 8 suggested difficulty ?
An Antminer R1 is running with diff 4 on solo pool Nice to know that But when i connect it shows diff 4000 --suggest-diff 8 It will switch to 8 as soon as it can with that. Otherwise, just wait and eventually the diff will adjust down anyway.
|
|
|
Mining bitcoin with GPUs is not remotely fun these days and hasn't been for many years. You'll probably get about 500 megahash, though there is no point even finding out exactly... which will earn you nothing but cost you heaps in electricity and heat strain/wear on your GPU. Bear in mind an average ASIC miner on sale today starts at 6 terrahash; that's 12 thousand times faster than your GPU for about double the power consumption of your GPU.
|
|
|
I've never heard of them, which is a bad sign in the first place.
|
|
|
I am having the exact same issue. Did you ever figure out a solution?
These devices had a very high failure rate with time and considering you're responding to a post that is almost 2 years old, I would say the answer is no. Mine died completely within a few months.
|
|
|
You're on linux so bring up 'top' while it's happening, press H to enable thread mode, and see what thread(s) is/are consuming CPU at the time. The bitcoin daemon has lots of threads that are named so you may be able to track which particular thread is consuming CPU and hence figure out what it's doing.
|
|
|
I suggest you put your post in the support thread for whichever pool you mine at instead of listing details that mean nothing by themselves.
|
|
|
|