mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 09:46:12 +00:00
Add capacity increses FAQ
This commit is contained in:
David A. Harding
parent
f394135bf0
commit
0934026778
3 changed files with 367 additions and 2 deletions
364
en/bitcoin-core/capacity-increases-faq.md
Normal file
364
en/bitcoin-core/capacity-increases-faq.md
Normal file
|
|
@ -0,0 +1,364 @@
|
|||
---
|
||||
# This file is licensed under the MIT License (MIT) available on
|
||||
# http://opensource.org/licenses/MIT.
|
||||
|
||||
layout: base-core
|
||||
lang: en
|
||||
id: bitcoin-core-capacity-increases-faq
|
||||
columns: 1
|
||||
title: Capacity increases FAQ — Bitcoin Core
|
||||
breadcrumbs:
|
||||
- bitcoin
|
||||
- bcc
|
||||
- Capacity increases FAQ
|
||||
---
|
||||
# Capacity increases FAQ
|
||||
|
||||
1. toc
|
||||
{:toc}
|
||||
|
||||
## What specific technologies are included in the roadmap, and when can we expect them? {#roadmap-dates}
|
||||
|
||||
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.x | Deploy OP_CHECKSEQUENCEVERIFY (BIPs [68][BIP68] & [112][BIP112]) + [BIP113][] as first [BIP9][] versionbits soft fork |
|
||||
| April 2016\* | 0.12.x | Deploy segregated witness |
|
||||
| 2016 | | Weak blocks, IBLTs, or both |
|
||||
|
||||
\* Dates with an asterisk are when we expect to release soft fork-ready code. The code will not be released until it has been well reviewed, and the actual fork will take time to activate ([BIP66][] activated in July 2015 after a few months; [BIP65][] activated in Dec 2015 after only 5 weeks).
|
||||
|
||||
- **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 4MB block size increase, a 2MB increase, a 1.75MB increase, or what? I keep hearing different numbers. {#segwit-size}
|
||||
|
||||
The [current proposal][] for soft fork segregated witness (segwit) counts
|
||||
each byte in a witness as 0.25 bytes towards the maximum block size
|
||||
limit, meaning the maximum size of a block is just under 4MB.
|
||||
|
||||
However, blocks are not expected to consist entirely of witness data and
|
||||
each non-witness byte is counted as 1.00 bytes towards the maximum block
|
||||
size limit, so blocks near 4MB 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.6MB and a block filled with 2-of-2 multisignature transactions would
|
||||
be about 2.0MB.
|
||||
|
||||
[current proposal]: https://youtu.be/fst1IK_mrng?t=2234
|
||||
[calculations]: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html
|
||||
|
||||
## Segregated witness sounds complicated; will the ecosystem be prepared for its deployment? {#ecosystem-ready}
|
||||
|
||||
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 can begin to test
|
||||
their software on the segwit testnet being deployed in 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.
|
||||
|
||||
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? {#size-bump}
|
||||
|
||||
There's a [single line of code][max_block_size] in Bitcoin Core that says the maximum block size is 1,000,000 bytes (1MB). The simplest change would be a hard fork to update that line to say, for example, 2,000,000 bytes (2MB).
|
||||
|
||||
Hard forks are anything but simple:
|
||||
|
||||
- **We don't have experience:** Miners, merchants, developers, and users
|
||||
have never deployed a 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][BIP66]
|
||||
and [65][BIP65] 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 1MB of
|
||||
space and which takes 30 seconds or more to validate on a modern
|
||||
computer (blocks containing such transactions have been mined). In
|
||||
2MB blocks, a 2MB 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 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? {#pre-segwit-fork}
|
||||
|
||||
No. That is not part of the [roadmap][].
|
||||
|
||||
[roadmap]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
|
||||
|
||||
## If there's eventually going to be a hard fork, why not do it now? {#why-not-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][q simple raise], 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? {#segwit-in-wallets}
|
||||
|
||||
Wallets that currently support P2SH can migrate to full segregated
|
||||
witness in two phases:
|
||||
|
||||
- Phase 1: Scripts are hashed twice, first to 256 bytes and then to 160
|
||||
bytes. The 160 byte 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 bytes. 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. {#why-upgrade}
|
||||
|
||||
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 adds 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? {#rbf}
|
||||
|
||||
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 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 transactions 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-iblts}
|
||||
|
||||
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.
|
||||
|
||||
[canonical transaction ordering]: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions
|
||||
|
||||
## “Why would miners adopt the SegWit format, given that it does not provide any savings of bandwidth, storage, or processing time to them?” {#why-mine-segwit}
|
||||
|
||||
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 is this
|
||||
FAQ. The reduced validation time make makes it fairly unique among soft
|
||||
forks in providing 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.
|
||||
|
||||
[#bitcoin-dev]: https://webchat.freenode.net/?channels=bitcoin-dev&uio=d4
|
||||
[BIP9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
|
||||
[BIP16]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
|
||||
[BIP34]: https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
|
||||
[BIP50]: https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
|
||||
[BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
|
||||
[BIP66]: https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki
|
||||
[BIP68]: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
|
||||
[BIP112]: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
|
||||
[BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
|
||||
[bitcoin core contributor]: /en/bitcoin-core/
|
||||
[Bitcoin relay network]: http://bitcoinrelaynetwork.org/
|
||||
[code review]: https://bitcoin.org/en/development#code-review
|
||||
[estimated savings]: https://www.reddit.com/r/bitcoinxt/comments/3w1i6b/i_attended_scaling_bitcoin_hong_kong_these_are_my/cxtkaih
|
||||
[increase in total bandwidth]: https://scalingbitcoin.org/hongkong2015/presentations/DAY1/3_block_propagation_1_rosenbaum.pdf
|
||||
[libsecp256k1 verification]: https://github.com/bitcoin/bitcoin/pull/6954
|
||||
[max_block_size]: https://github.com/bitcoin/bitcoin/blob/3038eb63e8a674b4818cb5d5e461f1ccf4b2932f/src/consensus/consensus.h#L10
|
||||
[miners' panel]: https://youtu.be/H-ErmmDQRFs?t=1086
|
||||
[payment channel efficiency]: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/1_layer2_2_dryja.pdf
|
||||
[previous soft forks]: https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki#classification-of-existing-bips
|
||||
[q simple raise]: #size-bump
|
||||
|
|
@ -19,7 +19,8 @@ Bitcoin system.][1] We have been working on
|
|||
scalability for several years within the Bitcoin Core project and
|
||||
consider this the best possible continuation of our efforts.
|
||||
|
||||
A FAQ is being prepared and will be linked from here when available.
|
||||
For more information, please see the
|
||||
[FAQ](/en/bitcoin-core/capacity-increases-faq).
|
||||
|
||||
{% include bitcoin-core/capability-increases-sigs.md %}
|
||||
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ breadcrumbs:
|
|||
{% endcapture %}
|
||||
{% assign array_releases = text_releases | strip_newlines | split: '::' %}
|
||||
|
||||
- 2015-12-21 - [Roadmap: Capacity increases for the Bitcoin system](/en/bitcoin-core/capacity-increases)
|
||||
- 2015-12-21 - Capacity increases for the Bitcoin system: [Statement](/en/bitcoin-core/capacity-increases) & [FAQ](/en/bitcoin-core/capacity-increases-faq)
|
||||
{% comment %}<!-- show the latest three releases -->{% endcomment %}
|
||||
{% for release in array_releases %}
|
||||
{% if forloop.index <= 3 %}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue