Pages:
Author

Topic: SPV Mining and how to slow it down ... if you care to ... - page 5. (Read 12859 times)

hero member
Activity: 636
Merit: 516
Forgive me if i'm wrong; but Antpool appears to be doing the same thing (found block, not submitting straight away,  mining on header of found block, submitting both in quick succession).. standard behaviour from them?

Blocks 387005 and 387006..
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Well Satoshi did say that in his design paper ... fees would take over from block reward ... but I guess there's a lot of people who have no idea about the design of bitcoin and the path that the design expected to take Tongue

The real issue is that so many people have their own agenda of what they want bitcoin to do.
Fortunately most of them have been unable to push those agendas ... fortunately since they all seem to be based on lining their pockets first and the advancement of bitcoin second (if at all)

Now a few relevant points from Satoshi's document for those who may not have ever read it Smiley

Quote
The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.

Quote
Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.

... and of course the last 2 sentences:
Quote
They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

The SPV mining pools clearly fail badly on that last important point.
They care not whether they work on valid or invalid blocks.
Yes that is their fault, not any one else's.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
 bullshit like spv mining and 0 blocks won't be tolerated in the long run as they don't serve the system well.  
At the very least, the system itself will sort out the zero transaction block pools as the block halving will decrease the reward from mined blocks substantially and make transaction fee mining far more important as a proportion of profit than it currently is - unless of course the consortium decide to drop transaction fees even further than they currently are (which I doubt will happen). Current block rewards are often up to 2% transaction fees and once the block halving occurs that will be up to 5%. That is a massive drop in potential profits for miners... but then miners don't necessarily have a good history of making the best choices, often choosing alleged 0% fee pools and those mining bullshit coins in the fake belief it's giving them more profit even though those same pools often underperform far more losing more profit than anything gained through what sounds profitable. OOC usually does a nice analysis of profitability proving this, yet miners go on mining in the wrong places...
legendary
Activity: 1764
Merit: 1002
hero member
Activity: 700
Merit: 501
https://bitcointalk.org/index.php?topic=905210.msg
Jorge I appreciate your willingness to have a civil conversation regarding what F2pool (and other pools) have and are continuing to do.
I believe that is and will always be the first step on the road to solving any conflicts of opinion from something as earth shattering as the Middle East conflicts, specifically Israel and Palestine, or our beloved Bitcoin Ecosystem and how things should be addressed.
Being open-minded to another's opinion and not being so immature and stubborn to believe there is only one way to make something work, or being unwilling to consider the other person may have a better way to move forward.

That is one of, if not the most important consistent behavior by macbook-air (f2pool operator.)
It is not as though he has stated this is how I am going to do things at my pool and if you don't like it mine somewhere else AND those choices only impact the miners at F2pool. His statements, threats and continued choices DO impact every single miner no matter where they mine. Effectively, his actions say if you do not like it go mine another coin, or in other words, I am powerful enough to do whatever I want regardless of what anyone thinks and as I understood and agree with cypherdoc those same choices will cause an early demise for people continuing to follow that very same abstract way of handling business.

Step away from the bitcoin code and how it is designed to influence decisions by miners and consider other social implications. They say hitler always arises at some point in any debate on the internet and I am far from comparing f2pool to being run by Hitler but it is run in a dictatorship fashion (along with antpool and BTCnuggets) whose choices impact every pool and every miner.
I see Slush and many other pool owners who will do what they can to remain neutral for the simple reason they do not want to risk a penny of income. I see Kano, CK, and eleuthria much more willing to discuss what they believe in, and in my opinion pushing for an overall better Bitcoin. Eleuthria has openly stated he feels much more open to discuss these things since the closure of the Guild. Why do we think that is? Because of the backlash he may have seen from these other, much larger pools, and I think he felt a responsibility and a need to protect his miners not that Kano and CK do not feel that same pressure, but choose to handle it a bit differently.

When CK or Kano say this is the way my pool is ran and if you do not like it go mine somewhere else. Which by the way, I have only seen Kano, CK, and Eleuthria spend considerable hours and hours patiently explaining many of the same items to miners over and over regardless if they mine at their pool or not. IT is very rare any of those three have said this is the way it is if you don't like it F off.
The scenarios where it could even be construed in that manner have outcomes which do not impact the network. They are their pool, their miners.
 
