Topic: Blockchain split of 4 July 2015 - page 16. (Read 45630 times)

This forum is still one of the best places for getting fast heads up on stuff like this! Also good that they highlight it at the top of the forums.

Woah, glad I checked in the forums this morning.  Thanks so much for the heads up!

Here is some more info on BIP66 from a mailing list that I found useful:

http://sourceforge.net/p/bitcoin/mailman/message/34199290/

Slush isn't listed as one of the "trusted" pools. Why?

You're right. I won't use anything but an SPV for everyday use. Soon there will come a time when I won't download the full block chain anymore (that time is almost here). I turn on my desktop computer maybe every few days and use it for a couple of hours. My desktop hasn't caught up with the current block in the last two or three times I've turned it on because I wasn't on it long enough. iPads and phones are making my desktop obsolete. I haven't used anything other than a phone to access this forum in over a year.

Major thanks was once given to those coding, it may seem today (5+ years on) with all the uncertainty this work has become a thankless endeavor.

Lets not forget the principles of what bitcoin is.

Here's some more info I found for people interested in what has happened and may happen again.
Block Versions

    Version 1 was introduced in the genesis block (January 2009).

    Version 2 was introduced in Bitcoin Core 0.7.0 (September 2012) as a soft fork. As described in BIP34, valid version 2 blocks require a block height parameter in the coinbase. Also described in BIP34 are rules for rejecting certain blocks; based on those rules, Bitcoin Core 0.7.0 and later versions began to reject version 2 blocks without the block height in coinbase at block height 224,412 (March 2013) and began to reject new version 1 blocks three weeks later at block height 227,930.

    We are here at Version 3 blocks will be introduced when sufficient numbers of miners switch to using Bitcoin Core 0.10.0 and other versions that create version 3 blocks. As described in draft BIP66, this soft fork change requires strict DER encoding for all ECDSA signatures used in transactions appearing in version 3 or later blocks. Transactions that do not use strict DER encoding have been non-standard since Bitcoin Core 0.8.0.

    Version 4 blocks will likely be introduced in the near-future as specified in draft BIP62. Possible changes include:

        Reject version 4 blocks that include any version 2 transactions that don’t adhere to any of the version 2 transaction rules. These rules are not yet described in this documentation; see BIP62 for details.

        A soft fork rollout of version 4 blocks identical to the rollout used for version 3 blocks (described briefly in BIP62 and in more detail in BIP34).

https://bitcoin.org/en/developer-reference#block-headers
Make sure to stay up to date and if mining make sure your mining pool stays up to date.
For what i read this effects you if could get invalid transactions that look "real" because they were considered "real" by "outdated" software. (wallets not update with latest QT) This could be bad in a business transaction say you sent someone money and they said it was invalid bad situation.

If your mining you could loss a great portion of blocks which were mined if your pool is on the wrong side or mining the wrong version. Meaning your blocks mined could be nullified. It helps if you have an up-to-date qt wallet to know if those are the blocks from the wrong version but you still loose those blocks meaning pressure your pool to upgrade or switch to one that did.

Thank you forrestv for keeping an eye out for P2Pool and continuing to support development

Well that wasn't something I expected to wake up, and read.  Looks like it is mostly fixed at this point, and hopefully can be prevented in the future?

I don't agree.  SPV is fine for everyday and small transactions.
Plus you can verify large received transactions on several places if you dont
have a full node.

Problem solved: switch to a smaller but more dedicated dev's pool (kano, slush, etc) and don't give crap about variance.

Plus the bandwidth consumed everyday in staying updated. Not everybody is sitting on a 'no-limits' connection.

Cool, i almost had a heart attack as I came really relax after a workout and swimming in the pool. This sounded pretty fucking catastrophic. Glad im paranoid and never went outside Bitcoin QT and always keep it updated. It shows how you can't trust anything that doesn't download the entire blockchain locally. This is a huge problem since in the future maybe it will be impossible for a lot of people to deal with huge ass blockchains. It's also impractical for mass adoption, most people will not deal with full nodes like us nerds do.

I don't think you understand....
For some people it will take weeks or worst case a month+ to download the QT...

Chinese are famous with their skils

What kind of resource are you talkin about? The only thing you need really is disc space (for now blockchain info is about 42GB big) every stationary PC or laptop is capable of storing more.
It is not resources we lack, it is that people are lazy is the problem.

A very serious event for sure - but seems to have been mostly fixed already.

It shows, that relying on SPV wallets is not a good idea at all. Only full nodes offer full security. That's why excessive increases in blocksize are dangerous: The number of full nodes will decline further, because the average user doesn't have the resources to run them. In turn, the system as a whole will become less secure and more vulnerable to events like this.

ya.ya.yo!

Yes, all wallets are working but you should wait longer if you are not using Bitcoin Core 0.9.5 or above

I believe blockchain.info wallet is vulnerable

All users on any wallet can send and receive Tx just fine. The Tx were being picked up on both chains. The risk and reason you would need to wait 30 confirmations had to deal with someone attempting to create a double spend attack where you are using a wallet on 0.9.4 and before that is vulnerable and possibly may be on the wrong chain.

In other words :
Someone pays you 100 dollars to your SPV wallet which is connected to a node on 0.9.4 or before. That node just so happens to be on the wrong chain. You start to receive confirmations coming in and assume the transaction is good. The attacker is aware of the forked chain and respends the same BTC on the other chain. When your node makes the correction and jumps on the correct chain it invalidates your BTC that was previously confirmed on the wrong chain.

Changing the headers does not actually do anything except show that the miners are voting "yes".

The miners should have started to implement the new rules of the soft fork as soon as they showed the new headers, however some were not doing this, and voted yes but did not implement the new rules