Topic: Blockchain split of 4 July 2015 - page 10. (Read 45588 times)

I don't think so besides BTCNuggets, F2Pool, and Antpool for 6 block rewards and wasted time and effort. There were no transactions in the fork except for the first invalid block from BTCNuggets which I believe got confirmed in the correct chain.

did anyone LOSE BITCOINS as a result of this issue ?? That's what really matters ..

Okay, I'll try to help.
Yes.  The software doing the block version upgrade to V3 was watching and had counted 950 of the last 1000 blocks having contained headers that said "block version=3".  Once that happened, any further blocks whose header said  "block version = 2" were supposed to be rejected.  

And at precisely that moment, at absolutely the first block where a "version = 2" block ought to have been rejected, BTCNuggets mined a block whose blockchain header said "block version = 2."


Slight edit here:  F2Pool and AntPool were not running correct software.   They had taken correct software and then deliberately modified it to make it wrong.  They stripped out the functionality of actually checking the block they were building on, because time spent checking a block for validity is not time spent mining, and - ASSUMING the block you've received is correct - spending more time mining makes you more money.  So F2Pool took this "version= 2" block from BTCNuggets, failed to check it, and built a "version = 3" block as the next block in the chain.  This version-3 block was not valid because it was built on a block that ought to've been rejected, but they'd never checked.  F2Pool and Antpool then built further on this new invalid block, never actually checking the original block from BTCNuggets.  If they had checked that block, they'd have known that the blocks they were building were invalid because that parent/grandparent/etc block originally built by BTCNuggets was invalid by the v3 rules.

When they did this, they built a chain that every full node checking the block chain and running correct software for block-version-3 would immediately reject no matter how long it got.


Yes.  Miners that had not deliberately introduced this bug into their software, simply ignored the bad chain because its blocks are invalid, and continued to do as they always do - to work to extend the longest valid chain.  Likewise all v3-enabled clients were also ignoring the bad chain and would not regard a transaction as "real" unless it were included in a valid chain.  


Regardless of how far ahead the bad branch had gotten, nobody running correct V3-checking software would ever have been using its blocks as a criterion of whether a transaction were successful, because those were invalid blocks.  The bad fork could still be adding blocks today, and people running up-to-date software would be in absolutely no danger of being fooled.  As far as a full node is concerned, your transaction is not confirmed until it is in a VALID block.  

The only reason people were in danger of thinking a transaction was confirmed when it in fact was not, is because a lot of them are subject to exactly the same bug that F2Pool and AntPool deliberately added to their otherwise-correct code - they are not fully checking blocks for validity.  

In some cases this is because they are running lightweight phone clients or SPV wallets.  Some of those check most of the requirements for validity, but there is one condition that they cannot check without downloading the entire block chain, and that is that in order to be valid a block must be built on a valid parent block.

In other cases this is because they are using web wallets at places like blockchain.io, and have no idea whether or not the people holding their keys are checking the validity of blocks according to the v.3 rules. - in which case it's best to assume that they are not, otherwise  you're going to get "confirmed" transactions which later disappear.


Approximately.  


Six.  Assuming nobody decides to mine another one.


Yes.  They had deliberately introduced a bug into their code to avoid "wasting" time checking the validity of blocks.


Perhaps they knew BIP66 had gone into effect, but they weren't checking validity, so clearly they didn't care.

Pretty sure it doesn't matter; given what they'd done to their mining software it would have done the same thing regardless.

Yes, absolutely.

Nope,  I checked.  There is no off-by-one error in the functionality that they cut out of their client.

Because of not being willing to spend one-tenth of a second checking a block when that tenth of a second could be spent mining.  


ALL OF THEM.  The blocks between the current block and the genesis block.  When you receive one block you need to check one block.  And if you keep doing so, then at any given moment you're going to have complete proof of the validity of EVERY BLOCK from genesis to the current block.  


Clearly not at issue here; in more than one case, the previous block was more than ten seconds old before the next block came out, meaning there is absolutely no way that any attempt to check it was made.  Any such check would have failed WELL before then.

Well forcing everyone to upgrade defeats the purpose of a soft-fork. The idea behind a soft-fork is that the new rules are still valid under the old rules. This makes soft-forks much easier to carry out and they are backwards compatible. What you are suggesting would be to make every soft-fork a hard-fork, which requires that everyone must upgrade otherwise they will be left off of the network. This is much more difficulty to carry out and I think such hard-forks have and will have the delay, alerts sent out, and monitoring of the situation before and after the fork.

Also, I would assume that all of the developers of Bitcoin stuff would be on the Bitcoin Development Mailing List (pretty big assumption). This mailing list discusses all of these changes when they come out and anyone following it would know that the BIP66 soft-fork was coming soon.

As I said above, this makes it a hard-fork, which is much more dangerous than a soft-fork and much more difficult to do. Also, disconnecting and alienating all nodes running v2 would disconnect more than 1/6 of the network. According to getaddr.bitnodes.io, it appears that more than 1000 nodes out of 6000-ish nodes are running old software, be it Core 0.9.5 or earlier or other old software. This would lose a significant portion of the network, and probably break Bitcoin's credibility.

