Segwit activation will happen on LTC and then... nothing will happen. LTC will continue to be as useless as it's always been and people will realise and its value will drop to its same baseline. However, what this will achieve is finally some good publicity for segwit in general since activation will be such a non-event where nothing bad happens and people will wonder what the fuss was all about. This will indirectly be good for bitcoin's segwit implementation - therefore this almost certainly will be the single most useful thing LTC has ever done. Which is a good thing since that's what altcoins were always meant to be in the first place - a playground for ideas for BTC; that got forgotten years ago and altcoins are just everyone trying to ride the next market capitalisation wave to be rich. They're all just playgrounds for pump and dump.

Anyway good news for segwit.

Don't fall into the trap of assuming all kinds of malice going on just because they're doing something wrong in the first place. A lot of bitcoin nodes are almost certainly being run as services on linux machines which are designed to restart in the event of a crash. This last crash was an out of memory error so restarting the node probably will be all that's needed until the memory gets out of control again. I'm pretty sure that none of them even are using a bugfix yet for this latest issue. They just have their nodes set to restart in the event of a crash... or actually what it looks like to me is they're set to crash in the event of a restart 

And despite so many core implementations out there, no instances of crashes taking down large numbers of any version of them. The stability record of core is exemplary.

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.)

Extra Crashy

Reading further into comments it's not even clear this is an exploit being attacked at all and could well be a spontaneous 'coordinated' bug due to network conditions causing a massive memory leak on the BU client. One person said he didn't have problems on his PC with 256GB ram 

https://twitter.com/alistairmilne/status/856405606630133761



I'm more worried about other sorts of exploits in code of this quality...

I wonder if there will be a closed or open source update for this one?

Correct it will be limited in feature set without segwit because of the malleability issue but that doesn't mean LN can't be implemented.

So scaling by making the blocks bigger is a solution so that you can put every cup of coffee transaction into the block chain? How much will fix it? 2MB? 4, 8, 16, 32? If you really wanted every coffee purchase to go into the blockchain you'd need approximately 2GB PER BLOCK. That means you're proposing a solution where the blockchain eventually grows at 2 terrabytes per week. Sure, we're not going to put every coffee purchase into the block chain today, but what if there was a solution that actually allowed you to do it? We're looking to create a transaction system that replaces the existing monetary one, not just supplement it. Note, I'm NOT saying that we shouldn't make the block size bigger, just that your solution doesn't fix microtransaction scaling. Off chain microtransactions (and note that LN as proposed will only allow transactions up to 0.0042 BTC so it IS being designed with per-coffee transactions) require an on-chain transaction to open the channel. Now if you really don't want bitcoin to be able to handle coffee sized transactions in one way or another, then that's a different argument all together. However it really doesn't matter what you want, LN will be implemented regardless on either core as is at the moment, segwit core or BU. There's nothing to stop an off chain payment channel system from being developed that works. Everyone is concentrating on segwit as though it's what will make LN possible - it improves what can be done with LN but there's nothing preventing LN being developed even with the current blockchain.

My service moved from supported to ready; i.e. ready is a HIGHER status for me than support. I am definitely supporting AND ready. While it is distinctly possible that a service may be "ready" without explicitly stating they are supporting segwit, the vast majority have moved to ready as a result of making their service ready because they support it.

The pool is still building up stats because this is the very first stats and hashrate. Your derp will never again be as good as it currently is, but if our first block is lucky you really will get that sized payout. Once we have reached 100% diff you will get a more realistic estimate of what your derp will stabilise to for long term mining.  We are currently less than 10% network diff so it has a long way to go.

When will we find a block? No one knows, on average we'll find a block once every 100% diff, but it could be 0.1% or it could be 1000%.

Yes

It should hopefully.

Welcome and good luck. If our first block is very lucky then you will reach a payout this block.

No this is an assumption you're making that is completely wrong. Some of us are experts in this area and can tell you beyond a shadow of a doubt their claims are impossible.

