Will BinnsTranslation coordination
+Will BinnsTranslation coordination
Ar ViccoRussian
Simon Alexander HinterreiterGerman
Jacob BurenstamSwedish
diff --git a/_templates/choose-your-wallet.html b/_templates/choose-your-wallet.html index 8e67901c..bdc88c78 100755 --- a/_templates/choose-your-wallet.html +++ b/_templates/choose-your-wallet.html @@ -445,6 +445,29 @@ wallets: privacyaddressreuse: "checkfailprivacyaddressrotation" privacydisclosure: "checkfailprivacydisclosurespv" privacynetwork: "checkfailprivacynetworknosupporttor" +- greenbits: + title: "GreenBits" + titleshort: "GreenBits" + compat: "mobile android" + level: 2 + platform: + mobile: + text: "walletgreenbits" + link: "https://play.google.com/store/apps/details?id=com.greenaddress.greenbits_android_wallet" + source: "https://github.com/greenaddress/GreenBits" + screenshot: "greenbits.png" + os: + - android + check: + control: "checkpasscontrolmulti" + validation: "checkpassvalidationspvp2p" + transparency: "checkpasstransparencyopensource" + environment: "checkpassenvironmenttwofactor" + privacy: "checkpassprivacybasic" + privacycheck: + privacyaddressreuse: "checkpassprivacyaddressrotation" + privacydisclosure: "checkfailprivacydisclosureaccount" + privacynetwork: "checkfailprivacynetworknosupporttor" - mycelium: title: "Mycelium" titleshort: "Mycelium" diff --git a/_translations/en.yml b/_translations/en.yml index e64e8349..0c628b6a 100644 --- a/_translations/en.yml +++ b/_translations/en.yml @@ -190,6 +190,7 @@ en: walletninki: "An advanced wallet for experienced Bitcoin users. Ninki is a multi-signature wallet with a beautiful user interface. You have full control of your bitcoins at all times." walletbither: "Bither is a simple and secure wallet on many platforms. With special designed Cold/Hot modes, user can easily get both safety and simplicity. Bither's XRANDOM uses different entropy sources to generate true random number for users. Also with HDM, users can have HD's advantages and Multisig's security." walletcoinapult: "Coinapult's wallet is designed with Bitcoin newcomers in mind. It allows sending bitcoins via email and SMS, and a handy tool called Locks helps protecting your balance from Bitcoin price swings. Users can Lock bitcoins to Gold, Euros, and more!" + walletgreenbits: "GreenBits is a fast and easy to use wallet. Enjoy improved security with a minimal/zero trust approach, optional hardware wallets support, multisignature based 2FA and spending limits functionality." walletcoinomi: "Coinomi is a lightweight, secure, open-source, universal, HD Wallet. Apart from Bitcoin it also supports many altcoins so you can keep all your funds in a single wallet. Your private keys never leave your device and you only need to back it up just once!" walletdownload: "Install" walletvisit: "Visit website" diff --git a/en/bitcoin-core/capacity-increases-faq.md b/en/bitcoin-core/capacity-increases-faq.md new file mode 100644 index 00000000..0e6330e5 --- /dev/null +++ b/en/bitcoin-core/capacity-increases-faq.md @@ -0,0 +1,369 @@ +--- +# 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][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 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 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 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 makes it uncommon 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 +[actively studied]: http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/ +[bip-segwit]: https://github.com/jl2012/bips/blob/segwit/bip-segwit.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]: /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/en/bitcoin-core/capacity-increases.md b/en/bitcoin-core/capacity-increases.md new file mode 100644 index 00000000..6e4fa2f6 --- /dev/null +++ b/en/bitcoin-core/capacity-increases.md @@ -0,0 +1,36 @@ +--- +# 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 +columns: 1 +title: Capacity increases for the Bitcoin system -- Bitcoin Core +breadcrumbs: + - bitcoin + - bcc + - Capacity increases +--- +# Capacity increases for the Bitcoin system + +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/bitcoin-core/capacity-increases-faq). + +{% include bitcoin-core/capability-increases-sigs.md %} + +--- + +Other versions of this page: + +- [简体中文](/zh_CN/bitcoin-core/capacity-increases) +- [繁體中文](/zh_TW/bitcoin-core/capacity-increases) + +Signatures may be added to Bitcoin.org pull request [#1165](https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165) + +[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html diff --git a/en/bitcoin-core/index.md b/en/bitcoin-core/index.md index 82c41671..c72f859f 100644 --- a/en/bitcoin-core/index.md +++ b/en/bitcoin-core/index.md @@ -91,6 +91,7 @@ breadcrumbs: {% endcapture %} {% assign array_releases = text_releases | strip_newlines | split: '::' %} + - 2015-12-21 - Capacity increases for the Bitcoin system: [Statement](/en/bitcoin-core/capacity-increases) & [FAQ](/en/bitcoin-core/capacity-increases-faq) {% comment %}{% endcomment %} {% for release in array_releases %} {% if forloop.index <= 3 %} diff --git a/en/full-node.md b/en/full-node.md index 9d988d23..f30e1973 100644 --- a/en/full-node.md +++ b/en/full-node.md @@ -1396,5 +1396,93 @@ ask for help on sites like [SuperUser](http://superuser.com). We can't provide direct support, but if you see a way to improve these instructions, please [open an issue.](https://github.com/bitcoin-dot-org/bitcoin.org/issues/new) +## Configuration Tuning + +This section contains advice about how to change your Bitcoin Core +configuration to adapt it to your needs. + +There are two ways to change your configuration. The first is to start +Bitcoin Core with the options you want. For example, if you want to +limit it to using one CPU core for signature verification, you can start +Bitcoin Core like this: + +{% highlight bash %} +## Bitcoin Core daemon +bitcoind -par=1 -daemon + +## Bitcoin Core GUI +bitcoin-qt -par=1 +{% endhighlight %} + +Once you've decided you like an option, you can add it to the Bitcoin +Core configuration file. You can find that file in the following +directories: + +- Windows: %APPDATA%\Bitcoin\ + +- OSX: $HOME/Library/Application Support/Bitcoin/ + +- Linux: $HOME/.bitcoin/ + +To add an option to the configuration file, just remove its leading +dash. You may also need to remove any quotation marks you used in your shell. +For example, the `-par` option seen above would look like this in the +configuration file: + +{% highlight text %} +par=1 +{% endhighlight %} + +If you have any questions about configuring Bitcoin Core, please stop by +one of our [forums](/en/bitcoin-core/help#forums) or [live +chatrooms](/en/bitcoin-core/help#live). + +### Reduce Traffic + +Some node operators need to deal with bandwith caps imposed by their ISPs. + +By default, bitcoin-core allows up to 125 connections to different peers, 8 of +which are outbound. You can therefore, have at most 117 inbound connections. + +The default settings can result in relatively significant traffic consumption. + +Ways to reduce traffic: + +#### Maximum Upload Targets + +{% highlight text %} +-maxuploadtarget=