Topic: Blockchain split of 4 July 2015 - page 9. (Read 45589 times)

I have a hard time believing that F2pool and AntPool did this by accident.

However I also cant see their profit motive in this case since everyone knew what was happening.

It seems they just wasted time/money on the wrong chain with no benefit.

What am I missing?

Yes,like you said its forward then back to my account again

Try their support first, when you encounter a problem.
I think, most services you sent Bitcoin to, don't keep it in the address you sent it do, but forward it to another address where they accumulate all inputs.
But I seriously have never checked, if that is really true. Looking at the blockchain is not an easy way to get any information. You should just do that, as a last resort.

I just received my bitcoin on yobit,seem its delayed for hours now is fine

I am using google 2fact for android this is my btc address https://blockchain.info/address/14s5Fnf2twWsDaDvskkrBFqorrnSub7JSn
You can see there are a withdrawal at 18:48:30,i dont know why my bitcoin will sent to there

2fact with email or phone? because it looks more and more like a steal and not a related issue of the blockchain split, that will not cause such a thing btw

but i'm curious can you post the address?

I have 2fact on my account,i dont know who belongs that btc withdrawal address,its happen automatically i eve check on my account history its not recorded for deposit nor withdrawal just like its happened on blockchain

that btc address to who belongs, it is your? because it sounds like your account there is hacked(your pc is infected maybe) or something, and this has nothing to do with the blockchain split

I sent btc to yobit but its weird that my btc did not show up on account instead auto withdrawal to another btc address,i never encounter such thing before,does this blockchain problem or what i dont know,i only know i lost my bitcoin

I agree with this partly. While bc.i has been providing an invaluable service, they seem to be having a lot of bugs lately.
However, its not their fault if people start conflating bitcoin with bc.i.

BTW, from what I gleaned from their error messages over the months, they are using (possibly modded) bitcoinj. In SPV mode this also would not validate BIP66.

On a different note, here's one proposed solution for SPV nodes that does not require us to wait for 30 confirmations. Please comment on its correctness.

Let us assume that an "invalid chain" cannot be more than 50 blocks.

Step 1. We boot our SPV node "now", several days after the July 4 fork.
Step 2. We receive the mth block, say b_m. We ensure that b_m is version 3 block.
Step 3. We need to ensure that at least 50 previous blocks before b_m were also correct. We download those blocks (not just the headers).
  That is blocks b_{m-50}, b_{m-49}... b_{m-1}. Then we ensure that all were version 3, have correct signatures, etc, and correctly validate the next block (via the prevBlockHash).
Step 4. We can start counting b_m as a block of a valid chain if above checks pass.
Step 5. For any further received blocks, we follow steps 2, 4, 5 (skipping steps 1 and 3), since we have already validated 50 blocks before the "boot" block. Hence we validating only with block b_{m-1} is sufficient.

You mean: after you sell some of your bitcoins for dollars through BitPay, and buy some stuff on overstock.com using those dollars. 

Well, maybe you're correct that a solid hashrate to defend against 51% attacks is just an urban legend.  Or maybe it also has to do with the idea that having a massive hashrate means massive interest in using a given coin.   I'll be sure to double-check that with the devs of the 1001 altcoins that have gone down the tubes over the past year for not having a single miner.

With respect to security, though, there's this:


So, I dunno, you're probably right bitcoin's usefullness and popularity are also just "urban legends".  But I'll have to double check that tomorrow after I buy some stuff for my house on overstock.com using bitcoin.

i m using btc e so here ill be same as this post?

Thanks @Cryddit for the replies! You write:


Well, it is debatable whether it can be called "wrong".  It is more risky for the miner, and not what the bitcoin devs think that the miner should do, and not as helpful to the system as the others would think.  But miners have no obligation to behave in any particular way.  Each miner has the right to run whatever software he wants and output any blocks he wants.  The economic incentives are supposed to lead him, through self-interest, to behave in a way that is best for the system.  If the incentives are right but the miner doesn't act in his best interests, it is his problem, not anyone else's.  But if the incentives actually encourage a behavior that is bad for the system, it is a flaw of the protocol.

When they opted for "SPV mining", it was because they thought it would increase their revenue. In this case it didn't, but maybe it paid off overall.  Perhaps they overreacted to that incident that made them disable the verification code (when they lost ~6000 USD in an orphaned block because of a few seconds of delay); or perhaps "SPV mining" indeed saved them from several other incidents. 

Anyway, it should be their problem to figure that out and do what they think is best for them.  Their losses in that chain should not be of concert to anyone... except that there were many v2 nodes and clients out there that got confused because, by their criteria, the 'bad' chain was fully valid and was the longest chain. 

So, I insist that the devs deserve a fat slice of the blame: for not having a delay after the "95% majority" event, and because they choose to do a riskier manoeuver (allow v3 nodes and miners interact with v2 clients) for PR reasons (to keep clients unaware of the change, and let them run the v2 version even after it went into effect).

Thanks @knightdk again for the reply. You write:


In understand that clients don't need to update if a soft fork only makes the rules for blocks more restrictive.  However, if it makes the rules for transactions more restrictive too, then the clients must update anyway, otherwise their transactions will be rejected (except by nodes and miners who are still running the old version, which may cause those transactions to be confirmed and then unconfirmed).  isn't that so? Isn't that the case of BIP66?


Indeed, I see the quote in other posts.

No matter how big the army, it cannot defend the country from an internal war.

The problem is solved now?

It appears that F2Pool did, but had it disabled when the fork happened due to a bug from losing an orphan race a few months ago. It seems that they implemented a fix for that bug, but the code is not refined yet.

Source:

This is what I'm wondering too. The client probably isn't optimised for mining, but surely with custom software it would be possible to save state when a block is received from a peer, then immediately begin work on the new block. At the same time, verify the block that has just been received; if it turns out to be invalid, restore state and continue work on the "old" block.

This way you still get the speed advantage, but with the added safety of consistency checks.

To clarify: All the transactions in the BTCNuggets block, EXCEPT for the coinbase, which was an invalid transaction, were later included and confirmed in the valid chain.  The other blocks in this fork did not contain any valid transactions; only their coinbases, which were invalid.