BIP proposal: Increase block size limit to 2 megabytes

This has been reviewed by merchants, miners and exchanges for a couple of weeks, and has been implemented and tested as part of the Bitcoin Classic and Bitcoin XT implementations.

Constructive feedback welcome; argument about whether or not it is a good idea to roll out a hard fork now will be unproductive, so I vote we don't go there.

Draft BIP:

  Increase block size limit to 2,000,000 bytes.
  After 75% hashpower support then 28-day grace period.
  With accurate sigop counting, but existing sigop limit (20,000)
  And a new, high limit on signature hashing

Blog post walking through the code:

Blog post on a couple of the constants chosen:

Gavin Andresen

bitcoin-dev mailing list
bitcoin-dev <at>
jl2012 via bitcoin-dev | 5 Feb 19:40 2016

BIP draft: Hard fork opt-in mechanism for SPV nodes

BIP draft: Hard fork opt-in mechanism for SPV nodes: This is a supplement, instead of a replacement, of the hardfork bit BIP: They solves different problems:

The hardfork bit tells full and SPV that a planned hardfork (instead of a softfork) has happened.

This BIP makes sure SPV nodes won't lose any money in a hardfork, even if they do not check the hardfork bit.
--------------------- BIP: ? Title: Hard fork opt-in mechanism for SPV nodes Author: Johnson Lau <jl2012 <at>> Status: Draft Type: Standard Track Created: 2016-02-05



This document specifies a new algorithm for the transaction commitment in block header, to ensure that SPV nodes will not automatically follow a planned hard fork without explicit opt-in consent.


A hard fork in Bitcoin is a consensus rule change where previously invalid blocks become valid. For the operators of fully validating nodes, migration to the new fork requires conscious actions. However, this may not be true for SPV node, as many consensus rules are transparent to them. SPV nodes may follow the chain with most proof-of-work, even if the operators do not agree with the economical or ideological properties of the chain.

By specifying a new algorithm for the transaction commitment in block header, migration to the new fork requires explicit opt-in consent for SPV nodes. It is expected that this proposal will be implemented with other backward-incompatible consensus rule changes at the same time.


The calculation of Merkle root remains unchanged. Instead of directly committing the Merkle root to the header, we commit




where zero is 0x0000....0000 with 32 bytes.


Since the header structure is not changed, non-upgraded SPV nodes will still be able to verify the proof-of-work of the new chain, and they will follow the new chain if it has most proof-of-work. However, they will not be able to the accept any incoming transactions on the new chain since they cannot verify them with the new commitment format. At the same time, SPV nodes will not accept any new transactions on the old chain, as they find it has less proof-of-work. Effectively, SPV nodes stop accepting any transactions, until their operators take further actions.

Zero-padding is applied before and after the merkle_root, so it is not possible to circumvent the rule change with any current implementations, even for faulty ones.

A future hard fork should change the padding value to stop non-upgraded SPV nodes from processing new transactions.

Hard forks may sometimes be totally uncontroversial and make barely noticeable change (BIP50, for example). In such cases, changing the padding value may not be needed as it may cause unnecessary disruption. The risk and benefit should be evaluated case-by-case.


As a mechanism to indicate hard fork deployment, this BIP breaks backward compatibility intentionally. However, without further changes in the block header format, non-upgraded full nodes and SPV nodes could still verify the proof-of-work of upgraded blocks.

Interaction with fraud proof system A fraud proof system is full nodes that will generate compact proofs to testify invalid blocks on the blockchain, verifiable by SPV nodes. Hard forks without any malicious intention may also be considered as a “fraud” among non-upgraded nodes. This may not be desirable, as the SPV node may accept devalued tokens on the old chain with less proof-of-work. With this BIP, non-upgraded SPV nodes will always believe the new chain is valid (since they cannot verify any fraud proof), while cannot be defrauded as they will not see any incoming transactions.


This document is placed in the public domain.

bitcoin-dev mailing list
bitcoin-dev <at>

Bitcoin Core 0.12.0 release candidate 3 available

Binaries for bitcoin Core version 0.12.0rc3 are available from:

Source code can be found on github under the signed tag

This is a release candidate for a new major version release, bringing new
features, bug fixes, as well as other improvements.

Preliminary release notes for the release can be found here:

Release candidates are test versions for releases. When no critical problems
are found, this release candidate will be tagged as 0.12.0.

