|
Pretty big best share already. That would have been a block a few weeks ago if the diff wasn't going to the moon, or maybe more like Saturn.
|
|
|
|
|
The point is bitcoin is successful, and still decentralised, which means it is ALWAYS available for someone to try and take it over since NO ONE is effectively in charge of it. Think about that and the fact it has a 40 billion dollar economy behind it now. Basically the answer to your question about when it will end is NEVER.
|
|
|
|
UPDATE:
The ASIC's usually return a nonce if at least the first 32 bits of the found hash are 0 (I think this is called a Work Unit).
But something doesn't fit with 4.10.0 as it finds only a few nonces (ie. the "Proof" lines printed).
I'm testing this on AntMiner S3. Or is the definition of such a WU differrent under AntMiner S3?
Dear author, can you please comment on this important issue as it could be a big bug affecting many people, thx.
The S3 code in master cgminer filters out low diff nonces. |
|
|
|
Except that there was a disagreement about whether they should roll back their block chain to recover the lost funds...
Most specifically funds that were lost privately and having nothing to do with the chain.  Indeed and there have been other funds lost since yet they didn't do a further rollback. What a sham. |
|
|
|
I thought the scary time in bitcoin was over but to be honest.. I was wrong  Indeed everyone's celebrating the safe landing of segwit without a blockchain split but that was never going to be the worrisome part of segwit2x, it's the 2x part  |
|
|
|
Possibly to try combat it in future is one reason I think that its got support because no one wants to go through all that carry on again. But I do see now why mess when with something that's not technically broken!
For the reference I have no problem with a 2MB base block size increase. I have a huge problem with a rushed hard fork without core's support which is the one thing most likely to lead to a split in bitcoin since its inception. November 1 is not far away and I see no reconciliation in sight. This sounds like what they did to ETH. Except that there was a disagreement about whether they should roll back their block chain to recover the lost funds. There's no such disagreement here that we shouldn't do a block size increase at some time, it's just a matter of how soon. Which means that for the sake of a time frame disagreement we're looking at a blockchain split :\ |
|
|
|
Possibly to try combat it in future is one reason I think that its got support because no one wants to go through all that carry on again. But I do see now why mess when with something that's not technically broken!
For the reference I have no problem with a 2MB base block size increase. I have a huge problem with a rushed hard fork without core's support which is the one thing most likely to lead to a split in bitcoin since its inception. November 1 is not far away and I see no reconciliation in sight. |
|
|
|
I pulled all my rental coin out of nicehash and no longer rent from them.
You have issues with their service now? Are you still renting anything? MRR is probably the only other substantially sized renter available as far as I'm aware. |
|
|
|
Block #477392 solved by 1MEq97jjRKrmSwgVLJirB1ZcrEvnURUAhj  congratulation I second that! Congrats! [2017-07-24 12:59:47.557] Possible block solve diff 968803270026.079346 !
[2017-07-24 12:59:47.652] BLOCK ACCEPTED!
[2017-07-24 12:59:47.670] Solved and confirmed block 477392 by 1MEq97jjRKrmSwgVLJirB1ZcrEvnURUAhj.r35192
[2017-07-24 12:59:47.670] User 1MEq97jjRKrmSwgVLJirB1ZcrEvnURUAhj:{"hashrate1m": "405T", "hashrate5m": "400T", "hashrate1hr": "383T", "hashrate1d": "87.2T", "hashrate7d": "118T"}
[2017-07-24 12:59:47.670] Worker 1MEq97jjRKrmSwgVLJirB1ZcrEvnURUAhj.r35192:{"hashrate1m": "318T", "hashrate5m": "310T", "hashrate1hr": "296T", "hashrate1d": "40.5T", "hashrate7d": "50.2T"}
[2017-07-24 12:59:47.673] Block solved after 113994199677 shares at 14.2% diff
Lucky block It was only 12 seconds after the block before it. 2017-07-24 17:59:35.610026 UpdateTip: new best=000000000000000001290cd8f91689506ce1f38e05acdf1ec1d3fcdcc52c6535 height=477391 version=0x20000002 log2_work=86.817537 tx=241568059 date='2017-07-24 17:59:27' progres
s=1.000000 cache=617.8MiB(303646tx)
2017-07-24 17:59:47.648430 UpdateTip: new best=0000000000000000012288cec644c7ab65fcce61adaf30316ce1ccfcc99791f9 height=477392 version=0x20000002 log2_work=86.817573 tx=241570404 date='2017-07-24 17:59:35' progres
s=1.000000 cache=618.2MiB(305602tx)
Interestingly enough the block wasn't even full because the pool's bitcoind memory pool was almost completely empty after that block because it was so close to the one before it. Makes one wonder about what the urgency is for 2 capacity increases in the blockchain now that the transaction spam has ended... |
|
|
|
But now that the segwit part has been concluded they seem to have stopped signalling for the hardfork! Which is very odd - as if this was what they wanted they could have just signalled for segwit originally and not had this whole segwit2 lockin process.... That's not correct. There is no signal for the hard fork, only the NYA comment in the coinbase that they're committed to doing so. The hard fork is assumed to already be locked in based on the signalling that's already happened. Of course that doesn't mean that they'll go ahead with it unless they all use btc1 compatible clients... |
|
|
|
3. A relatively small miner, ViaBTC decided to do a hard fork to a coin that incorporates the original Satoshi bitcoin design that had unlimited block size and no segwit. At this point the ViaBTC initiative should be irrelevant and of no consequence
Even ViaBTC can't dedicate all of their hashrate to BCC, because they're a Bitcoin mining pool. I can't fathom why they thought it was a good idea It was no more than a counterthreat. ViaBTC is just a subsidiary of Bitmain anyway. |
|
|
|
|
Not this shit again... If you want to discuss the pros/cons of blocksize/segwit/bu/classic/xt/abc/whatever, take it elsewhere. This thread was about development and activation of segwit2x. I know it's hard to believe that you can discuss one without the other but that's bullshit - you just want to talk about what your current gripes are and find a way to link it into this discussion. I think this thread has run its course and will only be useful in 3 months' time again. I can't even be bothered moderating posts that stray from it so I'll just lock it.
|
|
|
|
Dr. Haribo, have you switched over to supporting BIP91 and will the pool be ready to support SegWit blocks tomorrow?
This pool has been signalling BIP141 segwit for a long time. Even without BIP91 support, since basically 100% of blocks are signalling BIP141 now there is no realistic problem without supporting BIP91. |
|
|
|
As for no commitment, some of those are the vocal pools against segwit. What it means is they're not currently mining blocks that can include segwit transactions. It will be a valid block even once segwit is locked in but won't include any segwit transactions if they do that. It also means less fees for them so I doubt they'll do that indefinitely, though they might happily sacrifice it just on principle. The players involved are certainly that way inclined...
In addition it appears that eloipool users (which includes antpool and eligius), the segwit commitment is only included once there are segwit transactions. |
|
|
|
I see that now since BIP91 is locked in, the % of miners signaling has gone down. Interesting.
Yeah.. now it is around 85%. But now the attention seems to have shifted to BIP 141, which is having around 95.1% support now (95.0% support needed to lock in BIP 141). All the blocks seems to be signaling BIP 141 without exception. Signalling bit 4 AKA BIP91 serves no purpose now that its action is locked in. The important part is enforcing it, meaning rejecting any blocks that don't have bit 1 AKA BIP141 set. On the other hand, bit 4 is meant to be signalled up to the time of the 2x hard fork so pools dropping it now might mean something. More likely it's just shuffling of coin daemon code/settings. You are right, signalling bit 4 has no point now. I wonder though what you think about Antpool, GBMiners, Kano CKPool and Slush registering as "No!" under the Witness Commitment heading at xbt.eu Oops I made a mistake in that statement. Bit 4 gets dropped entirely after segwit gets activated and is no longer used. There is no way of knowing who's going to enforce the hard fork component, only their NYA comment gives an indication of intent but isn't used for activation. As for no commitment, some of those are the vocal pools against segwit. What it means is they're not currently mining blocks that can include segwit transactions. It will be a valid block even once segwit is locked in but won't include any segwit transactions if they do that. It also means less fees for them so I doubt they'll do that indefinitely, though they might happily sacrifice it just on principle. The players involved are certainly that way inclined... |
|
|
|
Rejecting the non-segwit blocks should start in how many hours exactly? 24 hours ?
114 blocks at last count which is ~19 hours. |
|
|
|
Its really incredible how this miners suddenly jumped in and save the day for us.
What's incredible is that you can possibly think that when the very same miners were the ones who held back on activating segwit the proper way, fucking it up for everyone and making a safe process precarious. Even though we're getting segwit, we're now staring down the barrel of a rushed miner code driven hard fork. |
|
|
|
|
That's because cgminer is ASIC MINING HARDWARE controlling software and you are trying to mine with a GPU. If you want to mine with a GPU you can only meaningfully mine altcoins and with different software so you're in the wrong place. I will help you and lock this thread for you so you can start again.
|
|
|
|
|
Show Posts
