1

i read the answer to this question and got some new one.

As far as i understand how a soft fork works, it means that post-softfork clients with new consensus rules accept only blocks that follow those new consensus rules, while older, pre-softfork clients accept both, pre- and post-softfork blocks. If a old client mines a block, that gets rejected by the newer clients, therefore causing a temporary blockchain fork that is resolved eventually after at least 51% of all clients are upgraded, because the clients then switch to the blockchain fork of the newer clients.

My questions are:

  1. Don't this bear the risk of invalidating all transactions still made by the old clients, but that where rejected by the newer ones? If i made a transaction that gets mined by an old client by the time the old clients still have 51% of the hashing power, but it then switches to the chain of the new ones that previously rejected this block, it disappears from the chain altogether, doesn't it?

  2. Since the blockchain don't change, a lot of old blocks that were following old consensus rules are still in there. When i'm starting a new, post-fork client and download the whole blockchain, how isn't this causing problems for the client when it tries to validate the whole blockchain with all the old blocks in it? Isn't it checking for old blocks following new rules?

Thanks for any help.

Improve this question

1 Answer 1

Reset to default
0

Your question is about deployment.

Softforking changing generally are not applied unconditionally to every block in history. Instead, an activation mechanism is used so that all clients know when they need to start being enforced. Before that activation point, new clients still enforce the old rules but not the new ones.

Activation mechanisms that have been used in the past:

  • Time-based (apply to every block whose timestamp is past a fixed point in time). Used in BIP16 and BIP30.
  • nVersion signalling (apply to every block after the first range of 1000 blocks in which at least 750 have a nVersion field that is higher than a specified value). Used in BIP34, BIP66, BIP65
  • Versionbits signalling (using signalling on individual bits of the nVersion field; see BIP9). Used in BIP141/143/144/147.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.