I think you must agree there is a much higher standard set by the aforementioned gentlemen to educate the individual miner AND do what they think is right to empower the bitcoin network as a whole. Their attitudes and choices do not cause harm and they are always willing to have a dialog. I do not agree with Kano or CK regarding every choice they make and every rule they have in place at their respective pools but they are my number one choice for where my hashpower has been since I began mining.

Their is a social aspect of mining and bitcoin in general which is not controlled by code. Simply, it is the act of good and bad, the intentions of creating a pool structure which promotes a healthy network even when costing them in other ways.

I followed the fork earlier this year with great intensity as I try to do with everything impacting all of us. I feel I have the right to form an opinion based on what I learn, and not only how I am treated, but more importantly how my peers are treated and how the choices made by pool operators who have the ability to use all of our hashing power to make decisions. I am certainly open-minded enough to admit when I am wrong, and even if I think I am right I want to hear what the other person has to say.
I am confident you have seen the quotes from macbook-air stating they were never wrong for SPV mining, the fork happened, and their involvement meant nothing, and other than making a code change so that particular style of fork would not happen they have no intention of changing.

Setting aside the threats and other obvious character flaws they have a mindset that they will do whatever they want in concert with the other two pools not to contribute to OUR network, but control it, and dammed be anyone who even offers an opinion on their choices. To my knowledge Bitmain (Antpool) and BTCnuggets have not made public statements to that effect regardless of their actions speaking loudly. This shows they are better at handling PR and do not provide an opportunity for the people who disagree to quote their statements. In so, they are smarter at handling the situation and are not ruled by emotion. Obviously the long-term health of the network is not priority one for those two, and they are not vocally touting the fact that collectively they can cause a massive problem at any time. This is why macbook-air is seeing the brunt of the replies. The greed and control has been vocalized as priority one.

I believe you will find  this social aspect or better yet, the court of public opinion can have a significant impact on these pools in the coming months and years. The court of public opinion has destroyed the reputations of companies, and sometimes those companies are so big they can withstand that assault and with changes can maintain and even grow beyond those terrible choices.

Personally I think mining zero transaction blocks and SPV mining are just as if not more important than the block size debate but referencing that particular debate look at how those pools control the blocksize. If they do not want the blocksize to increase, it will not happen.
You must consider the ramifications of the centralization aspect, AND the fact that what isn't good for these pools regardless of why they do not consider it to be good, just the fact that if something is not considered to be beneficial to them, it is unacceptable.
The bitcoin network is already controlled by the coercion of these pools. Set aside the reasons why they have such control and ask can this be good for anyone but them? Do you see them wanting to help all of us involved in bitcoin?

We can debate the validity of SPV mining and while I still do not agree I certainly consider the points you have made.

MY biggest point is we have empowered, or better yet, given up a scenario of controlled by code to people like macbook-air who control by threats, are running in a manner exactly the way a third world country dictator would do, and have openly stated there is no intention of doing anything other than more of the same.

So while the specifics of SPV mining and consistent zero transaction blocks are debatable, there is no debate regarding their intentions or motivation of domination through the same continued practices. They do not care if the network is healthy as long as they are controlling it, continuing to make the most profits imaginable, continuing to march towards total control, and be damned anyone or anything which counters such.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
v4 switch coming in the next few days - fun times ahead Smiley
(antpool, the one holding back the v4 change, has now put out their first v4 block)
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Meh, I wake up to this crap ...

...
tldr; quoting others without you even understanding it ...
...

Here go read this ... in this thread ... that will tell you how it works.
https://bitcointalksearch.org/topic/m.13151453

Seriously, I know exactly how it works down to the little itty bitty lines of code how to do it ...
That's why I posted those quotes of mine, so people could get a reasonable grasp of it in terms of what it does
... and you seem to have clearly missed a very big issue by not reading my 2nd quote of myself there.

Yeah I created the thread, yeah I know what is going on AND how it works, read a little of my posts.

I am still trying to understand what actually happened.
...
Clearly you still don't Tongue

Do you actually have any idea at all what the block change times are of pools and how they compare?
Obviously not.

As someone has already told you, and you ignored, there is one pool that does full validation block changes faster than all the empty block change pools and faster than some of the SPV empty block change pools.
(Even my pool does full verified block changes faster than the empty block change pools most of the time)