Maybe... They want to avoid hard-forks because those can more negatively affect Bitcoin than soft-forks do. In situations where a soft-fork is not required, then a soft-fork will be done.

I believe that it has been both confirmed and proved by F2Pool and AntPool.

Thanks for the replies, @knightdk.  You write:


I doubt that 1% of the bitcoiners out there know what a BIP is.

I doubt that 0.1% of the bitcoiners out there knew that a soft fork due to BIP66 was due to happen this year.

A 2-week delay would have allowed the devs to send an alert to all nodes and miners still runing v2 to upgrade immediately or risk being cut off from the network and having their feet eaten by the boogeyman while they sleep.

A 2-week delay would also allow any v3 nodes that were turned off to catch up with the blockchain, and determine whether BIP66 was already in force of not.


After BIP66 became active, any v3-running miner, node, or client should have ignored (or have disconnected from) any nodes that it knew were still running version v2.

More generally, the core devs approach to protocol changes seems to be like that of an airline that lets a plane take off with a known engine malfunction, and tries to fix it during flight -- because it does not want to alarm or inconvenience the passengers, or get bad exposure in the news...

And, AFAIK, "SPV mining" is only the most likely theory, not confirmed or proved yet.

I second that....this guy is good.

so much for the security advantage of bitcoin
because of massive hashrate
compared to altcoins.....

another urban legend
to make bitcoin look superior busted

I just wanna say good job to the OP above me for those awesome answers and for taking the time to reply to them, really made this thread make some more sense for us that aren't as techsavvy.

Pretty much.

6 or 7

I believe that they were using custom software for SPV Mining. SPV Mining means that the miner does not validate the block before beginning to mine on it. Thus, when F2Pool and AntPool received the v2 block, they did not verify the block but simply assumed that it was valid.

Yes, However, as I said above, they were SPV Mining so they did not validate the block which was in fact invalid by the new rules.

Probably from a node that still considered v2 valid such as Core 0.9.3 or lower.

Yes

SPV Mining

It most likely did not come from a v3 node.

I think it is B(M-6) because that is what the hard fork detection in Bitcoin Core looks for (I think, could be wrong)

Ideally they should wait for the verification of B(M), but, we all know that miners are greedy little bastards, and they will most likely not wait for the verification to complete because it could mean the difference between having their block win or having it lose.

I don't think that a delay would have made a difference. BIP66 has been public for months, and so has the clients supporting it. Really the only way I think that the remaining miners would switch is after they realize that their v2 blocks are no longer being accepted because who likes change?

Can't really stop the reception of blocks, but F2Pool's own devs do deserve a lot of the blame for having SPV Mining that did not validate the blocks at all.

No argument about what bullshit miners and the rest of the Bitcoiners are capable of. Most of it hasn't affected the software because it was in the social realm.

My beef here is with the randroid/"objectivist" corner here, which is quite large (or perhaps just very visible). I see this event as an excellent debunking of their ideology. I have chosen to bring up "anti-fragile" because it has played into their childish belief that they can be as self-centered and anti-social as they want, and Bitcoin would continue to function. Now we've all seen that's not the case.

I am still trying to understand what actually happened.

What I have read is that BTCNuggets, a miner that was still running v2 software, mined a block B'(N) that was valid by v2 criteria but invalid by v3 criteria. Somehow F2Pool, a miner that was running v3 software, received the header of this block and successfully mined a block B'(N+1) that was valid under v3 rules (empty, in fact) except for having an invalid parent.  As luck would have it, they also mined another (empty) block B'(N+2) with B'(N+1) as parent.  Then AntPool, who was running v3 software too, mined B'(N+3) on top of B'(N+2).  And so on; this was the 'bad' branch.

Meanwhile, other miners running v3 software either did not see block B'(N), or saw it and detected that it was not v3-valid; so they ignored it and eventually mined a block B''(N) that was v3-valid.  Several v3 miners solved additional v3-valid blocks B''(N+1), B''(N+2), etc. on top B''(N).  This was the 'good' branch.

For a while, the bad branch was ahead of the good one, in terms of total work.  Fortunately the devs and other bitcoin hackers were watching the blockchain to monitor the onset of BIP66, spotted the problem immediately, alerted F2Pool and AntPool that they were mining a v3-invalid chain, and sent out an alert recommending a 30-confirmation (5 hour) wait for important transactions.

Is this a correct summary of the events?

Some of the many questions that remain:

