From ac13200468e36e0b8b203db82e359ef4ee65874f Mon Sep 17 00:00:00 2001 From: MarcoFalke Date: Mon, 17 Jan 2022 12:01:17 +0100 Subject: [PATCH 1/2] Remove roadmap from 2015 --- .../posts/2015-12-07-ml-capacity-roadmap.md | 93 -------- .../en/posts/2015-12-14-segregated-witness.md | 18 -- .../en/posts/2015-12-21-capacity-increases.md | 21 -- .../2015-12-23-capacity-increases-faq.md | 199 ------------------ assets/images/ok-48.png | Bin 1301 -> 0 bytes 5 files changed, 331 deletions(-) delete mode 100644 _posts/en/posts/2015-12-07-ml-capacity-roadmap.md delete mode 100644 _posts/en/posts/2015-12-14-segregated-witness.md delete mode 100644 _posts/en/posts/2015-12-21-capacity-increases.md delete mode 100644 _posts/en/posts/2015-12-23-capacity-increases-faq.md delete mode 100644 assets/images/ok-48.png diff --git a/_posts/en/posts/2015-12-07-ml-capacity-roadmap.md b/_posts/en/posts/2015-12-07-ml-capacity-roadmap.md deleted file mode 100644 index 24346ba89..000000000 --- a/_posts/en/posts/2015-12-07-ml-capacity-roadmap.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Capacity increases Roadmap for the Bitcoin system -permalink: /en/2015/12/07/roadmap/ -lang: en -id: en-ml-roadmap-2015-12-07 -name: ml-roadmap-2015-12-07 -type: posts -layout: post -canonical: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html -version: 1 ---- -_The following roadmap was originally posted to the [bitcoin-dev mailing list](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html), by Gregory Maxwell on 2015-12-07._ - -The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating proposals were presented. -I think this would be a good time to share my view of the near term arc for capacity increases in the Bitcoin system. -I believe we’re in a fantastic place right now and that the community is ready to deliver on a clear forward path with a shared vision that addresses the needs of the system while upholding its values. - -I think it’s important to first clearly express some of the relevant principles that I think should guide the ongoing development of the Bitcoin system. - -Bitcoin is P2P electronic cash that is valuable over legacy systems because of the monetary autonomy it brings to its users through decentralization. Bitcoin seeks to address the root problem with conventional currency: all the trust that's required to make it work-- - --- Not that justified trust is a bad thing, but trust makes systems brittle, opaque, and costly to operate. -Trust failures result in systemic collapses, trust curation creates inequality and monopoly lock-in, and naturally arising trust choke-points can be abused to deny access to due process. -Through the use of cryptographic proof and decentralized networks Bitcoin minimizes and replaces these trust costs. - -With the available technology, there are fundamental trade-offs between scale and decentralization. -If the system is too costly people will be forced to trust third parties rather than independently enforcing the system's rules. -If the Bitcoin blockchain’s resource usage, relative to the available technology, is too great, Bitcoin loses its competitive advantages compared to legacy systems because validation will be too costly (pricing out many users), forcing trust back into the system. -If capacity is too low and our methods of transacting too inefficient, access to the chain for dispute resolution will be too costly, again pushing trust back into the system. - -Since Bitcoin is an electronic cash, it _isn't_ a generic database; the demand for cheap highly-replicated perpetual storage is unbounded, and Bitcoin cannot and will not satisfy that demand for non-ecash (non-Bitcoin) usage, and there is no shame in that. -Fortunately, Bitcoin can interoperate with other systems that address other applications, and--with luck and hard work--the Bitcoin system can and will satisfy the world's demand for electronic cash. - -Fortunately, a lot of great technology is in the works that make navigating the trade-offs easier. - -First up: after several years in the making Bitcoin Core has recently merged libsecp256k1, which results in a huge increase in signature validation performance. -Combined with other recent work we're now getting ConnectTip performance 7x higher in 0.12 than in prior versions. This -has been a long time coming, and without its anticipation and earlier work such as headers-first I probably would have been arguing for a block size decrease last year. -This improvement in the state of the art for widely available production Bitcoin software sets a stage for some capacity increases while still catching up on our decentralization deficit. This shifts the bottlenecks off of CPU and more strongly onto propagation latency and bandwidth. - -Versionbits (BIP9) is approaching maturity and will allow the Bitcoin network to have multiple in-flight soft-forks. Up until now we’ve had to completely serialize soft-fork work, and also had no real way to handle a soft-fork that was merged in core but rejected by the network. -All that is solved in BIP9, which should allow us to pick up the pace of improvements in the network. It looks like versionbits will be ready for use in the next soft-fork performed on the network. - -The next thing is that, at Scaling Bitcoin Hong Kong, Pieter Wuille presented on bringing Segregated Witness to Bitcoin. -What is proposed is a _soft-fork_ that increases Bitcoin's scalability and capacity by reorganizing data in blocks to handle the signatures separately, and in doing so takes them outside the scope of the current blocksize limit. - -The particular proposal amounts to a 4MB blocksize increase at worst. The separation allows new security models, such as skipping downloading data you're not going to check and improved performance for lite clients (especially ones with high privacy). -The proposal also includes fraud proofs which make violations of the Bitcoin system provable with a compact proof. -This completes the vision of "alerts" described in the "Simplified Payment Verification" section of the Bitcoin whitepaper, and would make it possible for lite clients to enforce all the rules of the system (under a new strong assumption that they're not partitioned from someone who would generate the proofs). -The design has numerous other features like making further enhancements safer and eliminating signature malleability -problems. If widely used this proposal gives a 2x capacity increase (more if multisig is widely used), but most importantly it makes that additional capacity--and future capacity beyond it--safer by increasing efficiency and allowing more trade-offs (in particular, you can use much less bandwidth in exchange for a strong non-partitioning assumption). - -There is a working implementation (though it doesn't yet have the fraud proofs) at . - -(Pieter's talk is at: [transcript](http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/), [slides](https://prezi.com/lyghixkrguao/segregated-witness-and-deploying-it-for-bitcoin/), [Video](https://www.youtube.com/watch?v=fst1IK_mrng#t=36m)). - -I had good success deploying an earlier (hard-fork) version of segwit in the Elements Alpha sidechain; the soft-fork segwit now proposed is a second-generation design. And I think it's quite reasonable to get this deployed in a relatively short time frame. -The segwit design calls for a future bitcoinj compatible hardfork to further increase its efficiency--but it's not necessary to reap most of the benefits,and that means it can happen on its own schedule and in a non-contentious manner. - -Going beyond segwit, there has been some considerable activity brewing around more efficient block relay. There is a collection of proposals, some stemming from a p2pool-inspired informal sketch of mine and some independently invented, called "weak blocks", "thin blocks" or "soft blocks". -These proposals build on top of efficient relay techniques (like the relay network protocol or IBLT) and move virtually all the transmission time of a block to before the block is found, eliminating size from the orphan race calculation. We already desperately need this at the current block sizes. These have not yet been implemented, but fortunately the path appears clear. -I've seen at least one more or less complete specification, and I expect to see things running using this in a few months. This tool will remove propagation latency from being a problem in the absence of strategic behavior by miners. Better understanding their behavior when miners behave strategically is an open question. - -Concurrently, there is a lot of activity ongoing related to “non-bandwidth” scaling mechanisms. -Non-bandwidth scaling mechanisms are tools like transaction cut-through and bidirectional payment channels which increase Bitcoin’s capacity and speed using clever smart contracts rather than increased bandwidth. -Critically, these approaches strike right at the heart of the capacity vs autotomy trade-off, and may allow us to achieve very high capacity and very high decentralization. CLTV (BIP65), deployed a month ago and now active on the network, is very useful for these techniques (essential for making hold-up refunds work); CSV (BIP68 / BIP112) is in the pipeline for merge in core and making good progress (and will likely be ready ahead of segwit). -Further Bitcoin protocol improvements for non-bandwidth scaling are in the works: Many of these proposals really want anti-malleability fixes (which would be provided by segwit), and there are checksig flag improvements already tendered and more being worked on, which would be much easier to deploy with segwit. -I expect that within six months we could have considerably more features ready for deployment to enable these techniques. Even without them I believe we’ll be in an acceptable position with respect to capacity in the near term, but it’s important to enable them for the future. - - is a relevant talk for some of the wanted network features for Lightning, a bidirectional payment channel proposal which many parties are working on right now; other non-bandwidth improvements discussed in the past include transaction cut-through, which I consider a must-read for the basic intuition about how transaction capacity can be greater than blockchain capacity: , though there are many others.) - -Further out, there are several proposals related to flex caps or incentive-aligned dynamic block size controls based on allowing miners to produce larger blocks at some cost. -These proposals help preserve the alignment of incentives between miners and general node operators, and prevent defection between the miners from undermining the fee market behavior that will eventually fund security. -I think that right now capacity is high enough and the needed capacity is low enough that we don't immediately need these proposals, but they will be critically important long term. -I'm planning to help out and drive towards a more concrete direction out of these proposals in the following months. - -(Relevant talks include . - -Finally--at some point the capacity increases from the above may not be enough. -Delivery on relay improvements, segwit fraud proofs, dynamic block size controls, and other advances in technology will reduce the risk and therefore controversy around moderate block size increase proposals (such as 2/4/8 rescaled to respect segwit's increase). -Bitcoin will be able to move forward with these increases when improvements and understanding render their risks widely acceptable relative to the risks of not deploying them. -In Bitcoin Core we should keep patches ready to implement them as the need and the will arises, to keep the basic software engineering from being the limiting factor. - -Our recent and current progress has well positioned the Bitcoin ecosystem to handle its current capacity needs. -I think the above sets out some clear achievable milestones to continue to advance the art in Bitcoin capacity while putting us in a good position for further improvement and evolution. - -TL;DR: I propose we work immediately towards the segwit 4MB block soft-fork which increases capacity and scalability, and recent speedups and incoming relay improvements make segwit a reasonable risk. BIP9 and segwit will also make further improvements easier and faster to deploy. -We’ll continue to set the stage for non-bandwidth-increase-based scaling, while building additional tools that would make bandwidth increases safer long term. -Further work will prepare Bitcoin for further increases, which will become possible when justified, while also providing the groundwork to make them justifiable. - -Thanks for your time, - -_Originally posted to the bitcoin-dev mailing list at , by Gregory Maxwell on 2015-12-07_ diff --git a/_posts/en/posts/2015-12-14-segregated-witness.md b/_posts/en/posts/2015-12-14-segregated-witness.md deleted file mode 100644 index 06df44796..000000000 --- a/_posts/en/posts/2015-12-14-segregated-witness.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -type: posts -layout: post -lang: en -id: en-segregated-witness -name: segregated-witness -title: Segregated Witness Video Presentation -permalink: /en/2015/12/14/segregated-witness/ -author: sipa -related: false -tags: [scalability] -version: 1 -excerpt: This is the extended presentation of Segregated Witness by Pieter Wuille. ---- - -This is the extended presentation of Segregated Witness by Pieter Wuille. - - \ No newline at end of file diff --git a/_posts/en/posts/2015-12-21-capacity-increases.md b/_posts/en/posts/2015-12-21-capacity-increases.md deleted file mode 100644 index 97988f468..000000000 --- a/_posts/en/posts/2015-12-21-capacity-increases.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -type: posts -layout: post -lang: en -id: en-capacity-increases -name: capacity-increases -title: Capacity increases for the Bitcoin system -permalink: /en/2015/12/21/capacity-increase/ -version: 1 ---- -We, the undersigned, support the roadmap in [Capacity increases for the 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. - -For more information, please see the [FAQ](/en/2015/12/23/capacity-increases-faq). - -{% include posts/capability-increases-sigs.md %} - ---- - -Signatures may be added to bitcoincore.org pull request [#53](https://github.com/bitcoin-core/website/issues/53) - -[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html diff --git a/_posts/en/posts/2015-12-23-capacity-increases-faq.md b/_posts/en/posts/2015-12-23-capacity-increases-faq.md deleted file mode 100644 index e2979de1a..000000000 --- a/_posts/en/posts/2015-12-23-capacity-increases-faq.md +++ /dev/null @@ -1,199 +0,0 @@ ---- -type: posts -layout: post -lang: en -name: bitcoin-core-capacity-increases-faq -id: en-bitcoin-core-capacity-increases-faq -title: Bitcoin Capacity Increases FAQ -permalink: /en/2015/12/23/capacity-increases-faq/ -version: 1 ---- -{% include toc.html %} - -## 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 |delivered| -| Feb 2016 | 0.12.0 | [libsecp256k1 verification][] |delivered| -| Feb 2016 | | Segregated witness feature complete & ready for general review |delivered| -| Mar 2016 | 0.12.1 | Deploy OP_CHECKSEQUENCEVERIFY (BIPs [68][BIP68] & [112][BIP112]) + [BIP113][] as first [BIP9][] versionbits soft fork |delivered| -| | | [Segregated witness pull request](https://github.com/bitcoin/bitcoin/pull/7910) | delivered| -| Oct 2016 | 0.13.1 | Deploy segregated witness (including block size increase) |delivered| -| 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][BIP112]:** 25,000% improvement in bi-directional [payment channel efficiency][] by allowing users to keep channels open as long as they want. - -- **[VersionBits][BIP9]:** 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][bip-segwit]:** 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. {#segwit-size} - -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. - -[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 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? {#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 (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][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 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? {#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 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. {#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 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? {#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 (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-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 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. - -[#bitcoin-dev]: https://webchat.freenode.net/?channels=bitcoin-dev&uio=d4 -[actively studied]: http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/ -[bip-segwit]: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki -[BIP9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki -[BIP16]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki -[BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.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]: https://bitcoin.org/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]: https://github.com/bitcoin/secp256k1 -[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 -[weak blocks and iblts]: https://www.youtube.com/watch?v=ivgxcEOyWNs&t=1h40m20s -[q simple raise]: #size-bump diff --git a/assets/images/ok-48.png b/assets/images/ok-48.png deleted file mode 100644 index 80f0fb268173a6d74afaf54a07b95268920d3dbe..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 1301 zcmV+w1?u{VP)l7-lS8^vnRZ+MJa#>8$6;AP2?MmiUpKmt8jhpl4uXM-9o$aF%sYu%eugM{rJcVf_TIM!(Kkn?}fl zd^c4W{;NXCd=aB8>8Mx{C;f)A#i5;v<5(^^OzjTb>c0{GHKE%tQYeg=j|ZjDl9)i! zi(6(##%bAuXYmQ1#9hLH&BQuf1YKpzvjNWwSKcWO;9kiWHKoZl_|Wv~G%jMMZJF4T zwOWrV8(~r`*q1qVi_PryyKx12GI4lT7UN!oIF(vw+j_ z6*f!8Yf8fkJ}-8l2#c^H6H#Un^VJSUM5z2jO=(z^esMS(VO56ZZ4s>)19(?*qOSZx zY!a8IMp#-=p-wQ2hb6~rN|SDJ%j;`m%*7ezwJzI?jN%E&XiaHCsLu6GjypFq`*F_+ zyel#f^{l|dTCjl4cAOAi^b*`>dhhu;o|YV|DGl%cm=?qKO5&*zCd6uPlpMegVY^3i z+Kvn159QSLiz{PG{wEW8nMN2AZhROd6Cw?=#nef>iQQ91NEVgbw|f4@GR1MkZtGMwS-20N|52B~iKVnQF_Q4!;8$4_-_x^bI= zIiCUyWg^)+K2ysodc@&dKcyyCdlzoUCpnq5Wn!1w74`1xk}MII_%#i7K2a8Cr&Qn^ z#g2WXeXD;MH)JBky`P3N!>0)kdYfeKv@Ijnxm){$CuBaF;dhbZJ~n;(Tzc_@x{G!W zYp}72@lVFMka=W|L6rQ8t8iWugU!QrN`6-Iy+ME0)F$VPYvbjuNLNM3laSuu@jGf2FViGl8aHsk>y)k-)gS-Eql4K1YQ0#_Pl;hZ5@h|nM#eTf1 zbu+g|IJ|2_wy#}`<1xv$NzK9Cy43&OdbY8(=G z=9=VJ{tHc{*WY()q}Pdsy;GWcr^tUF81zfow64l+zar&7F%@~_>l2TB%XIdU@1S_A7-;U1uR^HPUYv;wa7H^MoQ5%xe%T_~ou@X{ z6ur(J5ZA_;?!T=vTK>)^d|ISKGrt-vz#X_*sMY`ASA%*I!o;ois8J%mq+u%+^| z$AFIg>`_hpZZluRL5sz8^J4MR(<7cpGZ6xeh=cj9P|0C!_}%7jIM*W Date: Mon, 17 Jan 2022 13:29:40 +0100 Subject: [PATCH 2/2] Remove translations --- _data/navigation.yml | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/_data/navigation.yml b/_data/navigation.yml index 0b1bcb333..817efc648 100644 --- a/_data/navigation.yml +++ b/_data/navigation.yml @@ -19,9 +19,6 @@ en: title: "FAQs" submenu: true tree: - capacity-faq: - title: "Capacity Increases" - url: "/en/2015/12/23/capacity-increases-faq/" segwit-faq: title: "Segwit" url: "/en/2016/01/26/segwit-benefits/" @@ -86,9 +83,6 @@ zh_CN: title: "常见问题" submenu: true tree: - capacity-faq: - title: "容量增长" - url: "/zh_CN/2015/12/21/系统扩展常见问题解答/" segwit-faq: title: "隔离见证" url: "/zh_CN/2016/01/26/segwit-benefits/" @@ -153,9 +147,6 @@ zh_TW: title: "FAQs" submenu: true tree: - capacity-faq: - title: "Capacity Increases" - url: "/zh_TW/2015/12/21/系統擴展常見問題解答/" segwit-faq: title: "Segwit" url: "/en/2016/01/26/segwit-benefits/" @@ -220,9 +211,6 @@ ja: title: "FAQ" submenu: true tree: - capacity-faq: - title: "キャパシティの増加" - url: "/en/2015/12/23/capacity-increases-faq/" segwit-faq: title: "Segwit" url: "/ja/2016/01/26/segwit-benefits/" @@ -290,9 +278,6 @@ es: title: "FAQs" submenu: true tree: - capacity-faq: - title: "Capacity Increases" # XXX - url: "/en/2015/12/23/capacity-increases-faq/" # XXX segwit-faq: title: "Segwit" url: "/en/2016/01/26/segwit-benefits/" # XXX