Now when we get down to these numbers, we are talking 100s of milliseconds difference in the fast pools.

Wow isn't that a great idea? Risking network forks, transaction confusion on the whole network, lost blocks, people spouting ignorance about bitcoin from the likes of ... arm chair experts like you, all for a few hundred milliseconds speed difference in a 600s block time ...

... and as I have already stated, the SPV miners also have the peer 2 peer network advantage of being in a part of the network with the majority of the network hash rate

... and produce a high % of network blocks (some over 20%) and thus for those blocks will have that obvious advantage also

I'll soon be switching my pool over to solo's very fast (faster than my current already very fast) block change time with hardware performance well above the solo pool ... that will be interesting to see the results there ...

Yeah you can quote other people over and over again, but you need to first understand it and then see what really happens in practice, not stroke your beard and theorise (incorrectly) about how you hope it might be ...

...
Quote
The lead into v3 also started long before that.
https://github.com/bitcoin/bitcoin/releases/tag/v0.10.0 Released 13-Feb ...

Wait, you are not saying that there was plenty of time for 100% of the nodes to be among the first 95% to upgrade, are you?  Wink
Yeah funny the maths there hey ... it's not 95% ... think about it, stop just regurgitating what someone else has told you.
Upgrades happen ... before you find a block ...
You can even determine an 'expected' upgrade time for each pool being the point in the middle of their switch from v2->v3 blocks ... or the average time they take to find a block before their first v3 block ... or ... pick another way ... but of course it will always be BEFORE their first v3 block
sr. member
Activity: 278
Merit: 254
But you can blame [F2pool] for:
- threatening other pools
- "mining" while withholding
- lying

And so on.

No contest about DoS threats.  But that point is not related to bitcoin. DoS is a violation of general *laws* that govern use of the *internet* -- so it can be objectively said to be wrong, and the victims have the right to seek appropriate legal action.

"Mining" while withholding (whatever that means) is fair game.  Once again, bitcoin cannot depend on miners being pressured to act "failrly" in any sense.  The design *assumes*  that they will do whatever is best for them; an that is what is notable about it.  The protocol does not even assume that they are holding their bitcoins, or that they care about what will happen to the price after their current equipment becomes junk.

Ditto for lying (*).  While no one likes liars, there is no law against lying per se, and -- once more -- bitcoin cannot depend on miners being honest.  Indeed, it assumes that miners will tell lies, if that helps their bottom line.

(*) What "lies" are you referring to? The fact that they put "v3" on their headers? That was not a lie.  Something else?

POW blockchains are stable and behave as advertised only if a (super) majority of mining nodes follow the rules.  This technology does not and can not magically do the right thing if too many operators are dishonest and/or stupid. It is not fair game to cheat just because you can get away with it for a short while.  Bitcoin is a social experiment as much as it is a computer science project. 

Understanding the economic and social aspects of bitcoin requires skin in the game and is not something that can be done as an academic exercise.



hero member
Activity: 910
Merit: 1003
So would you mind and tell us which other pools you connected to for "reducing their orphans"? If you post this, we can check their orphan rate - otherwise, I call this BS.

When F2Pool "steals" the hash of B(N) from Kano in advance of the ful B(N), it can start mining an empty block B(N+1) on top of it, right away.  The head start gives F2Pool a greater chance to solve B(N+1), which protects B(N) against orphaning.

If Kano did not let F2pool get the hash of his B(N) in advance, some other miner might succeed in sending an alternative B1(N) to F2pool before Kano sends the full B(N). Then F2Pool would mine his B(N+1) on top or B1(N), rather than B(N); and so B(N) would run an increased risk of being orphaned by B1(N).

Therfore, it is in the interest of both pools to ensure that F2pool (and all other major pools) gets the hash as quicky as possible, and starts mining an empty block on top of it, without waiting to get the full B(N). 

It is in the interest of F2pool (but not of Kano) to download the full B(N) and replace his empty B(N+1) by a full one -- but only because of the tx fees.  If F2pool fails to do that, it is actually slightly better for all the other miners, because they will have a chance to get the tx fees that F2pool failed to get.
hero member
Activity: 910
Merit: 1003
But you can blame [F2pool] for:
- threatening other pools
- "mining" while withholding
- lying

And so on.