* How many blocks were actually mined on the bad branch (starting form B'(N)) before it was abandoned?

* Were F2Pool, AntPool, and the other pools that mined on the bad chain running modified versions of the v3 core? If so, what were the modifications?

* Did F2Pool realize that the BIP66 rules had already started to apply when they received B'(N) from BTCNuggets? (Say, perhaps it had counted only 949 v3 blocks, or had its counter reset recently, etc.)

* How did F2Pool get the header of the invalid block B'(N): directly from BTCNuggets, from a v2-running relay node, or from a v3-running relay node?

* In the standard version of the v3 core software, do miners get the whole parent node and verify its validity?

* Could there be an off-by-one bug in the v3 core software, that would have resulted in F2Pool verifying B'(N) with pre-BIP66 rules instead of BIP66 rules?  (Note that a v3-valid node *can* have a v3-invalid parent, if the parent was mined before BIP66 went into effect.)

* If F2Pool knew that BIP66 had kicked in, and got B'(N) from a v2-running miner or node: why was it still accepting transactions, blocks, and block headers from v2-running players, without checking whether such data was v3-valid?

* If F2Pool knew that BIP66 had kicked in, and got B'(N) from a v3-running node: which node was that, and why did it forward the v3-invalid node B'(N) to F2Pool?

* If a miner receives a block B(M), how many blocks B(M), B(M-1), B(M-2) etc. should it validate on its own before daring to mine B(M+1) on top of it?

* Suppose that a miner receives block B(M) and starts validating it, while in parallel mining a new block B(M+1) on top of it; and happens to solve B(M+1) before the validation of B(M) is complete.  Should it broadcast B(M+1), or wait until the verification of B(M) is complete?

The devs and others have been quick to blame F2Pool, and even AntPool, for the incident.  But, depending on the answers to the above questions, other players may be to blame too.

The devs deserve a fat slice of the blame for not programming a reasonable delay (say, 2 weeks) between the "95% majority" event and the activation of the BIP66 rule.  That delay would have given a chance for the remaining v2 miners and nodes, as well as more v2 clients, to upgrade to v3.  (Using blockchain voting to trigger protocol changes also seems a terrible idea, but that is another discussion.) EDIT: Such a delay would have also reduced the risk of a fork being triggered by off-by-one bugs and network delays.

The core devs or F2Pool's own devs may also deserve another fat slice of the blame, for the v3 software allowing v3 miners and nodes to receive blocks from v2-running miners and nodes after BIP66 was activated.

BTCNuggets deserved their slice of the blame for not upgrading to v3.

EDIT: repaced some "v3 rules" by "BIP66 rules"

So that's why the price of Bitcoin has been going up this last week. Once people realize that there is this fork, the price will come down. Then people will realize that Bitcoin has stabilized, and there will be a buying frenzy again. The price will go back up for a while, until it stabilizes at some higher price.

We might be looking at Bitcoin under $100, but then in a few months, Bitcoin above $500.

Can't wait.



EDIT: If this doesn't happen, that is, if the price keeps on going up amidst this fork, and if the fork levels out and dissolves itself, then Bitcoin is here to stay.

Interesting discussion on this page actually. How is it decided that a block is "wrong"? I understand that the block is not according to specs, but well yeah, you know what I mean.

I hope this is dealt with quick. Drama doesnt look good for new users even if its not that bad in reality.

Interesting question , perhaps by requiring some kind of checksum be calculated and inserted into the next block?

I think you mean F2Pool, not p2pool. It's an easy typo to make.

I only now realized that the split happened on july the fourth. Knowing the movie indepence day i wont forget this date. And its a big thing in the US. If this somehow could have been made up to happen then i would assume now that it is part of the other forking discussion. A fork happening exactly on indepence day? Really?

The situation sort of reminds me of what happens when I'm trying to use a genetic algorithm or other heuristic-search algorithm to solve a problem, and it turns out that my reward function stated the problem slightly wrong.

The symptom is that you then get "pseudosolutions" - meaning, proposed solutions that exploit the flaw in the reward function, but which don't actually do anything useful. 

In this case we have a reward function that is supposed to pay miners for checking blocks and affirming that they are correct - but what it actually pays them for is agreeing with other miners about whether the blocks have been checked, and asserting that they are correct.  The miners evolved a pseudosolution that allows them to collect the reward without actually checking the blocks.

So how can we correct the reward function?  Is there some key the miners can't possibly know, some test they cannot pass, unless they have REALLY checked the blocks?

I agree to a point, but...
That's not the premise Bitcoin is being advertised to be built upon. The whole "protocol" rhetoric states that Bitcoin is supposed to enforce proper behavior on it's own.
We both know and agree that's not how it works in practice, yet some people, those who came up with that anti-fragile bullshit will try to spin it in a different way.

So the current premise: Bitcoin requires honest participation of the vast majority of it's participants in order to function, and that doesn't mean rational self interest but altruistic action for the good of the network.

ANTI FRAGILE MY ASS

It is not the Bitcoin Core devs' faults, rather it is the developer who wrote the pool's own software. It is the pool and their developer's faults and their fail because they were selfish and did not write their code to validate the blocks before mining on it began. This is made possible due to the open source nature of Bitcoin. The pool developers are free to write whatever software they want and as long as it conforms to the Bitcoin protocol.