Diff since rc2:
#7440 `c76bfff` Rename permitrbf to mempoolreplacement and provide minimal string-list forward compatibility
#7415 `cb83beb` net: Hardcoded seeds update January 2016
#7438 `e2d9a58` Do not absolutely protect local peers; decide group ties based on time
#7439 `86755bc` Add whitelistforcerelay to control forced relaying. [#7099 redux]
#7424 `aa26ee0` Add security/export checks to gitian and fix current failures
#7384 `294f432` [qt] Peertable: Increase SUBVERSION_COLUMN_WIDTH

Also, a new certificate was used to sign the Windows installer, which should solve
Win7 compatibility issues.

Thanks to the gitian builders for keeping up so quickly, thanks
to them there are executables so quickly after tagging.

Please report bugs using the issue tracker at github:

jl2012 via bitcoin-dev | 4 Feb 18:14 2016

Hardfork bit BIP


This document specifies a proposed change to the semantics of the sign bit of the “version” field in Bitcoin block headers, as a mechanism to indicate a hardfork is deployed. It alleviates certain risks related to a hardfork by introducing an explicit “point of no return” in the blockchain. This is a general mechanism which should be employed by any planned hardfork in the future.


Hardforks in Bitcoin are usually considered as difficult and risky, because:


  1. Hardforks require not only support of miners, but also, most importantly, supermajority support of the Bitcoin economy. As a result, softfork deployment mechanisms described in BIP 34 or BIP 9 are not enough for introducing hardforks safely.
  2. Full nodes and SPV nodes following original consensus rules may not be aware of the deployment of a hardfork. They may stick to an economic-minority fork and unknowingly accept devalued legacy tokens.
  3. In the case which the original consensus rules are also valid under the new consensus rules, users following the new chain may unexpectedly reorg back to the original chain if it grows faster than the new one. People may find their confirmed transactions becoming unconfirmed and lose money.
The first issue involves soliciting support for a hardfork proposal, which is more a political topic than a technical one. This proposal aims at alleviating the risks related to the second and third issues. It should be employed by any planned hardfork in the future.



See BIP99


Hardfork bit The sign bit in nVersion is defined as the hardfork bit. Currently, blocks with this header bit setting to 1 are invalid, since BIP65 interprets nVersion as a signed number and requires it to be ≥ 4. Among the 640 bits in the block header, this is the only one which is fixed and serves no purpose, and therefore the best way to indicate the deployment of a hardfork.

Flag block Any planned hardfork must have one and only one flag block which is the “point of no return”. To ensure monotonicity, flag block should be determined by block height, or as the first block with GetMedianTimePast() greater than a threshold. Other mechanisms could be difficult for SPV nodes to follow. The height/time threshold could be a predetermined value or relative to other events (e.g. 10000 blocks / 100 days after 95% of miner support). The exact mechanism is out of the scope of this BIP. No matter what mechanism is used, the threshold is consensus critical. It must be publicly verifiable with only blockchain data, and preferably SPV-friendly (i.e. verifiable with block headers only, without downloading any transaction).

Flag block is constructed in a way that nodes with the original consensus rules must reject. On the other hand, nodes with the new consensus rules must reject a block if it is not a flag block while it is supposed to be. To achieve these goals, the flag block must

  1. have the hardfork bit setting to 1, and
  2. follow any other rules required by the hardfork
If these conditions are not fully satisfied, upgraded nodes shall reject the block.


The hardfork bit must be turned off in the successors of the flag block, until the deployment of the next hardfork.

Although a hardfork is officially deployed when flag block is generated, the exact behavioural change is out of the scope of this BIP. For example, a hardfork may not be fully active until certain time after the flag block.

Concurrent hardfork proposals To avoid confusion and unexpected behaviour, a flag block should normally signify the deployment of only one hardfork. Therefore, a hardfork proposal has to make sure that its flag block threshold is not clashing with other ongoing hardfork proposals.

In the case that the version bits mechanism is used in deploying a hardfork, height of the flag block should take a value of32N + B, where N is a positive integer and B is the position of bit B defined in BIP9. This guarantees that no clash may happen with another hardfork proposal using BIP9.

Uncontroversial subtle hardforks Hardforks may sometimes be totally uncontroversial and make barely noticeable change (BIP50, for example). In such cases, the use of hardfork bit may not be needed as it may cause unnecessary disruption. The risk and benefit should be evaluated case-by-case.

Automatic warning system When a flag block for an unknown hardfork is found on the network, full nodes and SPV nodes should alert their users and/or stop accepting/sending transactions. It should be noted that the warning system could become a denial-of-service vector if the attacker is willing to give up the block reward. Therefore, the warning may be issued only if a few blocks are built on top of the flag block in a reasonable time frame. This will in turn increase the risk in case of a real planned hardfork so it is up to the wallet programmers to decide the optimal strategy. Human warning system (e.g. the emergency alert system in Bitcoin Core) could fill the gap.