Put simply, the mining still works in the absence of asicboost being enabled, and that mining doesn't break with segwit. None of the public miners that have mined on testnet have been unable to mine blocks, and segwit is enabled on testnet.

Yes. You have an abysmal hashrate consistent with trying to mine diamonds with toothpicks, i.e. GPU mining bitcoin. You might find a block before the end of the known universe, but it's unlikely.

CPU and GPU miners are not welcome here, please stop doing so. You are needlessly using up resources for futile mining.

See I don't think we will find out. Because with so much uncertainty regarding what amounts to a hostile takeover, the ones mining the takeover attempt are putting their investments at massive risk when sticking with core is a safe way to maintain a stable economy, with or without segwit. The problem lies in not knowing what Roger Ver's actual motives are and why he's spending so much money trying to create a hostile takeover - the industry and the community has voted and is mostly against it. He's even running a mining pool at a loss to try and get community miners to add hashrate to BU (pool.bitcoin.com). I can speculate there but I prefer not to because I don't wish to fall into the trap of believing yet another conspiracy theory. The number of conspiracy theories out there at the moment is quite absurd. As a coder I can argue the technical side and I try to look at things objectively but as I've decided what I think is best, someone will instantly call me a shill or troll so I tend not to argue very strongly, especially against the 4 vocal trolls. People like yourself on the other hand have been trying to hold a civil meaningful discussion. I don't have the intestinal fortitude to fight with trolls so I just put them on ignore. I'm quite sure I don't even need to tell you who I'm ignoring; think about it yourself and what names come to mind... and why?

EDIT: I just saw your bitcoin core 0.14 post and changed my mind about you being civil. It's a software announce thread, not a debate thread.

Retarget at 1/4 the hashrate would take 4x longer. So? You think relatively slow blocks for a month longer would make a 20 billion dollar industry jump ship to something they have no confidence in?

By the way, they are NOT running the client as I already said. They added BU flags into their coinbase signature but all the antpool mining bitcoin nodes are showing up as bitcoin core clients. It turns out they don't actually trust the BU code, they are just using it as a leverage. Lucky for them since one pool already fucked up one block by trusting the BU code.

And as for "activate" BU in whatever form that takes, it would be nice to see because with 5000+ core nodes out there, the core node users would be completely unaware that a BU chain had started, only the slow blocks you speak of would be noticed. After one diff retargetting things would be back to normal. You're grossly exaggerating what would happen IF a BU based forked chain began. There will be no "destroy the chain" unless there is a concerted effort from them to waste all their hashpower and generate useless blocks on the core chain - such a move would cost them tens of millions of dollars of lost power and revenue in a short time. As if the bitcoin space doesn't hate them enough, such a bastard move is nigh on criminal on a massive scale and THAT would make the value tank for all forks of bitcoin.

Understand that you are in a minority thought pattern here, defending their actions. Once 4 vocal trolls are removed from bitcointalk, it fairly closely represents what's happening out in the node space with 5700 identifiable nodes running core and 630 running BU - and that number is falling. Yes miners have a lot of power, but they cannot direct things as easily as you think to destroy bitcoin core.

BIP 100 came and went two years ago from core as an idea. For a while there it had over 75% pool support, but no code was ever written for it. It simply allowed pools to vote on what the block size was and core decided it was a bad idea to give 100% of the power to the miners to choose... turns out that probably wasn't such a bad thing to not support it.

I agree. His threat was just that, a threat. If he was serious he would have put all his hashrate on BU anyway, and as it stands all he's doing is signalling BU in his coinbase; he is not actually running BU nodes. I've always suspected his BU threat was just a bargaining point after UASF was mentioned but now he's mined himself into a corner and is persisting with something he probably never intended to do. We'll see what he really does should the hashrate climb further and see if he persists with forking into a BU world just out of stubbornness now.

Agreed too, but let the bigblockers have their day for today. Let them fap to variance.