No contest about DoS threats.  But that point is not related to bitcoin. DoS is a violation of general *laws* that govern use of the *internet* -- so it can be objectively said to be wrong, and the victims have the right to seek appropriate legal action.

"Mining" while withholding (whatever that means) is fair game.  Once again, bitcoin cannot depend on miners being pressured to act "failrly" in any sense.  The design *assumes*  that they will do whatever is best for them; an that is what is notable about it.  The protocol does not even assume that they are holding their bitcoins, or that they care about what will happen to the price after their current equipment becomes junk.

Ditto for lying (*).  While no one likes liars, there is no law against lying per se, and -- once more -- bitcoin cannot depend on miners being honest.  Indeed, it assumes that miners will tell lies, if that helps their bottom line.

(*) What "lies" are you referring to? The fact that they put "v3" on their headers? That was not a lie.  Something else?
legendary
Activity: 1764
Merit: 1002
kano hits on it well.  f2pool doesn't understand or subscribe to the original ethos of Bitcoin like many of us earlier adopters do.

they look to be in it for the short run.  make bank now and long term be damned.  i think it's pretty clear what the rest of us have to do to counter this attitude.
sr. member
Activity: 278
Merit: 254

my bet is that if you continue down this strategy path, your pool will become deprecated despite any threats or machinations on your part.

Yes, or worse...   I note that the largest pools are still offering PPS payouts.
legendary
Activity: 1764
Merit: 1002
You cannot blame them for that decision.

But you can blame them for:
- threatening other pools
- "mining" while withholding
- lying

And so on. While you are playing an academic game - which I sometimes really enjoy - we are here in a situation where a pool operator shows the behavior of a bully - to say it in a friendly manner.

We were not mining and withholding. We just connect to their server and receive what they send me. What they get is just 4 more long-live connections. And what they gain is huge reduce of orphans. This guy does not thank me, instead blame me. The thread is completely pointless.

you are missing the point.

by spv mining, you're not processing tx's which exacerbates an already backed up mempool in stress test situations.  that causes all sorts of user/merchant based pain in terms of 0 confs.  you are being extremely short sighted b/c in the long run your income depends on tx growth and the resultant fees earned from them.  spv mining degrades confidence in the network of miners and discourages usage esp by new comers who suffer from long wait times.  it also encourages further perversion of Bitcoin by encouraging compensations like RBF which will destroy 0 conf tx's, which work perfectly well today.

my bet is that if you continue down this strategy path, your pool will become deprecated despite any threats or machinations on your part.
legendary
Activity: 2338
Merit: 1124


We were not mining and withholding. We just connect to their server and receive what they send me. What they get is just 4 more long-live connections. And what they gain is huge reduce of orphans. This guy does not thank me, instead blame me. The thread is completely pointless.

So would you mind and tell us which other pools you connected to for "reducing their orphans"? If you post this, we can check their orphan rate - otherwise, I call this BS.
sr. member
Activity: 266
Merit: 250
The thread is completely pointless.

Thanks to this thread, the mining community now knows that if your pool get's dos'd you will redirect your domain at a different pool, thus dos'ing that pool.

Hardly a pointless thread, is it?
sr. member
Activity: 324
Merit: 260
You cannot blame them for that decision.

But you can blame them for:
- threatening other pools
- "mining" while withholding
- lying

And so on. While you are playing an academic game - which I sometimes really enjoy - we are here in a situation where a pool operator shows the behavior of a bully - to say it in a friendly manner.

We were not mining and withholding. We just connect to their server and receive what they send me. What they get is just 4 more long-live connections. And what they gain is huge reduce of orphans. This guy does not thank me, instead blame me. The thread is completely pointless.
legendary
Activity: 2338
Merit: 1124
You cannot blame them for that decision.

But you can blame them for:
- threatening other pools
- "mining" while withholding
- lying

And so on. While you are playing an academic game - which I sometimes really enjoy - we are here in a situation where a pool operator shows the behavior of a bully - to say it in a friendly manner.
hero member
Activity: 910
Merit: 1003
Sigh, it is a majority that are SPV mining ... do you even understand at all what that means?

A majority of the network is happy to risk mining on invalid data.

