9

In the Bitcoin blockchain, each block has a 32-bit field called version. Right now, it takes on simple small values like 2 or 3. As an example of changes, block version 3 introduced new rules about transaction validity, as well as anti-malleability measures. Miners with the new Bitcoin client create blocks with the version set to 3 to signal their ...


6

BIP9 "versionbits" introduced a method to deploy up to 29 softfork proposals at the same time. Each proposal follows the same flow: Graphic from BIP9 After the starttime is reached for the proposal, miners can signal readiness by setting the corresponding bit in the version field of the block header. In the past weeks we've seen signalling for two ...


6

Signalling simply means the miner of a block has set a bit in the version field to say that they support something. BIP 8 and 9 discuss this, it allows the miners to let the network know they are ready for the change or not. The version field of a block is 32 bits long, and if the top 3 bits are set to '001', 29 bits are free to be used for signalling. ...


5

Signaling will commence with the first difficulty retarget after November 15th 12am UTC (i.e. midnight between 2016-11-14 and 2016-11-15). See BIP0009 State Transitions: All blocks within a retarget period have the same state. This means that if floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed to have the same state for ...


4

Most of what you ask about doesn't have anything to do with Version Bits actually. :) Let's start from the top: nVersion is a four byte (32 bit) field in the block header. The version field was first interpreted as an integer with the genesis block introducing version 1. Later the network was softforked to create blocks of version two. From that point on ...


4

New softforks are activated using BIP 9 (versionbits), which specifies the threshold requirements. The 95% threshold is inherited from the old BIP 34 (supermajority) softfork activation method. A softfork with greater than 50% hashing power should always become the dominant chain because the upgraded miners will create a harder difficulty chain, and the non-...


3

BIP141 – Deployment says: This BIP will be deployed by "version bits" BIP9 with the name "segwit" and using bit 1. For Bitcoin mainnet, the BIP9 starttime will be midnight 15 november 2016 UTC (Epoch timestamp 1479168000) and BIP9 timeout will be midnight 15 november 2017 UTC (Epoch timestamp 1510704000). As we're currently on the second version of ...


3

As per BIP 9, the transition to FAILED takes precendence. Which means that the feature will not be activated via BIP09. The relevant part of the code. case STARTED: if (GetMedianTimePast(block.parent) >= timeout) { return FAILED; } int count = 0; walk = block; for (i = 0; i < ...


2

Bitcoin XT versions 0.11A through 0.11D supported the withdrawn BIP101, which set version = 0x20000007 as a best-guess nod toward the developing versionbits standard, while trying to maximize backward compatibility with the ways nodes might check for compatible versions. Bitcoin XT version 0.11E supports BIP109, identical to Bitcoin Classic.


2

Bit 31 is sometimes referred to as the hard fork bit. BIP34 put a constraint on version numbers to be 2 or higher. As the block version is a 32-bit signed integer, setting its highest bit results in a negative number, which would violate BIP34. As a result, any usage of that bit results in a backward incompatible change to the rules - a hard fork - that is ...


1

However Segwit is a complex upgrade to Bitcoin so there must be many places where changes are made to Bitcoin for Segwit - so how many such "if" blocks are there ? As of writing, there are 23 to 34 places where behavior changes based on whether segwit is active, depending on how you count. (e.g. if you pass a boolean to a function, and that function ...


1

The new rules are come into effect only when the softfork activates. I am not completely sure, but I think in the case of segwit transactions these would be treated as non-standard nodes and thus not accept it in their mempool. If a miner does have it in their mempool, they will not mine it into a block. Hopefully, everyone that receives it would ...


1

Blocks have a field in the block header which is the time stamp. However this time stamp is set by the miner and can really be changed to whatever they want (although there is some restriction). Can anyone elaborate on what and how is this fiddling carried out? BIP 9 has a start time and a timeout time which indicate the time period that a proposal can ...


1

The answer is pretty boring. Nobody did the work to implement it (yet).


1

I would send your solved block to a core node of your own and then check the debug.log file to see why it wasn't accepted. But, no, in general there is no necessary relationship between the version of the block and the version of transactions. Version numbers just give a signal to other nodes if there is any special way to handle new blocks/transactions. ...


Only top voted, non community-wiki answers of a minimum length are eligible