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 ...


7

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 ...


7

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. ...


7

This question is based on a misconception. Miners do not vote on proposals. Consensus changes to Bitcoin are made by the entire ecosystem transitioning to new rules that they choose, by running node software that enforces these rules. Miners are a part of that ecosystem, and their enforcing of new rules is part of what makes them safe. But if miners refuse ...


7

Early soft forks each had their own activation method included in the proposal which relied on flagdays or block version signaling. The latter only allowed a single proposal to be considered concurrently as it relied on incrementing the block version. BIP9 proposed an activation standard which allowed multiple proposals to be considered at the same time. ...


6

Should block height or MTP (median time past [...]) or a mixture of both be used in an activation mechanism like BIP 8 or BIP 9 for defining the timings of the state transitions? What are the advantages and disadvantages of both and how do they compare? The main advantage of MTP is that it usually roughly corresponds to wall time, so it's easy to ...


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

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-...


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

See my answer here to address some of your misconceptions. TL;DR: miners signal support in blocks for certain rule changes in order to coordinate activation, not to determine whether it is accepted or not. As for the actual mechanism used to signal, a number have been used in the past: Time based: BIP16, BIP30 Early softforks (up to mid 2012) used a simple ...


4

There is only a single concept of Median Time Past (MTP) in Bitcoin, the median time of a block and the 10 blocks preceding it on the same block chain. MTP has always been used in Bitcoin as part of the rules nodes use to determine whether a block has a valid nTime field in its header. Those rules are: The nTime of a block must be greater than the MTP of ...


3

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 ...


3

Your observation is correct, except that a fork is expected to be activated by a supermajority of nodes and miners in the network. The most recent soft fork had an activation threshold of 950 blocks in specific segments of 1,000 blocks signaling readiness (95% hashrate) for the new rules. So, assuming that only 5% of the mining power don't follow the new ...


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 < ...


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 ...


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

The bytes you would put in the block header would be, in order: 0x00 0x00 0x00 0x20. That's how the number 221 (= 0x20000000) is stored in 32-bit little endian encoding. Note that this is actually a large number; that range is used for BIP9-compatible versions. Older blocks that use versions 1 through 4 predate BIP9.


2

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 ...


2

Soft fork and hard fork here, if you want to accurate, are statements about the conditions under which all nodes are guaranteed to eventually agree on the same chain. So it is about avoiding permanent forks, and the conditions to avoid them. Temporary splits are always possible, even when there is no consensus change at all. A consensus rule change is called ...


1

Using block heights for the start and timeout parameters has the advantage of giving miners a known number of signaling periods. Loss of hashpower doesn't reduce the number of retarget periods available for activation. Especially for an activation mechanism over a shorter time horizon (e.g. the Speedy Trial proposal) it may be important to ensure miners ...


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).


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