Overview
- What specific technologies are included in the roadmap, and when can we expect them?
- Is the segregated witness soft fork equivalent to a 4 MB block size increase, a 2 MB increase, a 1.75 MB increase, or what? I keep hearing different numbers.
- Segregated witness sounds complicated; will the ecosystem be prepared for its deployment?
- Segregated witness still sounds complicated. Why not simply raise the maximum block size?
- Will there be a hard fork before or as part of the segregated witness implementation?
- If there’s eventually going to be a hard fork, why not do it now?
- How will segregated witness transactions work for wallets?
- If no one is forced to upgrade, why will anyone bother to upgrade? I heard P2SH took almost two years to become widely deployed.
- I heard you were breaking zero-confirmation transactions. Which technology in the scaling roadmap is doing that?
- Weak blocks and IBLTs just say “2016” in the roadmap schedule. Does this mean you have no idea when they’ll be available?
- “Why would miners adopt the SegWit format, given that it does not provide any savings of bandwidth, storage, or processing time to them?”
- How can I help?
What specific technologies are included in the roadmap, and when can we expect them?
New technology will be deployed when it is ready and has been tested. However, we believe the following is a reasonable schedule for the specific improvements described in the roadmap.
| Dec 2015 | Deploy segregated witness testnet |  |
|
| Feb 2016 | 0.12.0 | libsecp256k1 verification | |
| Feb 2016 | Segregated witness feature complete & ready for general review | |
|
| Mar 2016 | 0.12.1 | Deploy OP_CHECKSEQUENCEVERIFY (BIPs 68 & 112) + BIP113 as first BIP9 versionbits soft fork | |
| Segregated witness pull request | |
||
| Oct 2016 | 0.13.1 | Deploy segregated witness (including block size increase) | |
| 2017 | Weak blocks and IBLT, Lightning, or both |
-
Segregated witness testnet: a separate testnet (not part of the regular testnet) that provides an opportunity for Bitcoin Core contributors to test segregated witness and for wallet authors to begin working with it.
-
Libsecp256k1 verification: 500% to 700% speed boost on x86_64 hardware during verification to help new full nodes join the network and to lighten the burden on existing nodes.
-
OP_CHECKSEQUENCEVERIFY: 25,000% improvement in bi-directional payment channel efficiency by allowing users to keep channels open as long as they want.
-
VersionBits: increase the maximum number of soft forks able to be deployed simultaneously from 1 to 29, allowing for faster and more decentralized future upgrades of the network.
-
Segregated witness: 175% to 400% direct capacity upgrade, 66% additional improvement in bi-directional channel efficiency by consolidating channel open and close operations, an end to third-party malleability that hurts smart contract deployment, fraud proofs to allow lightweight clients to better participate in economic enforcement, and ability to more easily upgrade Bitcoin’s Script language so that new and more powerful trustless contracts may be devised.
-
IBLTs and weak blocks: 90% or more reduction in critical bandwidth to relay blocks created by miners who want their blocks to propagate quickly with a modest increase in total bandwidth, bringing many of the benefits of the Bitcoin Relay Network to all full nodes. This improvement is accomplished by spreading bandwidth usage out over time for full nodes, which means IBLT and weak blocks may allow for safer future increases to the max block size.
Is the segregated witness soft fork equivalent to a 4 MB block size increase, a 2 MB increase, a 1.75 MB increase, or what? I keep hearing different numbers.
The current proposal for soft fork segregated witness (segwit) replaces the block size limit with a new block cost limit, counting each byte of witness data as 1 unit of cost and UTXO transaction data as 4 units; as a result, the maximum size of a block becomes just under 4 MB.
However, blocks are not expected to consist entirely of witness data, so blocks near 4 MB in size would be unlikely.
According to some calculations performed by Anthony Towns, a block filled with standard single-signature P2PKH transactions would be about 1.6 MB and a block filled with 2-of-2 multisignature transactions would be about 2.0 MB. It is further likely that future scaling improvements, such as Lightning, may slightly improve the ratio such that filled blocks become larger than 2 MB.
Segregated witness sounds complicated; will the ecosystem be prepared for its deployment?
Some ideas are easy to explain but hard to execute. Other ideas are easy to execute but hard to explain. Segregated witness (segwit) seems to be the latter.
Segwit can be deployed incrementally without breaking compatibility, so no significant preparation of the ecosystem is necessary. Developers who want immediate hands-on experience with segwit have begun to test their software on the segwit testnet deployed Dec 2015.
Initially, only miners who wish to support it need to upgrade in order to activate it and enforce it on the mainnet. Existing applications only need to change if they wish to take advantage of the new features and additional block space.
Segregated witness transactions will require lower fees, will afford much greater performance optimizations, and can support multistage smart contracts and protocols such as bi-directional payment channels that can scale without writing extra data to the blockchain. Wallets are strongly encouraged to upgrade but can continue to operate without modification as the deployment does not break backwards compatibility.
Segregated witness still sounds complicated. Why not simply raise the maximum block size?
There’s a single line of code in Bitcoin Core that says the maximum block size is 1,000,000 bytes (1 MB). The simplest code modification would be a hard fork to update that line to say, for example, 2,000,000 bytes (2 MB).
However, hard forks are anything but simple:
-
We don’t have experience: Miners, merchants, developers, and users have never deployed a non-emergency hard fork, so techniques for safely deploying them have not been tested.
This is unlike soft forks, whose deployments were initially managed by Nakamoto, where we gained experience from the complications in the BIP16 deployment, where we refined our technique in the BIP34 deployment, and where we’ve gained enough experience with BIPs 66 and 65 to begin managing multiple soft forks with BIP9 version bits in the future.
-
Upgrades required: Hard forks require all full nodes to upgrade or everyone who uses that node may lose money. This includes the node operator, if they use it to protect their wallet, as well as lightweight clients who get their data from the node.
-
Other changes required: Even a single-line change such as increasing the maximum block size has effects on other parts of the code, some of which are undesirable. For example, right now it’s possible to construct a transaction that takes up almost 1 MB of space and which takes 30 seconds or more to validate on a modern computer (blocks containing such transactions have been mined). In 2 MB blocks, a 2 MB transaction can be constructed that may take over 10 minutes to validate which opens up dangerous denial-of-service attack vectors. Other lines of code would need to be changed to prevent these problems.
Despite these considerable complications, with sufficient precautions, none of them is fatal to a hard fork, and we do expect to make hard forks in the future. But with segregated witness (segwit) we have a soft fork, similar to other soft forks we’ve performed and gained experience in deploying, that provides us with many benefits in addition to allowing more transactions to be added to the blockchain.
Segwit does require more changes in higher level software stacks than a simple block size increase, but if we truly want to see bitcoin scale, far more invasive changes will be needed anyway, and segwit will gently encourage people to upgrade to more scalable models right away without forcing them to do so.
Developers, miners, and the community have accrued significant experience deploying soft forks, and we believe segwit can be deployed at least as fast, and probably more securely, than a hard fork that increases the maximum block size.
Will there be a hard fork before or as part of the segregated witness implementation?
No. That is not part of the roadmap.
If there’s eventually going to be a hard fork, why not do it now?
We currently have the ability to increase the capacity of the system through soft forks that have widespread consensus without any of the complications of a hard fork, as described in an earlier question, so the expectation that there will be an eventual hard fork is not sufficient reason to attempt one now.
In addition to giving us extra transaction capacity, the improvements proposed in the roadmap (combined with other technology such as bi-directional payment channels) give users the ability to reduce the amount of blockchain space they use on average—effectively increasing the capacity of the Bitcoin system without increasing the amount of full node bandwidth used.
For example,
-
BIP68 and BIP112 allow bi-directional payment channels to stay open indefinitely, which we expect to vastly reduce the number of payment channel transactions that need to be committed to the blockchain.
-
Segregated witness allows a payment channel close transaction to be combined with a payment channel open transaction, reducing the blockchain space used to change channels by about 66%.
-
Segregated witness allows soft forks to change the Bitcoin Script language in ways that could reduce the average size of a transaction, such as using public-key-recovery-from-signatures or Schnorr combined signatures.
-
Segregated witness permits the creation of compact fraud proofs that may bring the security of Simplified Payment Verification (SPV) lightweight clients up near to that of full nodes, which may allow the network to function well with fewer full nodes than it can under currently-deployed technology.
The actual effect of these technologies is unknown, but scaling now with a soft fork that has wide consensus allows us to obtain the immediate gains, test and measure the mid-term possibilities, and use that data to formulate long-term plans.
How will segregated witness transactions work for wallets?
Wallets that currently support P2SH can migrate to full segregated witness in two phases:
-
Phase 1: Scripts are hashed twice, first to 256 bits and then to 160 bits. The 160 bit hash will be compatible with existing P2SH addresses, so upgraded wallets will be able to send and receive bitcoins to and from currently existing wallets.
-
Phase 2: Scripts are hashed once to 256 bits. This format will not be compatible with existing wallets but will allow more efficient use of block space and will offer better security due to greater collision resistance.
If no one is forced to upgrade, why will anyone bother to upgrade? I heard P2SH took almost two years to become widely deployed.
Each byte of the witness part of a segregated witness (segwit) transaction will only count as 0.25 bytes towards the size of the transaction. Since transaction fees are based on the size of a transaction, this is effectively a 75% discount on fees for that part of a transaction—but only for people who use segwit.
David Harding provided a table of estimated savings at various fee/transaction levels. That is, if the fee for a typical 250-byte transaction is $0.01 USD, using segwit will save about $0.003 when spending a P2PK-in-P2SH transaction output.
| Transaction | Bytes saved | $0.01/250B | $0.05/250B | $0.25/250B | $1.00/250B |
|---|---|---|---|---|---|
| P2PK-in-P2SH | 79/107 | $0.003 | $0.015 | $0.079 | $0.316 |
| 1-of-1 P2SH multisig | 83/112 | $0.003 | $0.016 | $0.083 | $0.332 |
| 2-of-2 P2SH multisig | 163/219 | $0.006 | $0.032 | $0.163 | $0.652 |
| 2-of-3 P2SH multisig | 189/254 | $0.007 | $0.037 | $0.189 | $0.756 |
(We don’t expect fees to get as high as the highest seen in this table; they are just provided for reference.)
Web wallets and exchanges that send large numbers of transactions each day at fixed rates (such as for free or for 1% per spend) are expected to be early adopters—even the small savings per spend seen in the table above will add up to significant amounts of money if repeated hundreds or thousands of times a day.
I heard you were breaking zero-confirmation transactions. Which technology in the scaling roadmap is doing that?
None of them. By default, current versions of Bitcoin Core won’t replace an unconfirmed transaction with another transaction that spends any of the same inputs. Some people think this means the first transaction they see that spends a particular input is safe, but this is untrue. (If it were true, we wouldn’t need the blockchain.)
This current default policy does mean that people who want to be able to update their unconfirmed transactions can’t do that. The original version of Bitcoin provided people with a way to indicate that they wanted to be able to update their transactions, but Nakamoto had to disable it in 2010 to prevent denial-of-service (DoS) attacks.
Recent Bitcoin Core developers realized that they could prevent the DoS attack by requiring updated transactions pay extra fees, and they’ve re-enabled Nakamoto’s mechanism for indicating when a transaction can be replaced. This feature is planned for Bitcoin Core 0.12.0 (expected Jan/Feb 2016) but, like Nakamoto’s original feature, is opt-in so people who want to be able to replace their transactions have to use a wallet that supports that feature.
Currently there are no wallets that provide this feature, but wallets that do provide it in the future may be able to combine multiple transactions together to reduce the amount of blockchain space they use as well as increase the fees they pay on transactions that are taking a long time to confirm, helping to prevent transactions from getting “stuck” (a known usability problem).
Weak blocks and IBLTs just say “2016” in the roadmap schedule. Does this mean you have no idea when they’ll be available?
Weak blocks and IBLTs are two separate technologies that are still being actively studied to choose the right parameters, but the number of developers working on them is limited and so it’s difficult to guess when they’ll be deployed.
Weak blocks and IBLTs can both be deployed as network-only enhancements (no soft or hard fork required) which means that there will probably only be a short time from when testing is completed to when their benefits are available to all upgraded nodes. We hope this will happen within 2016.
After deployment, both weak blocks and IBLTs may benefit from a simple non-controversial soft fork (canonical transaction ordering), which should be easy to deploy using the BIP9 versionBits system described elsewhere in this FAQ.
“Why would miners adopt the SegWit format, given that it does not provide any savings of bandwidth, storage, or processing time to them?”
Most previous soft forks have not provided these benefits to miners either. For example,
| BIP16 (P2SH) | New transaction type |
| BIP30 (duplicate txids) | Required checking for duplicate txids |
| BIP34 (height in coinbase) | Reduced miner coinbase space by 4 bytes |
| BIP65 (OP_CLTV) | New opcode |
The BIP66 (strict DER) soft fork which activated in July 2015 will soon be providing reduced processing time by making it possible to switch to libsecp256k1 for validation as described elsewhere in this FAQ. The reduced validation time makes it uncommon among soft forks in that it provides direct benefits to miners.
What segregated witness (segwit) does is provide several major benefits to anyone who uses it to create transactions:
A permanent fix for third-party malleability, allowing multi-stage smart contracts to flourish. A modest reduction in fees. Easy future upgrades to Bitcoin Script, so wallets can more easily gain access to new features.
Through the previous soft forks, and through conversations such as the Miners’ Panel at Scaling Bitcoin Hong Kong, miners have repeatedly shown that they want Bitcoin to be the most useful system possible even if they don’t receive any direct benefits. Segwit and the other improvements in the roadmap provide significant usability enhancements.
In addition, segwit allows miners to put more transactions in their blocks, which may allow them to increase their per-block revenue.
How can I help?
Start by reading the Bitcoin Core contributor pages on Bitcoin.org. In particular, code review is a critical part of getting soft forks deployed.
To get specific suggestions on how you can help, please join the #bitcoin-dev IRC channel.