As a mechanism to indicate hardfork deployment, this BIP breaks backward compatibility intentionally. However, without further changes in the block header format, full nodes and SPV nodes could still verify the Proof-of-Work of a flag block and its successors.

Hardfork involving change in block header format If a hardfork involves a new block header format, the original format should still be used for the flag block and a reasonable period afterwards, to make sure existing nodes realize that an unknown hardfork has been deployed.

Version bits This proposal is also compatible with the BIP9. The version bits mechanism could be employed to measure miner support towards a hardfork proposal, and to determine the height or time threshold of the flag block. Also, miners of the flag block may still cast votes for other concurrent softfork or hardfork proposals as normal.

Point of no return After the flag block is generated, a miner may support either the original rules or the new rules, but not both. It is not possible for miners in one fork to attack or overtake the other fork without giving up the mining reward of their preferred fork.


This document is placed in the public domain.

bitcoin-dev mailing list
bitcoin-dev <at>

Re: BIP Process: Status, comments, and copyright licenses

On Tuesday, February 02, 2016 11:28:40 PM Dave Scotese wrote:
> How about "defining" (rules, code, etc.) Such code and rules define what
> bitcoin is.  It does require consensus and it ends up being a concord, but
> all that can come after the fact (just as it did after bitcoin was first
> released to the public).

The difficulty is that this BIP needs to refer to three different context of 

1. Consensus (stated) among developers for changes in the BIP Process.
2. Economic consensus (potential and stated) to veto a soft-fork by an
   intended "firing" of the set of miners if they choose to enforce it.
3. (Actual) consensus in economic adoption of changed rules, to determine the
   success of a hard-fork (after the fact).
4. The set of rules currently established as (defining) Bitcoin, enforced by
   an (actual) consensus of economically-relevant nodes.

Context 3 can be disambiguated with "adoption consensus", and context 4 with 
"consensus rules" and/or "consensus protocol", but I don't see a clear 
solution that covers all four contexts, and even sharing the word "consensus" 
for them may be confusing.

In addition, usage of the word "consensus" for context 4 has proven confusing 
to users. For example, recently users misinterpreted the "Consensus" label 
used in context 4 as implying that the idea itself had in fact achieved 
consensus among some group of decision-makers (similar to context 1, but not 
necessarily the group being "developers").

I don't know a good way to make this completely clear, so suggestions are more 
than welcome.


BIP Process: Status, comments, and copyright licenses

I've completed an initial draft of a BIP that provides clarifications on the 
Status field for BIPs, as well as adding the ability for public comments on 
them, and expanding the list of allowable BIP licenses.

I plan to open discussion of making this BIP an Active status (along with BIP 
123) a month after initial revisions have completed. Please provide any 
objections now, so I can try to address them now and enable consensus to be 


Luke Dashjr via bitcoin-dev | 30 Jan 19:50 2016

SegWit GBT updates

I've completed an initial draft of a BIP for updating getblocktemplate for 
segregated witness here:

Please review and comment (especially with regard to the changes in the 
sigoplimits handling).

(Note: libblkmaker's reference implementation is at this time incompatible 
with the "last output" rule in this BIP.)



Best (block nr % 2016) for hard fork activation?


Question if you'll allow me. This is not about Gavin's latest hard fork proposal but in general about any hard (or soft) fork.

I was surprised to see a period expressed in human time instead of in block time:

> Blocks with timestamps greater than or equal to the triggering block's timestamp plus 28 days (60*60*24*28 seconds) shall have the new limits.

But even more so I would expect there to be significant differences in effects on non-updated clients depending on the moment (expressed as block number) of applying the new rules. I see a few options, all relating to the 2016 blocks recalibration window.

1) the first block after difficulty adjustment.
2) the last block before the difficulty adjustment.
3) in the middle
4) n blocks before the adjustment with n the smallest number of blocks calculated such that the adjustment can just manage to do the maximum possible drop in difficulty.

One of the effects I'm thinking of would be in case of an evil contentious 75-25 hard fork. If that activates at 1) or 2) it will take an awful long time for the 25% chain to get to 2016 for the next adjustment all the while having 40 minutes block times. Option 4) sounds a lot better for the conservative chain. The attacking fork clearly has a choice to make it as hard as possible for them.