Even Greg, who coined the term "SPV mining", admitted that it was a bad name.  There are three things that go by that name:

  • (A) The miner starts to mine an empty block B(N+1) as soon as it gets hold of the hash of B(N), before it has got the full B(N); and publishes that empty B(N+1) if he solves it before getting the full B(N).
  • (A2) The miner does (A) even when he notices that B(N) was itself empty, because the other miner was doing (A) too.
  • (B) The miner does not bother to dowload and check the full B(N) at all, once it got its hash.

Miners will do (A) and (A2) if they can, because the alternative is to let their equipment sit idle or turned off in the interval between receiving the hash of B(N) and the full B(N).  If that turns out to be bad for bitcoin, that is a flaw of the protocol; the miner is not to blame, because he was supposed to be greedy and do what is best for him.

(The protocol could be changed to prevent (A) and force the miners to wait for the full B(N); but then the useful hashpower would be less than the installed hashpower, so it is not clear that it would be better for the coin.)  

Item (A) is not an entirely bad thing, because the empty B(N+1) will still help secure B(N) against tampering.  The miner who mined B(N) *wants* to give its hash to all other miners, as quickly as possible, and *wants* them to do (A), because it helps secure his gain against orphaning.  Every miner *wants* to get the hash of other miners' blocks as soon as possible, and do (A).  

Item (A) is usually pretty safe for bitcoin, as well as for the miner of B(N+1), if he knows that the solver of B(N) is a known real pool: because that pool will lose lots of money and reputation if he sends a bogus hash out to its members.  Choosing to do (A) is a calculated risk by the miner, with a clearly positive expected payoff.  Last July (and in no other occasion that I know of) item (A) failed by magnifying the mistake of BTCNuggets from 1 block to 6 blocks, thus causing monetary loss to F2Pool and AntPool in addition to the loss suffered by BTCNugets.

Perhaps pools will modify their implementation of item (A) now that they know that the probability of other miners issuing invalid blocks is not negligible.  In hindsight, the Fork of July could have been just one or two v2 orphans, rather than a 6-block chain, if the miners had refrained from doing (A) or just (A2), for a couple of weeks around the BIP66 switch-on event; that would have avoided the loss incurred by F2Pool and Antpool (but not the loss of BTCNuggets).

As for item (B), it should not be in the miner's interest to do that, so there should be no need to nag those who do it.  But the expected loss from doing (B) is basically the transaction fees, so it is a weak deterrent.  That is a fault of the protocol and of whoever set the minimum fee so low -- not of the miners.

However, I recall that F2Pool admitted to be doing (B) in July.  They claimed that they had decided to do (B) after having one of their blocks orphaned.  I do not quite understand that excuse; but, anyway, they promised to stop doing (B).  But they also said that they would continue doing (A), for the reason above.  You cannot blame them for that decision.

Quote
The SPV miners were already submitting v3 blocks before hand.
They knew about BIP66 coz they had already upgraded for it.
What they didn't do with their SPV mining was ... ... ... ... check the block version number since they didn't care to do that.
That involved more than they already did.

Failing to check the version number of B(N) was F2Pool's mistake, but that did not happen because they were doing (A).  They easily could (and should) have checked the version when doing (A).  They did not bother to check it because they did not foresee the risk of other pools continuing to mine v2 blocks past the fork.  

That check would not have prevented Antpool from extending the wrong branch, because they mined on top of a v3 block header.  

Quote
... as for your 5% number, no that's wrong also.
It only means that in the previous 1000 blocks (~1week) there were 5% v2 blocks.
The actual number mining v2 blocks at the time of the change to v3 is lower than 5%
It's not a flat line of no more adoption for that entire week/1000 blocks ...

Maybe not 5%, but the percentage of v2 miners was high enough for a v2 block to be issued just after the fork.

Why is everybody blaming F2pool for mining an empty block on top of that one, and no one is blaming BTCNuggets (and the other miner who did the same 20 hours later) for having produced that block in the first place?

Quote
The lead into v3 also started long before that.
https://github.com/bitcoin/bitcoin/releases/tag/v0.10.0 Released 13-Feb ...

Wait, you are not saying that there was plenty of time for 100% of the nodes to be among the first 95% to upgrade, are you?  Wink
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Sigh, it is a majority that are SPV mining ... do you even understand at all what that means?

A majority of the network is happy to risk mining on invalid data.
Then what happens? They continue doing it coz they have the majority and the 'invalid' fork they are mining keeps growing faster.

