|
For the record, this is nothing like a regular orphan so drawing any comparisons based on that assumption are all misguided at best.
|
|
|
|
Actually quite a number of pools that use header only mining, btc.com viabtc f2pool btcc and btc.top all were mining on the invalid chain for a while there. I suspect the only reason there wasn't an extended fork was because the next block found was on the valid chain making them reorganise their own chains back to the correct one. Since the pools are not clear on when they switch from invalidated headers to validated blocks, it's hard to know exactly what might have happened. Here is the log of it hitting my pool's bitcoind and how my (0.13.2 core based) node handled it: 2017-01-29 06:58:50.871920 ERROR: ContextualCheckBlock(): weight limit failed
2017-01-29 06:58:50.896292 ERROR: AcceptBlock: bad-blk-weight (code 16)
2017-01-29 06:58:50.896352 ERROR: ProcessNewBlock: AcceptBlock FAILED
2017-01-29 06:58:50.896433 Misbehaving: 54.213.163.201 (0 -> 100) BAN THRESHOLD EXCEEDED
resulting in the propagating BU node being banned by my node. Followed by another node trying to submit the block again 2017-01-29 07:01:21.701452 ERROR: AcceptBlockHeader: block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 is marked invalid |
|
|
|
-ck, I'm guessing you may have my IP address blocked. I'm showing that my link to your pool is dead. It has always been "Active" before and failed-over successfully in the past. Whenever you get a chance, if you could take a look I'd appreciate it!  Thanks. username = whirledps1 (fixed now on the one miner to correctly use my BTC address as username) That IP should be unblocked by now, there are still 3 other users, including koh0907 - you are trying to put your btc address last in the username, it should be first. |
|
|
|
Dear users whirledps1 , orionberry and eagleUSER , you are repeatedly trying unsuccessfully to connect to his pool with a regular username. Please fix your login to only use a bitcoin address as your username.
Sorry. I have the pool as a backup and must have just copied and pasted my info into the pool slots when I changed main pools. I'll take care of it as soon as I can access my miners. Again, sorry. No nefarious intent! Hah, none assumed in the first place. Which username? I have blocked some IPs as a result but will unblock them if you're one of the blocked ones. |
|
|
|
|
Dear users whirledps1 , orionberry and eagleUSER , you are repeatedly trying unsuccessfully to connect to his pool with a regular username. Please fix your login to only use a bitcoin address as your username.
|
|
|
|
Can it be used in image processing systems, for example? Or can it be used to break different passwords?
High GPU cards are being used for image processing or password cracking experiments. ASIC machines are more powerful than GPU cards.
Can this be used for jobs?
You really didn't read the responses? Or do you just not believe us? No, absolutely no. Why is that so hard to understand? |
|
|
|
While trying to setup ckpool i needed a way to integrate ckpool with other pool frontends. So here's my version written in python https://github.com/ahmedbodi/PyCKDB/ATM it only handles user authentication and share inserts for MPOS. Tip Jar for anyone who finds it useful: 1D9sGeqx5TVzcCSdmiUqxtdqbc8puyVM9N I'll try and keep it maintained and up to date Ahmed Thanks for that, I'm sure someone out there might find it quite helpful. |
|
|
|
So on the next block -ck, will the stats reset?
If I fix it and restart the pool... which is likely to happen in the next couple of days. |
|
|
|
[2017-01-27 21:46:45.263] Possible block solve diff 29969507946342.382812 !
[2017-01-27 21:46:45.636] BLOCK ACCEPTED!
[2017-01-27 21:46:46.017] Solved and confirmed block 450328 by 1NrV55iVXdsDwoQYLnZK7DQMbhEmFDZyeV.barraccooda.025
[2017-01-27 21:46:46.017] User 1NrV55iVXdsDwoQYLnZK7DQMbhEmFDZyeV:{"hashrate1m": "766T", "hashrate5m": "770T", "hashrate1hr": "760T", "hashrate1d": "754T", "hashrate7d": "465T"}
[2017-01-27 21:46:46.017] Worker 1NrV55iVXdsDwoQYLnZK7DQMbhEmFDZyeV.barraccooda.025:{"hashrate1m": "4.96T", "hashrate5m": "4.67T", "hashrate1hr": "4.88T", "hashrate1d": "4.9T", "hashrate7d": "4.86T"}
Block solved after 163% diff shares. 3rd block solved by this miner/address, congratulations! https://www.blocktrail.com/BTC/block/000000000000000000096453b092e098538f56fb6889ec601cfa037ecb6ee540The share count/best share is still not resetting on the main pool so please ignore the reported value. This is the first block solved and submitted with the new code that's designed to submit code as quickly as possible across the different pools to help propagate it even faster than the relay network can. It was found and submitted at 45.263 on the DE pool which then confirmed it at 45.636: [2017-01-27 21:46:45.263] Possible block solve diff 29969507946342.382812 ! [2017-01-27 21:46:45.636] BLOCK ACCEPTED! It was simultaneously sent to the main pool for submission there; the main pool is 130ms ping away from the DE pool. The main pool then submitted it at 45.332, only 69ms later - which is exactly half the ping time and then the main pool confirmed it at 45.567 [2017-01-27 15:46:45.332] Possible remote block solve diff 29969507946342.382812 ! [2017-01-27 15:46:45.567] BLOCK ACCEPTED! So it was actually confirmed at the main pool earlier than at the DE pool where it was found, because the main pool's hardware is much more powerful than the DE pool. This would mean the block was propagated faster across the world than either pool could have by itself since it was propagated from both sides of the world at approximately the same time, making chance of the block being orphaned as small as possible. This is the new "remote" code I've been working on for some time in ckpool and is why there were so many restarts of the pool in the last month to implement. |
|
|
|
Exactly ! I hope though that the miners increase in numbers because that is the only solution I see to these slow confirmations.
Again another misunderstanding - the rate of transaction confirmation is the same no matter how many or few miners you have. The rate of block finding, and hence transaction confirmation, is kept constant by the bitcoin network constantly adapting its difficulty to maintain one block every 10 minutes on average. |
|
|
|
Ok, with cgminer-4.9.2, my AU3 ( https://www.amazon.com/gp/product/B016CWBYJK/) gets 12.5Gh/s over several days. With cgminer-4.10.0, it gets 8.5Gh/s over several days. The older USB miners all get the same on both versions. Both versions have all generic USB drivers enabled. I get the same results on both my 256M arm controller and an x86_64 desktop running Fedora 25. On the arm controller, both versions crash with "echo -n summary | nc 127.0.0.1 4028". I'm also getting a lot more accepted hashes with 4.9.2 - several times more, which the modest increase in total hashing power doesn't explain. Conclusion: There may be a (subtle and hard to debug) problem with 4.10.0. :-( Subtle or otherwise, if you do a git bisect to find the point of slowdown between 4.9.2 and 4.10.0 you should be able to find it what commit is responsible. If you're getting a crash on any platform, if you build a debug version (with CFLAGS -g only) and then run it in gdb you should be able to get a backtrace to find the crash debug. But if you're out of ram/resources, there's not much I can suggest. Also please don't post 3 consecutive posts for the same issue. Edit your last post or create a new post, deleting your old one. |
|
|
|
Just downloaded 4.10 for windows
Have an RX 480 Cgminer is bitcoin mining software for ASIC mining hardware, not GPUs. |
|
|
|
Does running an old miner that can't compete with the big guys at mining coins at least still help decentralize, secure, and support the bitcoin network?
It helps if you register your rig at miningrigrentals for example ! Unity is strength !  This makes no sense at all. It helps in a little way but not worth it in terms of your electricity bills.
And this we've explained multiple times is NOT the case at all. Since this thread is slowly getting derailed by posters who are either repeating what's already been said, don't know what they're talking about and/or are just adding posts to increase their post count, I'm locking it. |
|
|
|
|
There are four other recognised uses for ASICs depending on their physical size: Paperweight, book end, door stop and boat anchor.
In short, no. They really are that specialised for mining sha256d coins that they can't be used for anything else.
|
|
|
|
I know its a super small contribution, but it still adds to the network right? I mean if 10,000 people ran one old miner, it would start to be significant right?
No. Then again you have to define small. You have no idea how massive the network is at the moment compared to old miners. It's 3exahash, so you work it out for yourself. |
|
|
|
|
Not really in any significant way at all; it just costs you money in electricity.
|
|
|
|
The no. of unconfirmed transactions are constantly kept over 50000. It was over 70000 yesterday and went below 50000 for about 2-5 mins sometime back but then again pushed over 50000. Is it happening because the spammers are still on it constantly trying to keep the unconfirmed transactions over 50000? or has the spamming been stopped but the no. of transactions have been high now generally and coz of that the unconfirmed transactions are constantly above 50000?
It won't stay high; it looks like intermittent injections to keep it high as I said a few posts back. |
|
|
|
why do people think this or anytime mempool grows too big, that there is a spam attack going on! I mean unless you can see the transaction that are spam you shouldn't just assume that. in this case, there was an orphaned block ( https://blockchain.info/block-height/449695) and then there were less than 10 empty blocks that day which causes lots of accumulated unconfirmed transactions. The graph of rise in transaction sets at the time did not follow the normal stochastic nature of random transaction events. There was a perfect curve with a rise in the number of transactions starting from 2017-01-24 at 06:00 until it peaked at 17:00. After that there have been random injections into the network to keep the value high. The perfect curve is consistent with a single entity constructing a careful crafted set of injections into the network. See: http://statoshi.info/dashboard/db/transactionsChange the graph to see the last seven days and you will see why this is not just some random rise in transactions. There is also absolutely no reason orphans would affect transactions in any way you describe as bitcoinds would simply submit the existing transactions. Relatively empty blocks every so often is a common occurrence due to dodgy pool workarounds (see 10 billion other threads about empty blocks for explanations.) |
|
|
|
|
Show Posts