On the other hand when a non-contentious hard fork is rolled out, one could argue that it's actually best for everyone if the remaining 1% chain doesn't stand a chance of ever reaching 2016 blocks anymore (not even by a decent sized attacker trying to double spend on stragglers). Also causing all alarm bells to go off in the non-updated clients.

Have people thought through all the different scenarios yet?

And would it not make sense to define whatever the best choice is as mandatory for any hard fork proposal? BIP9? (Realising attackers won't necessarily follow BIPs anyway.)

Does something like this also play a role for soft forks?

I do realise that it's quite possible for the first few blocks, mined after the new rules become valid, to still be old style blocks. Thus maybe defeating the whole planning.

bitcoin-dev mailing list
bitcoin-dev <at>

BIP Classification Process


I think the current situation with forks could have been avoided with a better process that can distinguish between different layers for bitcoin modification proposals.

For instance, BIP64 was proposed by Mike Hearn, which does not affect the consensus layer at all. Many Core devs disliked the proposal and Mike had lots of pushback. Regardless of whether or not you agree with the merits of Mike’s ideas here, fact is having nodes that support BIP64 would not fundamentally break the Bitcoin network.

This issue prompted Mike to break off from Core and create XT as the applications he was developing required BIP64 to work. With this split, Gavin found a new home for his big block ideas…and the two teamed up.

We need to have a process that clearly distinguishes these different layers and allows much more freedom in the upper layers while requiring agreement at the consensus layer. Many of these fork proposals are actually conflating different features, only some of which would actually be consensus layer changes. When people proposing nonconsensus features get pushback from Core developers they feel rejected and are likely to team up with others trying to push for hard forks and the like.

A while back I had submitted a BIP -  BIP123 - that addresses this issue. I have updated it to include all the currently proposed and accepted BIPs and have submitted a PR:

I urge everyone to seriously consider getting this BIP accepted as a top priority before we get more projects all trying their hand at stuff and not understanding these critical distinctions.

- Eric
bitcoin-dev mailing list
bitcoin-dev <at>
Peter Todd via bitcoin-dev | 28 Jan 19:51 2016

Segwit Upgrade Procedures & Block Extension Data

A few notes on upgrade procedures associated with segregated witnesses:

Initial Deployment

While segregated witnesses is a soft-fork, because it adds new data
blocks that old nodes don't relay segwit nodes can't sync from
non-segwit nodes and still be fully validating; once the segwit softfork
has activated full nodes need witness data to function. This poses a
major problem during deployment: if full node adoption lags miner
adoption, the segwit-supporting P2P network can partition and lose

While Pieter Wuille's segwit branch(1) doesn't yet implement a fix for
the above problem, the obvious thing to do is to add a new service bit
such as NODE_SEGWIT, and/or bump the protocol version, and for outgoing
peers only connect to peers with segwit support. Interestingly, a
closely related problem already exists in Bitcoin Core: neither addrman
nor the outgoing connection thread takes what service bits a peer
advertises into account. So if a large number of non-block-relaying
nodes joined the network and advertised their addresses the network
could, in theory, partition even without an explicit attack. (My own
full-RBF fork of Bitcoin Core does fix(2) this issue, though by

Note how because of this the segwit soft-fork has properties not unlike
hard-forks in terms of the need for nodes to upgrade with regard to the
P2P layer. Even with the above fix, the worst case would be for segwit
to not be adopted widely by full node operators, resulting in a network
much more vulnerable to attacks such as DoSing nodes. This is one of the
(many) reasons why hard-forks are generally significantly more dangerous
than soft-forks.

Future Upgrades

Segwit isn't going to be the last thing that adds new block data. For
example, my own prev-block-proof proposal(3) requires that blocks commit
to another tree, which itself is calculated using a nonce that must be
passed along with the block data. (U)TXO commitments are another
possible future example.

BIP141 (currently) suggests an Extensible Commitment Structure(4)
consisting of a hashed linked list of consensus-critical commitments,
with a redefinable nonce at the end of the list for future soft-forks.
Currently this nonce is put into the otherwise useless, and non-hashed,
witness for the coinbase transaction(6) and a block is invalid if its
witness contains more than that single nonce.(7)

Unfortunately, this means that the next soft-fork upgrade to add
additional data will have the above relaying problem all over again!
Even a minimal upgrade adding a new commitment - like my
prev-block-proof proposal - needs to at least add another nonce for
future upgrades. In addition to having to upgrade full nodes, this also
requires systems like the relay network to upgrade, even though they may
not themselves otherwise need to care about the contents of blocks.

A more subtle implication of this problem is how do you handle parallel
upgrades, as proposed by BIP9? Splitting the P2P network into
non-upgraded nodes, and a much smaller group of upgraded nodes, is bad
enough when done every once in a awhile. How does this look with more
frequent upgrades, not necessarily done by teams that are working
closely with each other?

Proposal: Unvalidated Block Extension Data

1) Remove the restriction that the coinbase witness contain exactly one
   32byte value.

2) Hash the contents of the coinbase witness (e.g. as a merkle tree) and
   commit them in place of the current nonce commitment.

3) Include that data in the blocksize limit (to prevent abuse).

Now future soft-forks can simply add additional data, which non-upgraded
nodes simply see as extension data that they don't know how to fully
validate. All nodes can however validate that data came from the miner,
and thus they can freely propagate that data without risk of attack
(Bitcoin Core used to allow additional data to be included with
transactions, which was used in a DoS attack (CVE-2013-4627)).

This is more efficient than it may appear at first glace. As most future
upgrades are expected to be additional commitments where full nodes can
deterministically recalculate the commitment, the additional data for
each new commitment is just 32 bytes.

A significant design consideration is that if arbitrary data can be
added, it is very likely that miners will make use of that ability for
non-Bitcoin purposes; we've already run into problems deploying segwit
itself because of pools using the coinbase space for advertising and
merge-mining. Avoiding this problem is easiest with a merkelized
key:value mapping, with the ability to use collision-resistant ID's as
keys (e.g. UUID).

Secondly, does using the coinbase witness for this really make sense?
Logically it'd make more sense to change the way blocks are serialized,
much the same way transaction serialization was changed to accomodate
segwit; stuffing this in the coinbase witness smells like a hack. (along
those lines, note how witnesses themselves could have been implemented
this way - probably too late to change now)









-- 'peter'[:-1] <at>
bitcoin-dev mailing list
bitcoin-dev <at>

Fee smoothing

This post serves to convince you of the economic benefits of smoothing
the payout of fees across blocks. It incentivizes decentralization and
supports the establishment of a fee market.

Idea: currently, the total amount of fees collected in a block is paid
out in full to whoever mined that block. I propose to only pay out,
say, 10% of the collected fees, and to add the remaining 90% to the
collected fees of the next block. Thus, the payout to the miner
constitutes a rolling average of collected fees from the current and
past blocks. This reduces the marginal benefit of including an
additional transaction into a block by an order of magnitude and thus
aligns the incentives of individual miners better with those of the
whole network. As a side-effect, the disadvantage of mining with a
slow connection is reduced.

Example: currently, given a transaction with a fee of 1000 Satoshis
and global processing cost per transaction of 5000 Satoshis, an
individual miner would still include the transaction if it costs him
500 Satoshis to do so, as the remaining burden of 4500 Satoshis is
carried by others (a classic externality). However, with fee
smoothing, the immediate benefit of including that particular
transaction is reduced to 100 Satoshis, aligning the economic
incentives of the miner better with the whole network and leading the
miner to skip it. Generally, the fraction that is paid out immediately
(here 10%) can be used to adjust the incentive, but not arbitrarily.

1. The disadvantage of mining with a slow connection is reduced by an
order of magnitude. If it takes 30 seconds to download the latest
block, a miner loses 5% of the potential income from fees as he does
not know yet which transactions to include in the next block. With fee
smoothing, that loss is reduced to 0.5% as he would still earn 90% of
the average fees per block by mining an empty one based on the latest
2. This is a step towards a free fee market. In an ideal market,
prices form where supply and demand meet, with the fees asymptotically
approaching the marginal costs of a transaction. Currently, supply is
capped and only demand can adjust. Should we ever consider to let
miners decide about supply, it is essential that their marginal
benefit of including an additional transaction is aligned with the
global marginal cost incurred by that additional transaction. Fee
smoothing is a step in this direction.
3. The incentive to form mining pools is reduced. Currently,
solo-mining yields a very volatile income stream due to the random
nature of mining, leading to the formation of pools. This volatility
will increase to even higher levels once the amount of Bitcoins earned
per block is dominated by (volatile) collected fees and not by
(constant) freshly minted coins, thus increasing the economic pressure
to join a large pool. Fee smoothing reduces that volatility and

Problems: touching anything related to fee distribution is a political
minefield. This proposal probably requires a hard fork. Its technical
feasibility was only superficially verified.

This is my first post to this list and I am looking forward to your
comments. In case this proposal is received well, I plan to
specify/implement the idea more formally in order to kick off the
usual process for improvements.


Luzius Meisser
President of Bitcoin Association Switzerland
MSc in Computer Science and MA in Economics