Guess what actually happened?
The v2 fork was growing faster than the v3 fork.
I contacted Bitmain and told them what was going on and they contacted their "pool technicians" and then switched over from the v2 fork some time after that.
Of course, they didn't actually fix it coz it happened again about 20 hours later ...

--

Secondly, seriously go look at the block chain.
The SPV miners were already submitting v3 blocks before hand.

They knew about BIP66 coz they had already upgraded for it.

What they didn't do with their SPV mining was ... ... ... ... check the block version number since they didn't care to do that.
That involved more than they already did.
Guess what, it's prolly gonna happen again shortly with v4 blocks ...
As simple as that. They didn't care.

--

... as for your 5% number, no that's wrong also.
It only means that in the previous 1000 blocks (~1week) there were 5% v2 blocks.
The actual number mining v2 blocks at the time of the change to v3 is lower than 5%
It's not a flat line of no more adoption for that entire week/1000 blocks ...

The lead into v3 also started long before that.
https://github.com/bitcoin/bitcoin/releases/tag/v0.10.0 Released 13-Feb ...
hero member
Activity: 910
Merit: 1003
Bitcoin has "good citizen" rules.
Sorry if you felt that you'd found some magical anarchist utopia without rules, you're wrong.

Sorry, but you got it wrong.  

Quote
Those rules are reasonably well known - and bitcoin core is an example of where to find them - you should try learning about them one day.

e.g. I can't go mine a zillion, 1,000 difficulty blocks and get 10's of thousands of BTC a day with a 1THs miner.
Damn that's not what you thought is it? Yet that would be more profitable if I did that wouldn't it?

Also, of course, there's the block header requirements, like versions and hash values based on previous blocks and merkle tree hashes of transactions.

... and for those transactions ...
Yep, again, wouldn't it be more profitable to make a transaction that created 1,000 BTC and sent it to my address any time I wanted to?

So yeah, anyone can do those things, but then they are no longer mining Bitcoins and (most? Tongue) Bitcoin exchanges wont accept their scam-coins

And that is the point: miners should avoid those things because they are bad for them, not because they are bad for bitcoin.  

That is why it took 20 years to invent bitcoin.  If one could assume that the players would be good citizens who followed the rules, either to go to heaven or because of community pressure, bitcoin would have been invented 25 years ago.  If a misbehaving miner is hurting bitcoin, that is a flaw of bitcoin -- because its essential property, that made it the solution to the distributed ledger problem, is that it does not depend on miners being "good", only on a majority of them being "greedy".

Quote
Quote
I insist, [ the Fork of July ] was not [ the SPV miners' ] fault, but the fault of the devs who programmed BIP66 to be enabled immediately when 95% of the miners had updated, with no grace period -- thus ensuring that 5% of the hashpower would still be using the wrong rules at the fork time, no matter how quickly they tried to update.  

That 5% of the hashpower would have been wasted anyway, even if the SPV miners had not mined empty blocks on top of that bad one.

With Bitcoin, it has been done via a trigger in the core code that makes the change effective when the requirements exceed 95% of blocks mined over a given history of blocks. That's how it was done for the v3 change. The grace period was the whole period leading up to that 95% acceptance.

A longer grace period would have made no difference to their SPV code.
Their code didn't bother to even check the block version number, so whenever in the future, after the v3 change over, if someone mined a v2 block and sent it to the SPV pools, they could have accepted it and forked the network. Yes it was their fault. Yes, they had updated bitcoin daemons. No their SPV code was wrong.

You missed the point completely.  Miners were upgrading their code from v2 to v3.  Since the BIP66 change was programmed to be enabled immediately once 95% of was running v3, at that moment inevitably there would be 5% of the miners still running v2.  

A grace period of (say) 2 weeks after reaching the voting threshold would have allowed warnings to be sent out, and then those remaining 5% would have convert too -- because otherwise they would be wasting their work.  But the devs opted for zero grace period and zero warnings, thus ensuring that some miners -- those who were last to upgrade -- would issue invalid blocks and waste their work.  

Specifically, the 6-block bad branch started when BTCNuggets mined the v2 block after the forking block: not by their choice, not because F2Pool was SPV mining, but because the devs bungled it (and did not even apologize).

(Please don't tell me that the miners should have updated more promptly, so that 100% of them should have been among the first 95% to upgrade.)
Pages:
Jump to: