joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-27 01:36:13 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Remove Bitcoin Core stuff

Browse source
This commit is contained in:
thephez 2018-01-04 16:00:52 -05:00
parent a865e21b2b
commit c45c79ec53
44 changed files with 2 additions and 5675 deletions
Download patch file Download diff file Expand all files Collapse all files

30
_autocrossref.yaml
View file

@ -507,31 +507,5 @@ CVE-2012-2459:
'`walletpassphrasechange` RPC': rpc walletpassphrasechange '`walletpassphrasechange` RPC': rpc walletpassphrasechange
## Versions of Bitcoin Core (linked to Bitcoin.org release notes) ## Versions of Bitcoin Core (linked to Bitcoin.org release notes)
Bitcoin Core 0.1.6: #Bitcoin Core 0.14.2:
Bitcoin Core 0.2.9: #Bitcoin Core master:
Bitcoin Core 0.3.11:
Bitcoin Core 0.3.15:
Bitcoin Core 0.3.18:
Bitcoin Core 0.6.0:
Bitcoin Core 0.6.1:
Bitcoin Core 0.7.0:
Bitcoin Core 0.8.0:
Bitcoin Core 0.9.0:
Bitcoin Core 0.9.1:
Bitcoin Core 0.9.3:
Bitcoin Core 0.10.0:
Bitcoin Core 0.10.1:
Bitcoin Core 0.10.2:
Bitcoin Core 0.10.3:
Bitcoin Core 0.11.0:
Bitcoin Core 0.11.1:
Bitcoin Core 0.11.2:
Bitcoin Core 0.12.0:
Bitcoin Core 0.12.1:
Bitcoin Core 0.13.0:
Bitcoin Core 0.13.1:
Bitcoin Core 0.13.2:
Bitcoin Core 0.14.0:
Bitcoin Core 0.14.1:
Bitcoin Core 0.14.2:
Bitcoin Core master:

27
_includes/bitcoin-core/bitcoin-core-possible-problems.md
View file

@ -1,27 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
{% endcomment %}
- **Legal:** Bitcoin use is [prohibited or restricted in some
areas.](https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country)
- **Bandwidth limits**: Some Internet plans will charge an additional
amount for any excess upload bandwidth used that isn't included in
the plan. Worse, some providers may terminate your connection without
warning because of overuse. We advise that you check whether your
Internet connection is subjected to such limitations and monitor your
bandwidth use so that you can stop Bitcoin Core before you reach your
upload limit.
- **Anti-virus:** Several people have placed parts of known computer
viruses in the Bitcoin block chain. This block chain data can't infect
your computer, but some anti-virus programs quarantine the data
anyway, making it more difficult to run Bitcoin Core. This problem mostly
affects computers running Windows.
- **Attack target:** Bitcoin Core powers the Bitcoin peer-to-peer
network, so people who want to disrupt the network may
attack Bitcoin Core users in ways that will affect other things
you do with your computer, such as an attack that limits your
available download bandwidth.

59
_includes/bitcoin-core/capability-increases-sigs.md
View file

@ -1,59 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
{% endcomment %}
- [Adam Back](https://github.com/adam3us)
- [Alex Morcos](https://github.com/morcos)
- [Aaron Voisine](https://github.com/voisine)
- [Ben Davenport](https://github.com/bpdavenport)
- [Ben Gorlick](https://github.com/bgorlick)
- [Bram Cohen](https://github.com/bramcohen)
- [Bryan Bishop](https://github.com/kanzure)
- [BtcDrak](https://github.com/btcdrak)
- [Charlie Lee](https://github.com/coblee)
- [Christian Decker](https://github.com/cdecker)
- [Cøbra](https://github.com/cobra-bitcoin)
- [Cory Fields](https://github.com/theuni)
- [Craig Watkins](https://github.com/crwatkins)
- [Daniel](https://github.com/arowser)
- [Daniel Kraft](https://github.com/domob1812)
- [David A. Harding](https://github.com/harding)
- [David Vorick](https://github.com/DavidVorick)
- [Dev Random](https://github.com/devrandom)
- [DexX7](https://github.com/dexX7)
- [Douglas Huff](https://github.com/jrmithdobbs)
- [Eric Lombrozo](https://github.com/CodeShark)
- [Glenn H Tarbox](https://github.com/ghtdak)
- [Gregory Maxwell](https://github.com/gmaxwell)
- [Gregory Sanders](https://github.com/instagibbs)
- [James Hilliard](https://github.com/jameshilliard)
- [Johnathan Corgan](https://github.com/jmcorgan)
- [Johnson Lau](https://github.com/jl2012)
- [Jonas Schnelli](https://github.com/jonasschnelli)
- [Jouke Hofman](https://github.com/Joukehofman)
- [Lawrence Nahum](https://github.com/greenaddress)
- [Luke Dashjr](https://github.com/luke-jr)
- [Mark Friedenbach](https://github.com/maaku)
- [Eric Martindale](https://github.com/martindale)
- [Manuel Aráoz](https://github.com/maraoz)
- [Marco Falke](https://github.com/MarcoFalke)
- [Matt Corallo](https://github.com/TheBlueMatt)
- [Midnight Magic](https://github.com/midnightmagic)
- [Michael Ford](https://github.com/fanquake)
- [Nicolas Bacca](https://github.com/btchip)
- [Nicolas Dorier](https://github.com/NicolasDorier)
- [Obi Nwosu](https://github.com/obi)
- [Patrick Strateman](https://github.com/pstratem)
- [Pavel Janik](https://github.com/paveljanik)
- [Peter Todd](https://github.com/petertodd)
- [Pieter Wuille](https://github.com/sipa)
- [Randy Waterhouse](https://github.com/randy-waterhouse)
- [Rodolfo Novak](https://github.com/nvk)
- [Ruben de Vries](https://github.com/rubensayshi)
- [Suhas Daftuar](https://github.com/sdaftuar)
- [Theymos](https://github.com/theymos)
- [Thomas Kerin](https://github.com/afk11)
- [Wang Chun](https://github.com/wangchun)
- [Warren Togami](https://github.com/wtogami)
- [Wladimir J. van der Laan](https://github.com/laanwj)

12
_includes/bitcoin-core/download-bitcoin-core.html
View file

@ -1,12 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
{% endcomment %}
<div class="callout">
<p><a href="/{{page.lang}}/{% translate download url %}">Download Bitcoin Core</a>
<img src="/img/os/windows.png" alt="Windows">
<img src="/img/os/mac.png" alt="Mac">
<img src="/img/os/linux.png" alt="Linux">
</p>
</div>

10
_includes/layout/base-core/content.html
View file

@ -1,10 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
{% endcomment %}
<div id="content" class="content">
<div {% if page.columns == 1 and page.lang == 'en' %}class="one-column"{% endif %}>
{{ content }}
</div>
</div>

9
_includes/layout/base-core/footer-js-extra.html
View file

@ -1,9 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
{% endcomment %}
{% comment %}<!-- Try to minimize the amount of JS on the download page -->{% endcomment %}
{% if page.id != 'download' %}
<script src="/js/bitcoin-core.js"></script>
{% endif %}

10
_includes/layout/base-core/footer-license.html
View file

@ -1,10 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
{% endcomment %}
<div class="footerlicense">© Bitcoin Project 2009-{{ site.time | date: '%Y' }} {% translate footer layout %}<br>
Bitcoin Core pages on Bitcoin.org are <a
href="/en/bitcoin-core/about-site">maintained separately</a> from the
rest of the site.
</div>

20
_includes/layout/base-core/footer-menu.html
View file

@ -1,20 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
{% endcomment %}
<div>
<p>Bitcoin.org is community supported: <a href="bitcoin:1GwV7fPX97hmavc6iNrUZUogmjpLPrPFoE" target="_blank">1GwV7fPX97hmavc6iNrUZUogmjpLPrPFoE</a></p>
</div>
<div class="footermenu">
<a href="/en/alerts" class="statusmenu{% if site.STATUS == 1 %} alert{% endif %}">Network Status</a>
<a href="/{{ page.lang }}/{% translate legal url %}">{% translate menu-legal layout %}</a>
{% case page.lang %}
{% when 'id' or 'da' or 'de' or 'es' or 'fr' or 'it' or 'hu' or 'nl' or 'pl' or 'pt_BR' or 'ro' or 'sl' or 'sv' or 'tr' or 'el' or 'bg' or 'ru' or 'uk' or 'ar' or 'fa' or 'hi' or 'ko' or 'ja' or 'zh_CN' or 'zh_TW' %}
<a href="/en/privacy">Privacy Policy</a>
{% else %}
<a href="/{{ page.lang }}/{% translate privacy url %}">{% translate menu-privacy layout %}</a>
{% endcase %}
<a href="/en/bitcoin-core/about-site">About</a>
</div>

6
_includes/layout/base-core/head-logo.html
View file

@ -1,6 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
{% endcomment %}
<a class="logo" href="/en/bitcoin-core/"><img src="/img/bitcoin-core/bitcoin-core.svg" alt="Bitcoin"></a>

29
_includes/layout/base-core/head-menu.html
View file

@ -1,29 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
{% endcomment %}
<ul id="menusimple" class="menusimple menucore" onclick="mobileMenuHover(event);" ontouchstart="mobileMenuHover(event);">
<li><a>Features</a>
<ul>
<li{% if page.id == 'bitcoin-core-feature-overview' %} class="active"{% endif %}><a href="/en/bitcoin-core/features/">Overview</a></li>
<li{% if page.id == 'bitcoin-core-validation' %} class="active"{% endif %}><a href="/en/bitcoin-core/features/validation">Validation</a></li>
<li{% if page.id == 'bitcoin-core-privacy' %} class="active"{% endif %}><a href="/en/bitcoin-core/features/privacy">Privacy</a></li>
<li{% if page.id == 'bitcoin-core-requirements' %} class="active"{% endif %}><a href="/en/bitcoin-core/features/requirements">Requirements</a></li>
<li{% if page.id == 'bitcoin-core-user-interface' %} class="active"{% endif %}><a href="/en/bitcoin-core/features/user-interface">User Interface</a></li>
<li{% if page.id == 'bitcoin-core-donate-bandwidth' %} class="active"{% endif %}><a href="/en/bitcoin-core/features/network-support">Network Support</a></li>
</ul>
</li>
<li{% if page.id == 'bitcoin-core-help' %} class="active"{% endif %}><a href="/en/bitcoin-core/help">Get Help</a></li>
<li{% if page.id == 'bitcoin-core-contribute' %} class="active"{% endif %}><a>Contribute</a>
<ul>
<li{% if page.id == 'bitcoin-core-contribute-issues' %} class="active"{% endif %}><a href="/en/bitcoin-core/contribute/issues">Bug reports</a></li>
<li{% if page.id == 'development' %} class="active"{% endif %}><a href="/{{page.lang}}/{% translate development url %}">Code</a></li>
<li{% if page.id == 'bitcoin-core-contribute-documentation' %} class="active"{% endif %}><a href="/en/bitcoin-core/contribute/documentation">Documentation</a></li>
<li{% if page.id == 'bitcoin-core-contribute-translations' %} class="active"{% endif %}><a href="/en/bitcoin-core/contribute/translations">Translations</a></li>
<li{% if page.id == 'bitcoin-core-contribute-tech-support' %} class="active"{% endif %}><a href="/en/bitcoin-core/contribute/support">Tech Support</a></li>
</ul>
</li>
<li{% if page.id == 'version-history' %} class="active"{% endif %}><a href="/en/version-history">News</a></li>
<li{% if page.id == 'download' %} class="active"{% endif %}><a href="/{{ page.lang }}/{% translate download url %}">Download</a></li>
</ul>

10
_includes/layout/base-core/html-head-extra.html
View file

@ -1,10 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
{% endcomment %}
{% comment %}<!-- try to minimize the amount of JS on the Download page -->{% endcomment %}
{% if page.id != 'download' %}
<script src="/js/jquery/jquery-1.11.2.min.js"></script>
<script src="/js/jquery/jquery-ui.min.js"></script>
{% endif %}

9
_includes/layout/base-core/html-head-jquery-css.html
View file

@ -1,9 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
<!-- this must come before the main style sheet so that our
definitions override the defaults -->
{% endcomment %}
<link rel="stylesheet" href="/css/jquery-ui.min.css">

10
_includes/layout/base-core/pagetop-moved-notice.html
View file

@ -1,10 +0,0 @@
{% comment %}
This file is licensed under the MIT License (MIT) available on
http://opensource.org/licenses/MIT.
{% endcomment %}
{% if page.moved_url %}
<div class="banner-message minor">
<a href="{{page.moved_url}}"><span>{% translate banner-core-moved layout %}</span></a>
</div>
{% endif %}

23
_includes/references.md
View file

@ -302,29 +302,6 @@ http://opensource.org/licenses/MIT.
[bcc validation protection]: /en/bitcoin-core/features/validation#how-validation-protects-your-bitcoins [bcc validation protection]: /en/bitcoin-core/features/validation#how-validation-protects-your-bitcoins
[bcc version history]: /en/version-history [bcc version history]: /en/version-history
[Bitcoin Core 0.6.0]: /en/release/v0.6.0
[Bitcoin Core 0.6.1]: /en/release/v0.6.1
[Bitcoin Core 0.7.0]: /en/release/v0.7.0
[Bitcoin Core 0.8.0]: /en/release/v0.8.0
[Bitcoin Core 0.9.0]: /en/release/v0.9.0
[Bitcoin Core 0.9.1]: /en/release/v0.9.1
[Bitcoin Core 0.9.2]: /en/release/v0.9.2
[Bitcoin Core 0.9.3]: /en/release/v0.9.3
[Bitcoin Core 0.10.0]: /en/release/v0.10.0
[Bitcoin Core 0.10.1]: /en/release/v0.10.1
[Bitcoin Core 0.10.2]: /en/release/v0.10.2
[Bitcoin Core 0.10.3]: /en/release/v0.10.3
[Bitcoin Core 0.11.0]: /en/release/v0.11.0
[Bitcoin Core 0.11.1]: /en/release/v0.11.1
[Bitcoin Core 0.11.2]: /en/release/v0.11.2
[Bitcoin Core 0.12.0]: /en/release/v0.12.0
[Bitcoin Core 0.12.1]: /en/release/v0.12.1
[Bitcoin Core 0.13.0]: /en/release/v0.13.0
[Bitcoin Core 0.13.1]: /en/release/v0.13.1
[Bitcoin Core 0.13.2]: /en/release/v0.13.2
[Bitcoin Core 0.14.0]: /en/release/v0.14.0
[Bitcoin Core 0.14.1]: /en/release/v0.14.1
[Bitcoin Core 0.14.2]: /en/release/v0.14.2
[bitcoin URI subsection]: /en/developer-guide#bitcoin-uri [bitcoin URI subsection]: /en/developer-guide#bitcoin-uri
[dashd initial setup]: /en/developer-examples [dashd initial setup]: /en/developer-examples
[bitcoinpdf]: https://bitcoin.org/en/bitcoin-paper [bitcoinpdf]: https://bitcoin.org/en/bitcoin-paper

53
_layouts/base-core.html
View file

@ -1,53 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
---
<!DOCTYPE HTML>
<html lang="{{ page.lang }}">
{% comment %}
<!-- on non-translated pages (e.g. Download page), use conditionals to
use the base template -->
{% endcomment %}
<head>
{% include layout/base-core/html-head-jquery-css.html %}
{% include layout/base/html-head.html %}
{% include layout/base-core/html-head-extra.html %}
</head>
<body>
{% include layout/base/pagetop-detect-mobile.html %}
{% include layout/base/pagetop-alert.html %}
{% include layout/base-core/pagetop-moved-notice.html %}
<div class="head"><div>
{% include layout/base/head-language-dropdown.html %}
{% include layout/base/head-mobile-menu.html %}
{% if page.lang == 'en' %}
{% include layout/base-core/head-logo.html %}
{% include layout/base/head-language-select.html %}
{% include layout/base-core/head-menu.html %}
{% else %}
{% include layout/base/head-logo.html %}
{% include layout/base/head-language-select.html %}
{% include layout/base/head-menu.html %}
{% endif %}
</div></div>
<div class="body">
{% if page.lang == 'en' %}
{% include layout/base/breadcrumbs.html %}
{% endif %}
{% include layout/base-core/content.html %}
<div class="footer">
{% include layout/base-core/footer-menu.html %}
{% include layout/base-core/footer-license.html %}
</div>
</div>
{% include layout/base-core/footer-js-extra.html %}
{% include layout/base/footer-js.html %}
</body>
</html>

37
de/bitcoin-core/2016-01-07-statement.md
View file

@ -1,37 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: de
id: bitcoin-core-2016-01-07-statement
columns: 1
title: Stellungnahme der Bitcoin Core Entwickler -- 2016-01-07
breadcrumbs:
- bitcoin
- bcc
- 2016-01-07 Statement
moved_url: https://bitcoincore.org/de/2016/01/07/stellungnahme-der-bitcoin-core-entwickler/
---
# Stellungnahme der Bitcoin Core Entwickler 2016-01-07
Bitcoin ist eine peer-to-peer Version von digitalem Geld, welche ermöglicht Zahlungen auf dem direkten Weg zwischen zwei Teilnehmern zu veranlassen, ohne dabei durch einen zentralen Finanzdienstleister verarbeitet zu werden. Unsere Vorstellung von Bitcoin ist es auch bei extremer Auslastung effizient zu arbeiten, aber dennoch Sicherheit und die grundlegenden Eigenschaften der Dezentralisierung, welche Bitcoin einzigartig machen, zu erhalten.
Wir glauben dass Bitcoin dies erreichen kann, indem die Fundamente für weitere Schichten über dem Protokoll und Schnittstellen angeboten werden. Weiterhin ist unser Ziel die Privatsphäre der Bitcoin-Nutzer zu verteidigen und zu verbessern.
"Bitcoin Core" ist der Name des Open Source Software Projekts welches der direkte Nachfolger der originalen Bitcoin-Implementierung ist. Als Teilnehmer des Projekts entwickeln und veröffentlichen wir Software für die Bitcoin Community. Wir streben an das Konsensus-Protokoll von Bitcoin zu verbessern indem wir Upgrades vorschlagen die in unseren Augen sowohl technisch und im Hinblick auf die Ziele von Bitcoin Sinn machen, als auch vernüftige Wahrscheinlichkeit haben umfassende Unterstützung und Annahme zu erhalten.
Änderungen and den Bitcoin Konsensus-Regeln können entweder durch einen “soft fork” oder “hard fork” gemacht werden (siehe Anhang A). Soft forks erlauben Änderungen ohne Kompatibiliät zu brechen. Alte und neue Versionen der Software können im Netzwerk koexistieren. Soft forks können neue Funktionen einführen ohne Unterbrechung zu verursachen, weil Benutzer der neuen Funktion ein Upgrade durchführen können, während Nutzer, welche die neue Funktion nicht benötigen, keine Aktion durchführen müssen.
Hard forks verursachen Inkompatibilität zu allen frühreren Bitcoin-Softwareversionen und verlangen daher von jedem Teilnehmer ein Upgrade auf die neuen Konsensus-Regeln bis zu einer festgelegten Frist, um finanzielle Verluste zu vermeiden. Hard forks können auch die Nutzen aus Netzwerkeffekten stark dämmen, da einerseits Teilnehmer, die nicht auf den hard fork reagieren, andererseits auch Drittsoftware und Anwendungen vom Netzwerk abgestoßen werden.
Aus diesen Gründen bevorzugt Bitcoin Core Kompatibilität und glaubt dass jeder Nutzer selbst entscheiden kann wann und ob er seine Bitcoin-Software aktualisiert. Es stellte sich heraus, dass es möglich ist nahezu beliebige Funktionen mit einem soft fork hinzuzufügen. Gelegentlich können hard forks Vorteile haben und wenn nahezu universale Übereinstimmung herrscht, könnten diese Vorteile die Nachteile überwiegen. Abgesehen von diesen seltenen Fällen, sollten soft forks vorgezogen werden. Wir glauben, dass dies im besten Interesse der jetzigen und zukünftigen Nutzer des Systems ist.
Wir glauben auch, dass die Anzahl der Implementierungen des Bitcoin-Protokolls mit dem Wachstum des Bitcoin-Netzwerks zunimmt. Auch ist es unvermeidbar dass andere Softwareprojekte radikal abweichende Vorschläge veröffentlichen. Letztendlich entscheidet nicht das Bitcoin Core Entwicklerteam über die Bitcoin Konsensus-Regeln, sondern die Nutzer, die ihre eigenen Entscheidungen treffen welche Bitcoin-Software sie benutzen. Aus diesem Grund hat die Bitcoin Implementierung des Bitcoin Core Entwicklerteams absichtlich keine auto-update Funktion. Der Verzicht sichert ab, dass jedes Upgrade aufgrund der Freiwilligkeit des Benutzers geschieht und dem Nutzer die Wahl über die Software gelassen wird.
### Anhang A
Ein *hard fork* ist eine Änderung der Konsensus-Regeln, sodass Blöcke die unter alten Regeln ungültig sind unter neuen Regeln gültig werden könnten.
Ein *soft fork* ist eine Änderung der Konsensus-Regeln, sodass Blöcke die unter alten Regeln gültig sind, unter den neuen Regeln ungültig werden könnten. Jedoch bleiben alle Blöcke, die unter alten Regeln ungültig sind auch unter den neuen Regeln ungültig.

44
en/bitcoin-core/2016-01-07-statement.md
View file

@ -1,44 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: en
id: bitcoin-core-2016-01-07-statement
columns: 1
title: Statement from Bitcoin Core -- 2016-01-07
breadcrumbs:
- bitcoin
- bcc
- 2016-01-07 Statement
moved_url: https://bitcoincore.org/en/2016/01/07/statement
---
# Statement from Bitcoin Core 2016-01-07
Bitcoin is a "peer-to-peer version of electronic cash that allows online payments to be sent directly from one party to another without going through a financial institution". Our vision for Bitcoin is to expand the flexibility of the system to work efficiently at extremely high scale, while at the same time maintaining security and the core properties of decentralization that make Bitcoin unique.
We believe Bitcoin can accomplish this by providing the foundation for additional layers on top of the protocol and interfaces with other systems. Furthermore, our long term goals include protecting and improving the privacy of Bitcoin users.
"Bitcoin Core" refers to an open source software project that is a direct descendant of the original Bitcoin implementation. As project contributors, we maintain and release software for the Bitcoin community for users' consideration. We strive to make improvements to the consensus protocol by proposing upgrades that we believe make technical sense according to our understanding of the goals of Bitcoin, and that we believe stand a reasonable chance of widespread support and adoption.
Changes to the Bitcoin consensus rules can be made through either soft forks or hard forks (see Appendix A). Soft forks allow compatible changes. With soft forks, old and new software can co-exist on the network. Soft forks can introduce new features without disruption because users who want to use the new features can upgrade, while those who do not are free to continue as normal.
Hard forks break compatibility of all previous Bitcoin software and require every participant to upgrade to the same rules by a deadline or risk losing money. Such events can also harm network effects by pushing participants off the network if they take no action, and by potentially breaking downstream software and applications.
For these reasons, Bitcoin Core strongly favours compatibility and believes it should be each user’s choice not to upgrade the rules of their current Bitcoin software. It turns out it is possible to add almost any new feature with a soft fork. Occasionally, hard forks may have some benefits, and if there is near-universal agreement, these benefits may outweigh the downsides. Except for these rare cases, soft forks are to be preferred. We believe this is in the best interests of current and future users of the system.
We also expect that as the Bitcoin ecosystem grows, the number of alternative Bitcoin protocol implementations may increase, and it is inevitable that other software projects may release radically different software proposals for the ecosystem to consider. At the end of the day, the Bitcoin Core development team does not decide the Bitcoin consensus rules. Instead, users participate in Bitcoin by making their own choice of which Bitcoin software to run. This is why Bitcoin Core software deliberately does not have an auto-update feature. Its omission ensures voluntary user participation in every upgrade, so users always retain the choice over which software they run.
### Appendix A
A hard fork is a change to consensus rules, in which blocks that would have been invalid under the old rules may become valid under the new rules.
A soft fork is a change to consensus rules, in which blocks that would have been valid under the old rules may become invalid under the new rules, but all blocks that would have been invalid under the old rules remain invalid under the new rules.
Translations:
[{{site.langs.de}}](/de/bitcoin-core/2016-01-07-statement)
| [{{site.langs.es}}](/es/bitcoin-core/2016-01-07-statement)
| [{{site.langs.ru}}](/ru/bitcoin-core/2016-01-07-statement)
| [{{site.langs.zh_CN}}](/zh_CN/bitcoin-core/2016-01-07-statement)
| [{{site.langs.zh_TW}}](/zh_TW/bitcoin-core/2016-01-07-statement)

51
en/bitcoin-core/about-site.md
View file

@ -1,51 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: en
id: bitcoin-core-about-site
columns: 1
title: About Site - Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- About site
---
# About the Bitcoin Core pages on Bitcoin.org
Bitcoin.org hosts several pages about Bitcoin Core as well as the
[Bitcoin Core downloads][bcc download], but the Bitcoin.org and Bitcoin
Core open source projects are run by separate teams.
## History
Bitcoin.org was originally used by [Satoshi Nakamoto][] to host his
[Bitcoin paper][bitcoinpdf]. Soon after, it began linking to
downloadable versions of the original Bitcoin software, making it the
homepage for the Bitcoin program.
New educational content about Bitcoin was added to Bitcoin.org over
time, but that home page remained even when the name of the original
program was changed to Bitcoin Core.
In the years since, the amount of content on Bitcoin.org has continued
to increase. There's more content about Bitcoin Core than ever before
and also more content about other Bitcoin software and resources.
## Separation of concerns
As of Dec 2015, Bitcoin.org has 876 pages in 25 different languages,
but fewer than 100 of those pages belong to Bitcoin Core. The Bitcoin
Core project has no control over those non-Core pages or any polices
enacted on them.
Likewise, content provided through the Bitcoin Core pages is not
necessarily endorsed or supported by the Bitcoin.org contributors.
## Maintenance
Pull requests and issues directly relating to Bitcoin Core are tagged as
*[Core][core github tag]* in the Bitcoin.org repository.
{% include references.md %}

384
en/bitcoin-core/capacity-increases-faq.md
View file

@ -1,384 +0,0 @@
---
# 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
moved_url: https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
---
# Capacity increases FAQ
Other versions: [Italiano](/it/bitcoin-core/capacity-increases-faq) \| [简体中文](/zh_CN/bitcoin-core/capacity-increases-faq) \| [繁體中文](/zh_TW/bitcoin-core/capacity-increases-faq)
1. toc
{:toc}
## What is the roadmap? {#roadmap}
**[Capacity increases for the Bitcoin system][roadmap]**, written by Gregory
Maxwell and published 7 Dec 2015 to the bitcoin-dev mailing list. A
[statement][] supporting the roadmap has been signed by developers who
([according to GitHub][commit stats]) generated more than [90% of all
commits][commit spreadsheet] to Bitcoin Core in 2015.
## 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 | Segregated witness deployment including [block size increase](#segwit-size) |
| 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&amp;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]: /en/bitcoin-core/
[Bitcoin relay network]: http://bitcoinrelaynetwork.org/
[code review]: https://bitcoin.org/en/development#code-review
[commit spreadsheet]: https://docs.google.com/spreadsheets/d/15jtxuA3dVY5NUuYezZ4d_69ASUMYjqFOMxsF9ZX-BKA/edit?usp=sharing
[commit stats]: https://github.com/bitcoin/bitcoin/graphs/contributors?from=2015-01-01&to=2015-12-31&type=c
[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
[statement]: /en/bitcoin-core/capacity-increases
[weak blocks and iblts]: https://www.youtube.com/watch?v=ivgxcEOyWNs&t=1h40m20s
[q simple raise]: #size-bump

38
en/bitcoin-core/capacity-increases.md
View file

@ -1,38 +0,0 @@
---
# 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
moved_url: https://bitcoincore.org/en/2015/12/21/capacity-increase
---
# 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:
- [Italiano](/it/bitcoin-core/capacity-increases)
- [简体中文](/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

119
en/bitcoin-core/contribute/documentation.md
View file

@ -1,119 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
id: bitcoin-core-contribute-documentation
lang: en
layout: base-core
columns: 1
title: Documentation - Contribute to Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- bcc contribute
- Documentation
---
# Writing Bitcoin Core Documentation
Bitcoin Core documentation is spread across three projects: Bitcoin
Core, the Bitcoin Wiki, and Bitcoin.org---and is further subdivided into
different parts. The sections below briefly describe what documentation
is available and how you can contribute.
## Bitcoin Core Docs Directory
The [docs directory][bitcoin core docs directory]
contains various files describing aspects of Bitcoin Core. Almost all of
the files are meant for developers and testers rather than users, although
some (such as the build instructions) may be used by power users.
The files are all written in Markdown, which can be easily edited in
GitHub's web interface:
1. Create a GitHub account, or if you already have one, log in.
2. Find the file you want to edit. For example, [build-unix.md][bitcoin
core build unix]
3. Click the Edit icon (a pencil).
4. Make your change and click the Preview button to preview it. Revise
and edit until you're happy with it.
5. At the bottom of the page, fill out the Propose File Change form and
submit it.
*Need help getting started? Stop by the [#bitcoin-dev][] IRC chatroom
and tell us what documentation you want to write.*
## Bitcoin.org Bandwidth Sharing Guide
The [Bitcoin.org bandwidth sharing guide][bandwidth sharing guide]
currently provides instructions for how to install Bitcoin Core on
multiple operating systems, configure it to automatically start at boot,
and manually open port 8333 so it accepts incoming connections.
To contribute, you can [edit the guide][edit bandwidth sharing
guide] using the same GitHub web interface as described in the
previous section.
*Need help getting started? You can [open an issue][] or email Bitcoin.org
documentation maintainer {{site.text.bitcoin_org_docs_maintainer_email_link}}.*
## Bitcoin Wiki
The Bitcoin Wiki uses the popular MediaWiki software, so you may already
know how to edit it and create new pages. To reduce spam, you need to
[create an account][wiki create account] and then follow the
[instructions to enable editing][wiki enable editing].
Current documentation can be found in the [Bitcoin Core documentation
category][wiki bitcoin core documentation]. If you create a new page,
be sure to add it to the [Bitcoin Core documentation template][wiki
template bitcoin core documentation] and then add the following code to
the very bottom of the page:
{% raw %}{{Bitcoin Core documentation}}{% endraw %}
Adding the line above to a page will also add that page to the Bitcoin
Core documentation category.
*Need help getting started? Stop by the [#bitcoin-wiki][] IRC chatroom and
tell us what documentation you want to write.*
## Bitcoin.org RPC/REST API Reference
The [Bitcoin.org developer reference][devref] contains over 100 printed
pages worth of documentation for the Bitcoin Core RPC and REST
interfaces, which are mainly used by Bitcoin Core command line users and
developers of apps depending on Bitcoin Core.
To contribute RPC edits, the easiest way is to:
1. Go to the [Bitcoin.org developer documentation main page][developer documentation].
2. Search for the RPC you want to edit.
3. Under the subheading for the RPC, click the Edit link.
To create new RPC/REST documentation or edit the REST documentation:
1. Follow [these instructions][open a pull request] to clone the Bitcoin.org repository.
2. RPC files are in the `_includes/ref/bitcoin-core/rpcs` directory.
REST files are in the `_includes/ref/bitcoin-core/rest` directory.
New files need to be added to the list in `en/developer-reference.md`
*Need help getting started? You can [open an issue][] or email
Bitcoin.org documentation maintainer {{site.text.bitcoin_org_docs_maintainer_email_link}}.*
<br class="clear big">
<div class="prevnext">
<span markdown="1">**Previous**<br>[Code][bcc contribute code]</span>
<span markdown="1">**Next**<br>[Translations][bcc contribute translations]</span>
</div>
<br class="clear">
{% include references.md %}

40
en/bitcoin-core/contribute/index.md
View file

@ -1,40 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: en
id: bitcoin-core-contribute
columns: 1
title: Contribute to Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- Contribute
---
# Contributing To Bitcoin Core
Thank you for considering contributing to Bitcoin Core! We have
instructions below to help you get started contributing in several different
ways.
If want to contribute in another way, please visit the [#bitcoin-dev][]
IRC chatroom and discuss your plan with a developer.
<div markdown="block" class="two-column-list">
{:.fa-ul}
- <span class="fa fa-li fa-bug fa-2x"></span> **[Bug reports][bcc contribute issues]**<br>Report bugs, including security issues
- <span class="fa fa-li fa-code fa-2x"></span> **[Code][bcc contribute code]**<br>Write & review code
- <span class="fa fa-li fa-book fa-2x"></span> **[Documentation][bcc contribute documentation]**<br>Write documentation for users and developers
- <span class="fa fa-li fa-language fa-2x"></span> **[Translations][bcc contribute translations]**<br>Translate the user interface
- <span class="fa fa-li fa-question fa-2x"></span> **[Tech support][bcc contribute support]**<br>Support other users
</div>
<br class="clear"><br class="big">
{% include references.md %}

67
en/bitcoin-core/contribute/issues.md
View file

@ -1,67 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
id: bitcoin-core-contribute-issues
columns: 1
lang: en
title: Issues - Contribute to Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- bcc contribute
- Issues
---
# Contribute Bug Reports
If you discover a bug or other problem with Bitcoin Core, please report
it. The are two different processes, [responsible disclosure](#disclosure) for
security bugs and [public issue tracking](#public-issue-tracking) for all other bugs.
<span class="fa fa-exclamation-triangle"></span> **Please don't open an
issue to ask for support.** See the [Get Help][bcc help] page instead.
<h2 id="disclosure">{% translate disclosure development %}</h2>
See the [Bitcoin Core contact page](https://bitcoincore.org/en/contact/) for reporting security issues.
## Public Issue Tracking
For non-security problems with Bitcoin Core, please [search for similar
issues][bcc issues] and, if you don't find any, [open a new issue][bcc
new issue] providing the information listed below.
1. A clear description of the problem. If possible, please describe how
to reproduce the problem. (For general guidelines on writing steps
to reproduce, see [Mozilla's bug reporting documentation][].)
2. What version of Bitcoin Core you use (if you downloaded from
Bitcoin.org) or what commit you built using (`git log -1`) plus any
extra patches you applied.
3. Any relevant entries from your `debug.log` file. Note, this file can
contain private information, so review it before posting or ask in
the issue to email it directly to a developer rather than posting
publicly. You can publicly post logs on a [0bin service][0bin]. By
default, the `debug.log` can be found at the following locations:
- Windows: `%APPDATA%\Bitcoin\debug.log`
- OS X: `$HOME/Library/Application Support/Bitcoin/debug.log`
- Linux: `$HOME/.bitcoin/debug.log`
The best strategy to get your issue fixed quickly is to make it as easy
as possible for the development team to track down the problem and
write a fix. Providing more information and organizing it well helps
significantly.
<br class="clear big">
<div class="prevnext">
<span markdown="1">**Previous**<br>[Contribute overview][bcc contribute]</span>
<span markdown="1">**Next**<br>[Code][bcc contribute code]</span>
</div>
<br class="clear">
{% include references.md %}

76
en/bitcoin-core/contribute/support.md
View file

@ -1,76 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
id: bitcoin-core-contribute-tech-support
lang: en
layout: base-core
columns: 1
title: Support - Contribute to Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- bcc contribute
- Support
---
# Supporting Bitcoin Core Users
This site tells Bitcoin Core users where they can [go to find help][bcc
help]---but that help is provided by volunteers like you. Many questions
are asked by complete newbies, so nearly everyone with any experience
using Bitcoin Core can provide help.
Before you start providing support, you may want to familiarize yourself
with the available [documentation][bcc documentation].
## Forums
The following forums are where we believe most users ask their Bitcoin
Core questions.
- [Bitcoin StackExchange][] is a community dedicated entirely to
answering questions about Bitcoin and related technology. Many
questions about Bitcoin Core can be found under the [Bitcoin-Qt
tag][bitcoin stackexchange tag bitcoin-qt]
- [BitcoinTalk Technical Support][forum tech support] is a
sub-forum dedicated to providing help for Bitcoin Core and other
Bitcoin programs.
- [/r/Bitcoin][bitcoin reddit] is a Reddit community that occasionally
features questions about Bitcoin Core. Currently, very few questions
receive enough upvotes to be featured on the front page, but you can
always check the [new queue][bitcoin reddit new] or answer questions
on the popular Mentor Monday thread (usually posted around noon UTC
on Monday).
- [/r/BitcoinBeginners][bitcoin beginners] is a Reddit community that
prominently features questions from inexperienced Bitcoin users.
## Live
Internet Relay Chat (IRC) is the most popular way to get live online
help with Bitcoin Core. When providing links to documentation, most
chatrooms require you post full links (not links shortened using
services like TinyURL or Bit.ly).
The links below will get you started using an IRC web interface. Many
serious IRC users use a [native IRC client][].
- [#bitcoin][] is where most users should ask general questions about
Bitcoin Core.
- [#bitcoin-mining][] hosts discussion about Bitcoin mining, including
decentralized mining using Bitcoin Core as part of the system.
- For more channels, please see the [comprehensive
listing][irc channels] on the Bitcoin Wiki.
<br class="clear big">
<div class="prevnext">
<span markdown="1">**Previous**<br>[Translations][bcc contribute translations]</span>
<span markdown="1">**Next**<br>[Contribute overview][bcc contribute]</span>
</div>
<br class="clear">
{% include references.md %}

59
en/bitcoin-core/contribute/translations.md
View file

@ -1,59 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
id: bitcoin-core-contribute-translations
layout: base-core
lang: en
columns: 1
title: Translations - Contribute to Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- bcc contribute
- Translations
---
# Translating Bitcoin Core
Bitcoin Core has been fully translated into over two dozen languages,
with dozens more languages partially translated---but more help is
always needed.
To contribute a translation, create a [Transifex][transifex] account and
then go to the [Bitcoin Core translation page][bitcoin core transifex].
From there you can click the Join Team button near the top of the page.
![Help translate Bitcoin](/img/bitcoin-core/transifex-1.png)
After you've joined the team, find the language you want to help
translate. Click on it and choose what Bitcoin Core release you want to
contribute to.
![Choose a language](/img/bitcoin-core/transifex-2.png)
From the page listing a specific release, you can click the Translate
button.
![Translate](/img/bitcoin-core/transifex-3.png)
On the Translation screen, click the Untranslated tab. On the left pane
will appear the English versions of text that needs translating. On the
right pane, you can enter your proposed translation.
![Choose untranslated](/img/bitcoin-core/transifex-4.png)
After saving your translation, it will be reviewed and (if accepted)
included in the next release of that version of Bitcoin Core.
*If you have any questions, please contact the translation maintainers
listed on Transifex or ask (in English) in the [#bitcoin-dev][] IRC
chatroom.*
<br class="clear big">
<div class="prevnext">
<span markdown="1">**Previous**<br>[Documentation][bcc contribute documentation]</span>
<span markdown="1">**Next**<br>[Tech support][bcc contribute support]</span>
</div>
<br class="clear">
{% include references.md %}

113
en/bitcoin-core/features/index.md
View file

@ -1,113 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: en
id: bitcoin-core-feature-overview
columns: 1
title: Features - Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- Features
end_of_page: |
<script>
start_slideshow($('#slidebox'));
</script>
---
# Bitcoin Core
{:.not-displayed}
<div id="slidebox">
<div class="slide-viewer">
<div class="slide-group">
<div class="slide slide-1">
<a href="#validation"><img src="/img/bitcoin-core/slider-validation.svg" alt="Full Validation: the best possible decentralized security" /></a>
</div>
<div class="slide slide-2">
<a href="#privacy"><img src="/img/bitcoin-core/slider-privacy.svg" alt="Strong privacy" /></a>
</div>
<div class="slide slide-3">
<a href="#requirements"><img src="/img/bitcoin-core/slider-warning.svg" alt="Requirements and warnings" /></a>
</div>
<div class="slide slide-4">
<a href="#user-interface"><img src="/img/bitcoin-core/slider-ui.svg" alt="User interface" /></a>
</div>
<div class="slide slide-5">
<a href="#network-support"><img src="/img/bitcoin-core/slider-network.svg" alt="Support the network" /></a>
</div>
</div>
</div>
<div class="slide-buttons"
><button type="image" class="slide-btn button-1" markdown="1"
><span class="fa fa-check-square-o"></span></button>
<button type="button" class="slide-btn button-2" markdown="1"
><span class="fa fa-shield"></span></button>
<button type="button" class="slide-btn button-3" markdown="1"
><span class="fa fa-bar-chart"></span></button>
<button type="button" class="slide-btn button-4" markdown="1"
><span class="fa fa-sign-in"></span></button>
<button type="button" class="slide-btn button-5" markdown="1"
><span class="fa fa-globe"></span></button
></div>
</div>
<br class="clear">
{% include bitcoin-core/download-bitcoin-core.html %}
## <span class="fa fa-check-square-o fa-lg"></span> Full Validation {#validation}
{:.no_gap}
Bitcoin Core ensures every block and transaction it accepts is valid,
increasing not only your security but also **helping prevent miners and
banks from taking control of Bitcoin.**
{:.right-hanger}
[Learn about full validation][bcc validation]
## <span class="fa fa-shield fa-lg"></span> Better Privacy {#privacy}
Bitcoin Core provides **exclusive privacy features** that can make it
hard for anyone to link you to your transactions.
{:.right-hanger}
[Discover the privacy advantages][bcc privacy]
## <span class="fa fa-bar-chart fa-lg"></span> Warning: Better Security Has Costs {#requirements}
Bitcoin Core uses more resources than other wallets, but it's still
convenient to run on most computers and Internet connections.
{:.right-hanger}
[System requirements & warnings][bcc requirements]
## <span class="fa fa-sign-in fa-lg"></span> A Better User Interface {#user-interface}
Bitcoin Core wallet has **features most other wallets don't have.** But
if you don't need them, you can use several other wallets on top of
Bitcoin Core without losing Bitcoin Core's [security][bcc validation] and
[privacy][bcc privacy] benefits.
{:.right-hanger}
[Tour the user interface][bcc user interface]
## <span class="fa fa-globe fa-lg"></span> Support The Network {#network-support}
Bitcoin Core helps support other peers. This isn't as useful as [helping
to keep Bitcoin decentralized](#validation), but it's **an easy way for
broadband users to contribute** to less well-connected users.
{:.right-hanger}
[Begin donating bandwidth][bcc network support]
<br>
{% include references.md %}

59
en/bitcoin-core/features/network-support.md
View file

@ -1,59 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
id: bitcoin-core-donate-bandwidth
layout: base-core
lang: en
columns: 1
title: Support The Network - Bitcoin Core Features
breadcrumbs:
- bitcoin
- bcc
- bcc features
- Network Support
---
# Donate Bandwidth Using Bitcoin Core
{:.not-displayed}
![Support the network](/img/bitcoin-core/slider-network.svg)
{% include bitcoin-core/download-bitcoin-core.html %}
The Bitcoin peer-to-peer network serves both Bitcoin Core and many other
Bitcoin programs (mostly lightweight wallets). By contributing some of
your bandwidth---typically about 100 GB upload a month---you can help
support Bitcoin.
The [bandwidth sharing guide][] provides all of the details you need
to begin donating bandwidth.
## Don't Forget About Decentralization
The Bitcoin network needs more than bandwidth---it also needs people who
[actively secure][bcc validation do you validate] their bitcoins using Bitcoin Core. By
securing your bitcoins with a full node like Bitcoin Core, you [help
protect Bitcoin's decentralization][bcc validation decentralization] for
yourself and other Bitcoin users.
You can help protect decentralization instead of donating bandwidth by
simply using Bitcoin Core as your main wallet. Or, even better, you can
both donate bandwidth and protect decentralization at the same time by
using Bitcoin Core as your main wallet while also following the
instructions in the [bandwidth sharing guide][].
## Thank You
Whether you choose to donate bandwidth, protect decentralization, or
both, please know that your fellow Bitcoin users thank you. Without
volunteers like you, Bitcoin would never have come as far as it has.
<br class="clear big">
<div class="prevnext">
<span markdown="1">**Previous Feature**<br>[User interface][bcc user interface]</span>
<span markdown="1">**Next feature**<br>[Feature overview][bcc features]</span>
</div>
<br class="clear">
{% include references.md %}

443
en/bitcoin-core/features/privacy.md
View file

@ -1,443 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
id: bitcoin-core-privacy
layout: base-core
lang: en
columns: 1
title: Privacy - Bitcoin Core Features
breadcrumbs:
- bitcoin
- bcc
- bcc features
- Privacy
third_party_privacy:
## Alphabetical order
- name: "Bitcoin Core"
css_class: bitcoin_core
group: default-show
tracks_real_names: "no"
knows_your_bitcoin_balance: "no"
susceptible_to_taint_analysis: "yes"
tracks_payments: "no"
tracks_amounts: "no"
tracks_ip_addresses: "no"
- name: "BitGo"
css_class: bitcoin_go
group: not-displayed
tracks_real_names: "no"
knows_your_bitcoin_balance: "yes"
susceptible_to_taint_analysis: "yes"
tracks_payments: "yes"
tracks_amounts: "yes"
tracks_ip_addresses: "yes"
- name: Blockchain.info
css_class: blockchain_info
group: not-displayed
tracks_real_names: "no"
knows_your_bitcoin_balance: "yes"
susceptible_to_taint_analysis: "yes"
tracks_payments: "yes"
tracks_amounts: "yes"
tracks_ip_addresses: "yes"
- name: Coinbase
css_class: coinbase
group: default-show
tracks_real_names: "yes"
knows_your_bitcoin_balance: "yes"
susceptible_to_taint_analysis: "no"
tracks_payments: "yes"
tracks_amounts: "yes"
tracks_ip_addresses: "yes"
- name: GreenAddress
css_class: greenaddress
group: not-displayed
tracks_real_names: "no"
knows_your_bitcoin_balance: "yes"
susceptible_to_taint_analysis: "yes"
tracks_payments: "yes"
tracks_amounts: "yes"
tracks_ip_addresses: "yes"
---
# Bitcoin Core's Excellent Privacy
{:.not-displayed}
![Excellent privacy](/img/bitcoin-core/slider-privacy.svg)
{% include bitcoin-core/download-bitcoin-core.html %}
> What if every time you spent or received cash, all the transaction
> details were published to your Twitter or Facebook feed for all your
> friends to see? You probably wouldn't want to use cash any more.
Every confirmed Bitcoin transaction is published to the block chain
where anyone can see it. So **why do people still use Bitcoin?** And why
do many of them believe that Bitcoin is a private way of sending money?
One reason is that Bitcoin Core and some other Bitcoin software tries to
avoid associating your real-world identity with the transactions you
make. The difference looks like this:
![Privacy difference: pseudonymous transactions](/img/bitcoin-core/privacy-difference.svg)
The second type of transaction (a pseudonymous transaction) only provides
practical privacy if nobody can figure out that "5a35b" is really Alice.
It's up to your wallet to prevent anyone from making that connection.
See below for how Bitcoin Core's privacy compares to other wallets.
## No Sign-Up Required
Third-party Bitcoin services can both increase and decrease your
privacy. They can increase it by mixing your transactions with those of
other users; they can decrease it by tracking your activity and directly
associating it with your real name or other identifying information.
<p class="center service-choose">
<a>Click an entry below to show it:</a>
{% for service in page.third_party_privacy %}
{% if service.name != 'Bitcoin Core' %}
<button
{% if service.group == "default-show" %}
class="js showcolumn active"
{% else %}
class="js showcolumn"
{% endif %}
id="{{service.css_class}}"
>{{service.name}}</button>
{% endif %}
{% endfor %}
</p>
<table class="privacy-comparison">
{% comment %}
<!-- Don't overdo it! Limit table to a total of seven content rows, with a
maximum of five content rows in each category. -->
{% endcomment %}
<tr>
<th markdown="span" colspan="99">Who knows your information? **Just you**{:.fggreen} or also a **service provider?**{:.fgred}</th>
</tr>
<tr>
<th></th>
{% for service in page.third_party_privacy %}
{% if service.name %}
<th class="{{service.css_class}} {{service.group}}">{{service.name}}</th>
{% else %}
{% die "Some service doesn't have a name" %}
{% endif %}
{% endfor %}
</tr>
<tr>
<td>Your real name</td>
{% for service in page.third_party_privacy %}
{% case service.tracks_real_names %}
{% when "yes" %}
<td class="bgred {{service.css_class}} {{service.group}}"></td>
{% when "no" %}
<td class="bggreen {{service.css_class}} {{service.group}}"></td>
{% when "maybe" %}
<td class="bgyellow {{service.css_class}} {{service.group}}"></td>
{% else %}
{% die "missing service information" %}
{% endcase %}
{% endfor %}
</tr>
<tr>
<td>Your bitcoin balance</td>
{% for service in page.third_party_privacy %}
{% case service.knows_your_bitcoin_balance %}
{% when "yes" %}
<td class="bgred {{service.css_class}} {{service.group}}"></td>
{% when "no" %}
<td class="bggreen {{service.css_class}} {{service.group}}"></td>
{% when "maybe" %}
<td class="bgyellow {{service.css_class}} {{service.group}}"></td>
{% else %}
{% die "missing service information" %}
{% endcase %}
{% endfor %}
</tr>
<tr>
<td>Who you pay, and/or who pays you (in some cases)</td>
{% for service in page.third_party_privacy %}
{% case service.tracks_payments %}
{% when "yes" %}
<td class="bgred {{service.css_class}} {{service.group}}"></td>
{% when "no" %}
<td class="bggreen {{service.css_class}} {{service.group}}"></td>
{% when "maybe" %}
<td class="bgyellow {{service.css_class}} {{service.group}}"></td>
{% else %}
{% die "missing service information" %}
{% endcase %}
{% endfor %}
</tr>
<tr>
<td>How much you spend and/or receive</td>
{% for service in page.third_party_privacy %}
{% case service.tracks_amounts %}
{% when "yes" %}
<td class="bgred {{service.css_class}} {{service.group}}"></td>
{% when "no" %}
<td class="bggreen {{service.css_class}} {{service.group}}"></td>
{% when "maybe" %}
<td class="bgyellow {{service.css_class}} {{service.group}}"></td>
{% else %}
{% die "missing service information" %}
{% endcase %}
{% endfor %}
</tr>
<tr>
<td>The IP address your connection came from</td>
{% for service in page.third_party_privacy %}
{% case service.tracks_ip_addresses %}
{% when "yes" %}
<td class="bgred {{service.css_class}} {{service.group}}"></td>
{% when "no" %}
<td class="bggreen {{service.css_class}} {{service.group}}"></td>
{% when "maybe" %}
<td class="bgyellow {{service.css_class}} {{service.group}}"></td>
{% else %}
{% die "missing service information" %}
{% endcase %}
{% endfor %}
</tr>
<tr class="empty"></tr>
<tr>
<th markdown="span" colspan="99">Who can guess your information? **Just you**{:.fggreen} or also **people
you trade with?**{:.fgred}</th>
</tr>
<tr>
<th></th>
{% for service in page.third_party_privacy %}
{% if service.name %}
<th class="{{service.css_class}} {{service.group}}">{{service.name}}</th>
{% else %}
{% die "Some service doesn't have a name" %}
{% endif %}
{% endfor %}
</tr>
<tr>
<td>Other transactions you made or received</td>
{% for service in page.third_party_privacy %}
{% case service.susceptible_to_taint_analysis %}
{% when "yes" %}
<td class="bgred {{service.css_class}} {{service.group}}"></td>
{% when "no" %}
<td class="bggreen {{service.css_class}} {{service.group}}"></td>
{% when "maybe" %}
<td class="bgyellow {{service.css_class}} {{service.group}}"></td>
{% else %}
{% die "missing service information" %}
{% endcase %}
{% endfor %}
</tr>
</table>
## Perfect Privacy for Received Transactions
There are {{site.text.total_tx_count_in_millions}} million transactions on the Bitcoin block
chain. How do you find which ones pay you? Here are some common
options:
<table class="received_transactions">
<tr>
<td class="center" markdown="span">**Ask bankers**{:.fgred}<br
>They'll monitor your every transaction<br><br
><button class="popup js" data-container="bitcoin_bank_receiving">Bitcoin banks</button></td>
<td class="center" markdown="span">**Ask random nodes**{:.fgred}<br
>Some of which sell your data<br><br
><button class="popup js" data-container="bloom_filter_receiving">P2P lightweight wallets</button></td>
</tr>
<tr>
<td class="center" markdown="span">**Ask a free service**{:.fgred}<br
>(Actually, some do care about privacy)<br><br
><button class="popup js" data-container="electrum_style_receiving">Client lightweight wallets</button></td>
<td class="center" markdown="span">**Get all {{site.text.total_tx_count_in_millions}} million transactions**{:.fggreen}<br
>For **perfect** receiving privacy<br><br
>**Bitcoin Core**</td>
</tr>
</table>
Bitcoin Core downloads all {{site.text.total_tx_count_in_millions}} million transactions on the Bitcoin block
chain and processes them to find which transactions pay you.
This currently takes about {{site.text.typical_ibd_time_in_hours}} hours the first time
you start Bitcoin Core and about {{site.text.typical_144_block_catchup_time_in_minutes}}
minutes a day to keep updated, but it gives you what scientists call
**<button class="popup js" data-container="information_theoretic_privacy">information-theoretic (perfect) privacy</button>**
against eavesdroppers for received transactions.
## Strong Privacy for Sent Transactions
To put a transaction on the block chain, you must send it publicly---but
how you send it can make a big difference.
![Sending privacy](/img/bitcoin-core/sending-privacy.svg)
**Can you guess who made which transactions?** Nearly all peer-to-peer
lightweight clients today make no attempt to obscure their sent
transactions. They simply send them to some or all of their peers.
Bitcoin Core does much better. By default, it relays transactions for
all of its peers---thousands of separate transactions a day under common
conditions---which allows it both [support the peer-to-peer network][bcc
network support] and confuse anti-privacy organizations that try to
track your transactions.
## Tor Compatible
The Tor anonymity network helps disassociate your online activity from
your IP address (which is often closely associated with your real name).
This significantly increases your ability to confound anti-privacy
organizations.
Once you [setup Tor][], using it with Bitcoin Core is [easy][bcc
tor]. If you also [setup a Tor hidden service][bcc tor hs], you will
be able to [connect mobile clients][bcc user interface lightweight]
to your Bitcoin Core full node for increased security and privacy
wherever you go.
{:.right-hanger}
[Start using Tor today <span class="fa fa-external-link-square"></span>][setup tor]
## Decentralized Peer Discovery
The first time any Bitcoin program connects to the peer-to-peer network,
it has to ask a centralized authority for a list of recommended peers.
Once the program gets on the network, it can ask its peers for more
recommendations in a fully decentralized way---but
<button class="popup js" data-container="spv_decentralized_peer">most</button>
lightweight wallets don't bother.
<table class="center_header">
<tr>
<th class="fgred">P2P Lightweight Wallets</th>
<th class="fggreen">Bitcoin Core</th>
</tr>
<tr>
<td>Asks the same centralized services every time program is
restarted. This can be faster.</td>
<td>Uses the peer-to-peer network to independently discover new
peers. Uses found peers on restart.</td>
</tr>
</table>
This allows the centralized authority to connect lightweight wallets to
dishonest peers that can **completely destroy lightweight transaction
privacy.** Those dishonest peers can work with dishonest miners to
**weaken lightweight security too.**
Bitcoin Core prefers decentralized peer discovery, so after the first
time it starts, it no longer has to trust the centralized authority.
Isn't that worth occasionally starting up a few seconds slower?
<br class="clear big">
<div class="prevnext">
<span markdown="1">**Previous Feature**<br>[Validation][bcc validation]</span>
<span markdown="1">**Next feature**<br>[Requirements][bcc requirements]</span>
</div>
<br class="clear">
<div class="not-displayed">
<div id="bitcoin_bank_receiving" title="Bitcoin Bank Receiving Privacy" markdown="block">
![Bitcoin Core receiving privacy features](/img/bitcoin-core/bank-receiving-privacy.svg)
When you receive bitcoins to a Bitcoin bank, the money is sent to one of
the bank's addresses---not your own---which can give you excellent
privacy against random strangers.
However, the bank knows you received the transaction and they can likely
also see any information you associate with the transaction, such as the
sender's name or another note you attach to the transaction.
The bank may also be required by law to disclose information about your
account. They can also sell your information or have a hacker steal your
information.
</div>
<div id="bloom_filter_receiving" title="Bloom Filter Privacy" markdown="block">
![Receiving privacy](/img/bitcoin-core/receiving-privacy.svg)
By only asking for payments related to your wallet, plus maybe a few
others as bloom filter camouflage, lightweight wallets may reveal who you
paid, who paid you, and what your current bitcoin balance is.
> A [2014 study of lightweight clients][study of SPV privacy over tor]
> said, "Our results show that bloom filters incur serious privacy
> leakage in existing SPV client implementations [...] such an
> information leakage might severely harm the privacy of users" **Nearly
> all lightweight clients are still vulnerable today.**
**Learn more:** ["Lying consistently is hard"][lying consistently is hard]
</div>
<div id="electrum_style_receiving" title="Client Lightweight Wallet Receiving Privacy" markdown="block">
![Electrum-style receiving privacy](/img/bitcoin-core/electrum-receiving-privacy.svg)
Some lightweight wallets don't connect to the Bitcoin peer-to-peer (P2P)
network. Instead, they make a (usually secure) connection to a single
server that provides block chain data.
The wallet tells the server all of its addresses, and the server replies
with all of the transactions that belong to the wallet. This explicitly
reveals all of your addresses, which is bad for your privacy---but it
only gives that information to one server, as long as you don't change
servers later.
The server can, of course, give away your information and further
reduce your privacy. However, as of
{{site.text.assertion_month | date: "%B %Y"}}, most of these types of
servers are run by volunteers who likely want to help protect your
privacy, so this model can be more private than bank wallets or P2P
lightweight wallets.
</div>
<div id="spv_decentralized_peer" title="P2P Decentralized Peer Discovery" markdown="block">
The following P2P lightweight wallets use decentralized peer discovery
by default.
- BreadWallet
If you know of another compliant lightweight wallet, please [tell us
about it][docs issue].
</div>
<div id="information_theoretic_privacy" title="Information-Theoretic Privacy" markdown="block">
Information-theoretic privacy means that the privacy can't be broken even
if an attacker has unlimited computing resources.
**Learn more:** [Information theoretic security][] (Wikipedia)
</div>
</div>
{% include references.md %}

229
en/bitcoin-core/features/requirements.md
View file

@ -1,229 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: en
columns: 1
id: bitcoin-core-requirements
title: Requirements And Warnings - Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- bcc features
- Requirements
---
# Bitcoin Core Requirements And Warnings
{:.not-displayed}
![Bitcoin Core requirements and warnings](/img/bitcoin-core/slider-warning.svg)
{% include bitcoin-core/download-bitcoin-core.html %}
Bitcoin Core gives you increased [security][bcc validation] and
[privacy][bcc privacy] at a cost. You need to [take
responsibility](#wallet-responsibility-checklist) for the security of
your bitcoins, meet higher [minimum system
requirements](#system-requirements), and beware of some [possible
problems](#possible-problems).
![Warning icon](/img/icons/icon_warning.svg)
**No matter what Bitcoin software you use,** you should never
buy more bitcoins than you can afford to lose. Bitcoin is still an
experimental system and bitcoins remain a risky investment.
## Wallet Responsibility Checklist
Bitcoin Core puts you in charge of your wallet, which means your
bitcoins are at risk unless you complete certain tasks:
{% comment %}
<!-- Note: the short pop-ups below are a temporary measure. I (@harding) plan
to write a Bitcoin Core user guide for the site that will provide more
detailed instructions for at least some of these things. -->
{% endcomment %}
- <button class="popup js" data-container="backup_your_keys">Backup your keys</button>
- Make sure your <button class="popup js" data-container="secure_your_wallet">wallet is secure</button>
- Setup an <button class="popup js" data-container="offline_wallet">offline wallet</button>
(cold storage) for significant amounts of bitcoins
- Watch for [security notifications](/en/alerts)
- Allow your heirs to <button class="popup js" data-container="bitcoin_inheritance">receive your bitcoins</button>
if you die or become incapacitated
If you need help with any step, please ask for assistance in any of
Bitcoin's [friendly forums][bcc forums] or [live chatrooms][bcc live
help].
## System Requirements
{% assign DISK='<span class="fa fa-li fa-hdd-o fa-2x"></span> **Disk space**<br>' %}
{% assign DOWNLOAD='<span class="fa fa-li fa-download fa-2x"></span> **Download**<br>' %}
{% assign UPLOAD='<span class="fa fa-li fa-upload fa-2x"></span> **Upload**<br>' %}
{% assign MEMORY='<span class="fa fa-li fa-database fa-2x"></span> **Memory (RAM)**<br>' %}
{% assign SYSTEM='<span class="fa fa-li fa-desktop fa-2x"></span> **System**<br>' %}
{% assign OS='<span class="fa fa-li fa-windows fa-2x"></span> **Operating system**<br>' %}
{% assign FOOTNOTE='<b>*</b>' %}
{% capture INITIAL_DOWNLOAD %}<b>*</b> Plus a one-time {{site.text.chain_gb}} GB download the first time you start Bitcoin Core.{% endcapture %}
<div markdown="block" class="two-column-list" id="system-requirements-accordion">
### Bare Minimum (With Default Settings)
<div markdown="block">
{:.fa-ul}
- {{DISK}} {{site.text.bitcoin_datadir_gb}} GB
- {{DOWNLOAD}} 250 MB/day (8 GB/month){{FOOTNOTE}}
- {{UPLOAD}} 5 GB/day (150 GB/month)
- {{MEMORY}} 512 MB
- {{SYSTEM}} Desktop<br
>Laptop<br
>[Some ARM chipsets][wiki bitcoin core compatible devices arm] >1 GHz
- {{OS}} Windows 7/8.x<br
>Mac OS X<br
>Linux<br
>Some BSDs
<br class="clear">
{{INITIAL_DOWNLOAD}}
</div>
### Bare Minimum (With Custom Settings)
<div markdown="block">
{:.fa-ul}
- {{DISK}} {{site.text.bitcoin_datadir_gb_pruned}} GB
- {{DOWNLOAD}} 150 MB/day (5 GB/month){{FOOTNOTE}}
- {{UPLOAD}} 10 MB/day (300 MB/month)
- {{MEMORY}} 256 MB
- {{SYSTEM}} Desktop<br
>Laptop<br
>[Most ARM chipsets][wiki bitcoin core compatible devices arm]
- {{OS}} Windows 7/8.x<br
>Mac OS X<br
>Linux<br
>Some BSDs
<br class="clear">
{{INITIAL_DOWNLOAD}}
**Learn more:** [Bitcoin Core configuration options][bcc configuration]
</div>
### Minimum Recommended
<div markdown="block">
{:.fa-ul}
- {{DISK}} {{site.text.bitcoin_datadir_gb}} GB
- {{DOWNLOAD}} 500 MB/day (15 GB/month){{FOOTNOTE}}
- {{UPLOAD}} 5 GB/day (150 GB/month)
- {{MEMORY}} 1 GB
- {{SYSTEM}} Desktop<br
>Laptop<br
>[Some ARM chipsets][wiki bitcoin core compatible devices arm] >1 GHz
- {{OS}} Windows 7/8.x/10<br
>Mac OS X<br
>Linux
<br class="clear">
{{INITIAL_DOWNLOAD}}
</div>
</div>
## Possible Problems
{% include bitcoin-core/bitcoin-core-possible-problems.md %}
<div class="not-displayed">
<div id="backup_your_keys" title="Backup Your Keys" markdown="block">
By default, you need to backup Bitcoin Core after every 100
transactions. This includes both transactions you send as well as
payments you request (whether or not you actually received the payment).
For example, you need to backup after sending 33 payments and requesting
67 payments (even though you only received 60 payments).
Bitcoin Core can be configured to allow you to go more transactions
between backups. See the [`-keypool` setting][bcc configuration].
</div>
<div id="secure_your_wallet" title="Secure Your Wallet" markdown="block">
Anyone who gets access to your wallet can steal your bitcoins. The
first line of defense against this is encrypting your wallet, an option
from the File menu in the graphical interface.
However, encrypting may not be enough if your computer becomes infected
by malware. Learn about <button class="popup js" data-container="offline_wallet">offline wallets</button>
for security against this type of attack.
In addition to securing your wallet, you also need to keep your backups
secure. Anyone who gets access to them can also steal your bitcoins.
**Learn more:** [secure your wallet][]
</div>
<div id="offline_wallet" title="Offline Wallet" markdown="block">
Computers that connect to the Internet are frequently hacked or infected
with bitcoin-stealing malware. Computers that never connect to the
Internet are a much more secure location for your bitcoins.
Bitcoin Core can be run on an always-offline computer, creating an
offline wallet (also called a cold wallet). The offline wallet will
securely store the private keys, while a separate online Bitcoin Core
wallet will send and receive transactions.
**Learn more:** [Creating and signing offline transactions][offline transactions]
</div>
<div id="bitcoin_inheritance" title="Bitcoin Inheritance" markdown="block">
Your Bitcoin wallet isn't like a bank account---it won't automatically
go to your heirs if you die or become disabled.
You have to plan ahead and make sure there is a way for your heirs
to access your wallet backups when you're no longer available.
**Learn more:** [Estate planning: how can I ensure my bitcoins are inheritable?][inherit bitcoins]
</div>
</div>
<br class="clear big">
<div class="prevnext">
<span markdown="1">**Previous Feature**<br>[Privacy][bcc privacy]</span>
<span markdown="1">**Next feature**<br>[User interface][bcc user interface]</span>
</div>
<br class="clear">
{% include references.md %}

347
en/bitcoin-core/features/user-interface.md
View file

@ -1,347 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
id: bitcoin-core-user-interface
layout: base-core
lang: en
columns: 1
title: User Interface - Bitcoin Core Features
breadcrumbs:
- bitcoin
- bcc
- bcc features
- Interface
---
# Bitcoin Core's User Interface
{:.not-displayed}
![Bitcoin Core User Interface](/img/bitcoin-core/slider-ui.svg)
{% include bitcoin-core/download-bitcoin-core.html %}
Bitcoin Core has a built in wallet with [graphical](#graphical) and
[command line/API](#cli) modes. It can also simultaneously support multiple
lightweight wallets with similar [security][bcc validation] and
[privacy][bcc privacy] to its built-in wallet.
![Multiple wallet support](/img/bitcoin-core/multi-wallet-support.svg)
**Warning:** you only get the security and privacy benefits in supported
lightweight wallets if they make a secure and private connection to your
Bitcoin Core *every* time you use them. This usually requires special
configuration.
## Bitcoin Core Wallet GUI (Graphical) {#graphical}
{% comment %}<!-- Limit to a maximum of 10 features to avoid overwhelming the reader -->{% endcomment %}
<div markdown="block" class="two-column-list">
{:.fa-ul}
- <span class="fa fa-li fa-desktop fa-2x"></span> **<button class="popup js" data-container="gui_overview">Clear overview</button>**<br
>See your current balance and recent transactions
- <span class="fa fa-li fa-toggle-on fa-2x"></span> **<button class="popup js" data-container="gui_fee_slider">Fee slider</button>**<br
>Easily choose between low fees and fast confirmation
- <span class="fa fa-li fa-btc fa-2x"></span> **<button class="popup js" data-container="gui_coin_control">Coin control</button>**<br
>Enhance privacy or save money by choosing your inputs
- <span class="fa fa-li fa-qrcode fa-2x"></span> **<button class="popup js" data-container="gui_qr_codes">QR codes</button>**<br
>Generate QR codes to receive payment
- <span class="fa fa-li fa-file-text-o fa-2x"></span> **<button class="popup js" data-container="gui_unique_invoices">Unique invoices</button>**<br
>Easily track who paid you
- <span class="fa fa-li fa-shield fa-2x"></span> **<button class="popup js" data-container="gui_proxy_configuration">Proxy configuration</button>**<br
>Use Tor or a proxy for privacy
- <span class="fa fa-li fa-bar-chart fa-2x"></span> **<button class="popup js" data-container="gui_network_monitoring">Network monitoring</button>**<br
>Track how much bandwidth you use
- <span class="fa fa-li fa-power-off fa-2x"></span> **<button class="popup js" data-container="gui_watch_only">Watch-only support</button>**<br
>Track bitcoins stored safely offline
</div>
<br class="clear">
## Bitcoin Core Wallet RPC/REST (CLI) {#cli}
{% comment %}<!-- Limit to a maximum of 10 features to avoid overwhelming the reader -->{% endcomment %}
<div markdown="block" class="two-column-list">
{:.fa-ul}
- <span class="fa fa-li fa-plus-square-o fa-2x"></span> **<button class="popup js" data-container="rpc_getnewaddress">GetNewAddress</button>**<br
>Get a new address for receiving payment
- <span class="fa fa-li fa-area-chart fa-2x"></span> **<button class="popup js" data-container="rpc_getbalance">GetBalance</button>**<br
>Instantly see your available Bitcoin balance
- <span class="fa fa-li fa-arrows fa-2x"></span> **<button class="popup js" data-container="rpc_sendmany">SendMany</button>**<br
>Send a single payment to multiple addresses
- <span class="fa fa-li fa-list fa-2x"></span> **<button class="popup js" data-container="rpc_listunspent">ListUnspent</button>**<br
>See what received transactions you can spend
- <span class="fa fa-li fa-share-square-o fa-2x"></span> **<button class="popup js" data-container="rpc_rawtx">Create/Sign/Send</button>**<br
>Create and send raw transactions
- <span class="fa fa-li fa-bell-o fa-2x"></span> **<button class="popup js" data-container="notification">Notification</button>**<br
>Be notified of new blocks and transactions
</div>
<br class="clear">
**Learn more:** documentation for the [RPC][rpc] and [REST][rest] interfaces
## Lightweight Wallets Using Bitcoin Core {#lightweight}
Lightweight wallets usually connect to several random full nodes (like
Bitcoin Core) to send and receive all of their data. In the process they
[leak private data][bcc privacy data leaking] and make themselves more
[vulnerable to attacks][bcc validation protection].
![Non-private connection](/img/bitcoin-core/connection-types-p2p-spv.svg)
But it's also possible to connect certain lightweight wallets solely to
your own Bitcoin Core full node, called a trusted peer. If you do this
with a secure and private connection every time you use that
lightweight wallet, you'll get most of the security and privacy
benefits of a full node as well as [help protect decentralization][bcc
validation decentralization].
![Secure and private connection](/img/bitcoin-core/connection-types-trusted-peer.svg)
<br>
### Trusted Peer Support {#trusted-peer}
The following wallets can securely connect to a trusted peer.
<div markdown="block" class="wallet_accordion">
{% comment %}<!-- Put wallets in alphabetical order -->{% endcomment %}
### GreenBits
<div markdown="block">
![GreenBits screenshot](/img/screenshots/greenbits.png)
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.
**Requires you setup a [Tor .onion address][bcc tor hs].**
1. Open the GreenBits app
2. Go to the configuration screen
3. Choose to *Enable SPV* (default) and tap *Only connect to a
trusted peer*.
4. Enter your .onion address in the *trusted peer* field.
5. Restart the app.
Note that GreenAddress will still be able to see your payments; however,
you'll have enhanced security as well as privacy from random peers on
the Bitcoin network.
{:.right-hanger}
[Get GreenBits <span class="fa fa-external-link-square"></span>](https://play.google.com/store/apps/details?id=com.greenaddress.greenbits_android_wallet)
</div>
### mSigna
<div markdown="block">
![mSigma screenshot](/img/screenshots/msigna.png)
{% translate walletmsigna choose-your-wallet %}
**No configuration necessary:** just install Bitcoin Core on the same
computer you plan to use mSigna, wait for Bitcoin Core to sync the block
chain, and then start mSigna---it will automatically connect to your
Bitcoin Core full node.
{:.right-hanger}
[Get mSigna <span class="fa fa-external-link-square"></span>](https://ciphrex.com/redirect/?referer=bitcoin.org)
</div>
</div>
<div class="not-displayed">
<div id="gui_overview" title="Wallet Overview" markdown="block">
![Clear overview](/img/bitcoin-core/clear-overview.png)
</div>
<div id="gui_fee_slider" title="Fee Slider" markdown="block">
![Fee slider](/img/bitcoin-core/fee-slider.png)
</div>
<div id="gui_coin_control" title="Coin Control" markdown="block">
![Coin control](/img/bitcoin-core/coin-control.png)
</div>
<div id="gui_qr_codes" title="QR Codes" markdown="block">
![QR codes](/img/bitcoin-core/qr-codes.png)
</div>
<div id="gui_unique_invoices" title="Unique Invoices" markdown="block">
![Unique invoice](/img/bitcoin-core/unique-invoice.png)
</div>
<div id="gui_proxy_configuration" title="Proxy Configuration" markdown="block">
![Proxy configuration](/img/bitcoin-core/proxy-configuration.png)
</div>
<div id="gui_network_monitoring" title="Network monitoring" markdown="block">
![Network monitoring](/img/bitcoin-core/network-monitoring.png)
</div>
<div id="gui_watch_only" title="Watching-only Wallets" markdown="block">
![Fee slider](/img/bitcoin-core/watching-only.png)
</div>
<div id="rpc_getnewaddress" title="GetNewAddress" markdown="block">
<div class="multicode" markdown="block">
{% highlight bash %}
bitcoin-cli -testnet getnewaddress "doc test"
{% endhighlight %}
{% highlight text %}
mft61jjkmiEJwJ7Zw3r1h344D6aL1xwhma
{% endhighlight %}
</div>
</div>
<div id="rpc_getbalance" title="GetBalance" markdown="block">
<div class="multicode" markdown="block">
{% highlight bash %}
bitcoin-cli -testnet getbalance
{% endhighlight %}
{% highlight json %}
1.99900000
{% endhighlight %}
</div>
</div>
<div id="rpc_sendmany" title="SendMany" markdown="block">
<div class="multicode" markdown="block">
{% highlight bash %}
bitcoin-cli -testnet sendmany \
"test1" \
'''
{
"mjSk1Ny9spzU2fouzYgLqGUD8U41iR35QN": 0.1,
"mgnucj8nYqdrPFh2JfZSB1NmUThUGnmsqe": 0.2
} ''' \
6 \
"Example Transaction"
{% endhighlight %}
{% highlight text %}
ec259ab74ddff199e61caa67a26e29b13b5688dc60f509ce0df4d044e8f4d63d
{% endhighlight %}
</div>
</div>
<div id="rpc_listunspent" title="ListUnspent" markdown="block">
<div class="multicode" markdown="block">
{% highlight bash %}
bitcoin-cli -testnet listunspent 6 99999999 '''
[
"mgnucj8nYqdrPFh2JfZSB1NmUThUGnmsqe"
]
'''
{% endhighlight %}
{% highlight json %}
[
{
"txid" : "d54994ece1d11b19785c7248868696250ab195605b469632b7bd68130e880c9a",
"vout" : 1,
"address" : "mgnucj8nYqdrPFh2JfZSB1NmUThUGnmsqe",
"account" : "test label",
"scriptPubKey" : "76a9140dfc8bafc8419853b34d5e072ad37d1a5159f58488ac",
"amount" : 0.00010000,
"confirmations" : 6210,
"spendable" : true
}
]
{% endhighlight %}
</div>
</div>
<div id="rpc_rawtx" title="Create/Sign/Spent Raw Transactions" markdown="block">
Create a raw transaction:
<div class="multicode" markdown="block">
{% highlight bash %}
bitcoin-cli -testnet createrawtransaction '''
[
{
"txid": "1eb590cd06127f78bf38ab4140c4cdce56ad9eb8886999eb898ddf4d3b28a91d",
"vout" : 0
}
]''' '{ "mgnucj8nYqdrPFh2JfZSB1NmUThUGnmsqe": 0.13 }'
{% endhighlight %}
{% highlight text %}
01000000011da9283b4ddf8d89eb996988b89ead56cecdc44041ab38bf787f1206cd90b51e0000000000ffffffff01405dc600000000001976a9140dfc8bafc8419853b34d5e072ad37d1a5159f58488ac00000000
{% endhighlight %}
</div>
Sign the above raw transaction:
<div class="multicode" markdown="block">
{% highlight bash %}
bitcoin-cli -testnet signrawtransaction 01000000011da9283b4ddf8d\
89eb996988b89ead56cecdc44041ab38bf787f1206cd90b51e0000000000ffff\
ffff01405dc600000000001976a9140dfc8bafc8419853b34d5e072ad37d1a51\
59f58488ac00000000
{% endhighlight %}
{% highlight json %}
{
"hex" : "01000000011da9283b4ddf8d89eb996988b89ead56cecdc44041ab38bf787f1206cd90b51e000000006a47304402200ebea9f630f3ee35fa467ffc234592c79538ecd6eb1c9199eb23c4a16a0485a20220172ecaf6975902584987d295b8dddf8f46ec32ca19122510e22405ba52d1f13201210256d16d76a49e6c8e2edc1c265d600ec1a64a45153d45c29a2fd0228c24c3a524ffffffff01405dc600000000001976a9140dfc8bafc8419853b34d5e072ad37d1a5159f58488ac00000000",
"complete" : true
}
{% endhighlight %}
</div>
Send the above signed raw transaction:
<div class="multicode" markdown="block">
{% highlight bash %}
bitcoin-cli -testnet sendrawtransaction 01000000011da9283b4ddf8d\
89eb996988b89ead56cecdc44041ab38bf787f1206cd90b51e000000006a4730\
4402200ebea9f630f3ee35fa467ffc234592c79538ecd6eb1c9199eb23c4a16a\
0485a20220172ecaf6975902584987d295b8dddf8f46ec32ca19122510e22405\
ba52d1f13201210256d16d76a49e6c8e2edc1c265d600ec1a64a45153d45c29a\
2fd0228c24c3a524ffffffff01405dc600000000001976a9140dfc8bafc84198\
53b34d5e072ad37d1a5159f58488ac00000000
{% endhighlight %}
{% highlight text %}
f5a5ce5988cc72b9b90e8d1d6c910cda53c88d2175177357cc2f2cf0899fbaad
{% endhighlight %}
</div>
The returned value is the transaction's identifier (TXID).
</div>
<div id="notification" title="Programmable Notification" markdown="block">
<div class="multicode" markdown="block">
{% highlight bash %}
bitcoind -daemon -walletnotify=your_notification_command
{% endhighlight %}
</div>
</div>
</div>
<br class="clear big">
<div class="prevnext">
<span markdown="1">**Previous Feature**<br>[Requirements][bcc requirements]</span>
<span markdown="1">**Next feature**<br>[Network Support][bcc network support]</span>
</div>
<br class="clear">
{% include references.md %}

477
en/bitcoin-core/features/validation.md
View file

@ -1,477 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: en
columns: 1
id: bitcoin-core-validation
title: Validation - Bitcoin Core Features
breadcrumbs:
- bitcoin
- bcc
- bcc features
- Validation
---
# Bitcoin Core Validation
{:.not-displayed}
![Full validation](/img/bitcoin-core/slider-validation.svg)
{% include bitcoin-core/download-bitcoin-core.html %}
> Imagine a scientist reading about an experimental result and then
> repeating the experiment for herself. Doing so allows her to **trust
> the result without having to trust the original scientists.**
Bitcoin Core checks each block of transactions it receives to ensure
that everything in that block is fully valid---allowing it to trust the
block without trusting the miner who created it.
This prevents miners from tricking Bitcoin Core users into accepting
blocks that violate the 21 million bitcoin limit or which break other
important rules.
Users of other wallets don't get this level of security, so miners can
trick them into accepting fabricated transactions or hijacked block chains.
Why take that risk if you don't have to? Bitcoin Core provides
the **best possible security against dishonest miners** along
with additional security against other easier attacks (see below
for details).
## How Validation Protects Your Bitcoins
<button class="popup js" data-container="bitcoin_banks">Bitcoin banks</button>
and
<button class="popup js" data-container="spv_wallets">lightweight (SPV) wallets</button>
put your bitcoins at
increased risk of being stolen. That risk may be acceptable for small
values of bitcoin on mobile wallets, but is it what you want for your
real wallet?
*Click any row below for more details about that attack*
{:.center}
<table class="validation">
<tr>
<th>Attack</th>
<th markdown="span">Bank Wallet</th>
<th markdown="span">SPV Wallet</th>
<th>Bitcoin Core</th>
</tr>
<tr class="brief">
<td><span class="ui-button-icon-primary ui-icon ui-icon-triangle-1-e"></span>Direct theft</td>
<td class="bgred"></td>
<td class="bggreen"></td>
<td class="bggreen"></td>
</tr>
<tr class="details">
<td colspan="4" markdown="block">
> Alice deposits 100 bitcoins to Bank.Example.com. The next day, the
> owners of the site disappear with Alice's money.
- **Bitcoin bank**{:.fgred} users are vulnerable to direct theft because
they don't control their own private keys.
- **Lightweight (SPV) wallet**{:.fggreen} users and **Bitcoin
Core**{:.fggreen} users are not vulnerable because they control their
own private keys.
<div class="callout" markdown="block">
Direct theft is likely the leading cause of stolen bitcoins so far.
</div>
### Real Example
Bitcoin exchange Mt Gox reportedly had 650,000 bitcoins (worth $347
million USD) stolen from their customer deposits and their own operating
funds. They declared bankruptcy on 28 February 2014.
Even when the bankruptcy proceeding is complete, customers are unlikely to
recover more than a small fraction of the bitcoins they had on deposit.
**Learn More:** [Collapse of Mt
Gox](https://en.bitcoin.it/wiki/Collapse_of_Mt._Gox)
</td>
</tr>
<tr class="brief">
<td><span class="ui-button-icon-primary ui-icon ui-icon-triangle-1-e"></span>Bait and switch</td>
<td class="bgred"></td>
<td class="bgyellow"></td>
<td class="bggreen"></td>
</tr>
<tr class="details">
<td colspan="4" markdown="block">
> Alice installs Example Wallet, whose open source code has been
> audited. The next day, the authors of Example Wallet push new code to
> Alice's device and steal all her bitcoins.
- **Bitcoin bank**{:.fgred} users are vulnerable because they can only
spend their bitcoins when they use the bank's approved software.
- **Lightweight (SPV) wallet**{:.fgyellow} users are vulnerable with
most software because auditors can't easily verify the software you
run (the executable) is the same as the program source code, called a
deterministic build. However, some lightweight wallets are moving to
deterministic builds.
- **Bitcoin Core**{:.fggreen} is built deterministically. Cryptographic
signatures from build auditors---many of whom are well known to the
community---are [released publicly][gitian sigs].
<div class="callout" markdown="block">
Bitcoin.org's [Choose Your Wallet][] page tells you whether or not
wallet builds are audited in the *Transparency* score for each wallet.
</div>
### Real Example
In April 2013, the OzCoin mining pool was hacked. The thief stole 923
bitcoins (worth $135,000 USD), but online wallet StrongCoin modified
their wallet code to 'steal back' 569 of those bitcoins ($83,000)
from one of their users who was suspected of the theft.
Although this attack was done with good intentions, it illustrated
that the operators of StrongCoin could steal bitcoins from their users
at any time even though the users supposedly controlled their own
private keys.
**Learn More:** [OzCoin Hacked, Stolen Funds Seized and Returned by StrongCoin](https://bitcoinmagazine.com/4273/ozcoin-hacked-stolen-funds-seized-and-returned-by-strongcoin/)
</td>
</tr>
<tr class="brief">
<td><span class="ui-button-icon-primary ui-icon ui-icon-triangle-1-e"></span>Fabricated transactions</td>
<td class="bgred"></td>
<td class="bgred"></td>
<td class="bggreen"></td>
</tr>
<tr class="details">
<td colspan="4" markdown="block">
> Mallory creates a transaction giving Alice 1,000 bitcoins, so Alice
> gives Mallory some cash. Later Alice discovers the transaction Mallory
> created was fake.
- **Bitcoin bank**{:.fgred} users depend on the information reported by the
bank, so they can easily be fooled into accepting fabricated
transactions.
- **Lightweight (SPV) wallet**{:.fgred} users depend on full nodes and
miners to validate transactions for them. It costs nothing for
dishonest full nodes to send unconfirmed fabricated transactions to an
SPV wallet. Getting one or more confirmations of those fabricated
transactions is also possible with help from a dishonest miner.
- **Bitcoin Core**{:.fggreen} users don't have to worry about fabricated
transactions because Bitcoin Core validates every transaction before
displaying it.
<div class="callout" markdown="block">
Currently the best defense against fabricated transactions, besides
using Bitcoin Core, is to wait for as many confirmations as possible.
</div>
### Real Example
On 4 August 2015, web wallet BlockChain.info began indicating that a
transaction had spent the earliest mined 250 bitcoins, coins that some
people believed were owned by Bitcoin creator Satoshi Nakamoto.
It was soon discovered that the transaction was invalid. BlockChain.info
was not validating transactions with Bitcoin Core and that transaction
had been [created by a security researcher][fake satoshi transaction].
**Learn more:** [BitcoinJ documentation about pending transaction
safety][]
</td>
</tr>
<tr class="brief">
<td><span class="ui-button-icon-primary ui-icon ui-icon-triangle-1-e"></span>Chain hijacking</td>
<td class="bgred"></td>
<td class="bgred"></td>
<td class="bggreen"></td>
</tr>
<tr class="details">
<td colspan="4" markdown="block">
> Alice believes that there should never be more than 21 million
> bitcoins---but one day she's tricked into buying "bitcoins" that
> are only valid on a block chain with permanent 10% inflation.
- **Bitcoin bank**{:.fgred} users have to use whatever block chain the
bank uses. Banks can even profit from switching their users to a new
chain and selling their users' bitcoins from the old chain.
- **Lightweight (SPV) wallet**{:.fgred} users accept the block chain
they know about with the most proof of work. This lets the hash rate
majority of miners force SPV wallet users off of Bitcoin.
- **Bitcoin Core**{:.fggreen} users don't have to worry about chain
hijacking because Bitcoin Core validates every block using *all* of
Bitcoin's consensus rules.
<div class="callout" markdown="block">
Preventing chain hijacking is one of Bitcoin Core's most important jobs.
The alternative is to allow miners to do whatever they want.
</div>
### Real Example
In July 2015, several large Bitcoin miners accidentally produced an
invalid block chain several blocks longer than the correct block chain.
Some bank wallets and many SPV wallets accepted this longer chain,
putting their users' bitcoins at risk.
Recent versions of Bitcoin Core never accepted any of the blocks from
the invalid chain and never put any bitcoins at risk.
It is believed that the miners at fault controlled more than 50% of the
network hash rate, so they could have continued to fool SPV wallets
indefinitely. It was only their desire to remain compatible with
Bitcoin Core users that forced them to abandon over $37,500 USD worth of
mining income.
**Learn more:** [July 2015 chain forks][]
</td>
</tr>
<tr class="brief">
<td><span class="ui-button-icon-primary ui-icon ui-icon-triangle-1-e"></span>Transaction withholding</td>
<td class="bgred"></td>
<td class="bgred"></td>
<td class="bggreen"></td>
</tr>
<tr class="details">
<td colspan="4" markdown="block">
> Mallory shows Alice $1,000 USD that he will pay her if she sends him some
> bitcoins. Alice sends the bitcoins but the transaction never seems to
> confirm. After waiting a long time, Alice returns Mallory's cash. It
> turns out the transaction did confirm, so Alice gave away her bitcoins
> for nothing.
- **Bitcoin bank**{:.fgred} users only see the transactions the bank
choose to show them.
- **Lightweight (SPV) wallets**{:.fgred} users only see the
transactions their full node peers choose to send them, even if those
transactions were included in a block the SPV wallet knows about.
- **Bitcoin Core**{:.fggreen} users see all transactions included in
received blocks. If Bitcoin Core hasn't received a block for too long,
it displays a catching-up progress bar in the graphical [user
interface][bcc user interface] or a warning message in the CLI/API user
interface.
<div class="callout" markdown="block">
Unless you use Bitcoin Core, you can never be sure that your bitcoin balance
is correct according to the block chain.
</div>
### Real Example
In March 2015, spy nodes run by the company Chainalysis accidentally
prevented some users of the lightweight BreadWallet from connecting to
honest nodes. Since the spy nodes didn't relay transactions, BreadWallet
users stopped receiving notification of new transactions.
**Learn more:** [Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network](http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/)
</td>
</tr>
<tr class="brief">
<td><span class="ui-button-icon-primary ui-icon ui-icon-triangle-1-e"></span>Chain rewrites</td>
<td class="bgred"></td>
<td class="bgred"></td>
<td class="bgred"></td>
</tr>
<tr class="details">
<td colspan="4" markdown="block">
> Mallory gives Alice 1,000 bitcoins. When Alice's wallet says the
> transaction is confirmed, Alice gives Mallory some cash. Later Alice
> discovers that Mallory has managed to steal back the bitcoins.
This attack applies to **all Bitcoin wallets.**{:.fgred}
The attack works because powerful miners have the ability to rewrite the
block chain and replace their own transactions, allowing them to take
back previous payments.
The cost of this attack depends on the percentage of total network hash
rate the attacking miner controls. The more centralized mining becomes,
the less expensive the attack for a powerful miner.
![The cost of a chain rewrite](/img/bitcoin-core/en-confirmed-double-spend-cost.svg)
### Real Example
In September 2013, someone used centralized mining pool GHash.io to
steal an estimated 1,000 bitcoins (worth $124,000 USD) from the gambling
site BetCoin.
The attacker would spend bitcoins to make a bet. If he won, he would
confirm the transaction. If he lost, he would create a transaction
returning the bitcoins to himself and confirm that, invalidating the
transaction that lost the bet.
By doing so, he gained bitcoins from his winning bets without losing
bitcoins on his losing bets.
Although this attack was performed on unconfirmed transactions, the
attacker had enough hash rate (about 30%) to have profited from
attacking transactions with one, two, or even more confirmations.
**Learn more:** [GHash.IO and double-spending against BetCoin
Dice][ghash betcoin double spend]
</td>
</tr>
</table>
Note that although all programs---including Bitcoin Core---are
vulnerable to chain rewrites, Bitcoin provides a defense mechanism: the
more confirmations your transactions have, the safer you are. *There is
no known decentralized defense better than that.*
## Help Protect Decentralization
{% comment %}<!-- 1231006505 is the time in block 0; 31558149 is the average number of seconds in a year -->{% endcomment %}
{% capture bitcoin_age %}{{ site.time | date: "%s" | minus: "1231006505" | divided_by: "31558149" }}{% endcapture %}
The bitcoin currency only works when people accept bitcoins in exchange
for other valuable things. That means it's the people accepting
bitcoins who give it value and who get to decide how Bitcoin should work.
When you accept bitcoins, you have the power to enforce Bitcoin's rules,
such as preventing confiscation of any person's bitcoins without access
to that person's private keys.
Unfortunately, **many users outsource their enforcement power**. This
leaves Bitcoin's decentralization in a weakened state where a handful of
miners can collude with a handful of banks and free services to change
Bitcoin's rules for all those non-verifying users who outsourced their power.
<table class="received_transactions center">
<tr>
<td class="center" markdown="span">*Users of Bitcoin banks*<br
>**Trust bankers**{:.fgred}</td>
<td class="center" markdown="span">*Users of P2P lightweight wallets*<br
>**Trust miners**{:.fgred}</td>
</tr>
<tr>
<td class="center" markdown="span">*Users of client lightweight wallets*<br
> **Trust "free" services**{:.fgred}</td>
<td class="center" markdown="span">*Users of Bitcoin Core*<br
>**Enforce the rules**{:.fggreen}</td>
</tr>
</table>
Unlike other wallets, **Bitcoin Core *does* enforce the rules**---so
if the miners and banks change the rules for their non-verifying
users, those users will be unable to pay full validation Bitcoin Core
users like you.
As long as there are many non-verifying users who want to be able to
pay Bitcoin Core users, miners and others know they can't effectively
change Bitcoin's rules.
But what if not enough non-verifying users care about paying Bitcoin
Core users? Then it becomes easy for miners and banks to take control of
Bitcoin, likely bringing to an end this {{bitcoin_age}} year experiment
in decentralized currency.
![History of Bitcoin](/img/bitcoin-core/history-of-bitcoin.svg)
If you think **Bitcoin should remain decentralized,** the best thing you
can do is [validate every payment you receive](#do-you-validate) using your own personal
full node such as Bitcoin Core.
We don't know how many full validation users and business are needed,
but it's possible that for each person or business who validates their
own transactions, Bitcoin can remain decentralized even if there are ten
or a hundred other non-verifying users. If this is the case, **your
small contribution can have a large impact** towards keeping Bitcoin
decentralized.
## Do You Validate Your Transactions? {#do-you-validate}
Some people confuse [supporting the network][bcc network support] with
helping to [protect Bitcoin's decentralization][bcc validation
decentralization].
To [improve your security][bcc validation protection] and help
protect decentralization, you must use a wallet that fully validates
received transactions. There are three ways to do that with Bitcoin
Core right now:
1. **Use the built-in wallet's graphical mode.** If you request payment
using the following screen in Bitcoin Core, your received
transactions will be fully validated.
![Bitcoin Core request payment](/img/bitcoin-core/unique-invoice.png)
2. **Use Bitcoin Core as a trusted peer for certain lightweight
wallets.** Learn more on the [user interface][bcc user interface
lightweight] page. If you use a secure connection to your personal
trusted peer *every time* you use the wallet, your received
transactions will be fully validated.
3. **Use the built-in wallet's CLI/API interface.** This is meant for
power users, businesses, and programmers. The [user interface][bcc
user interface] page provides an overview, the [installation
instructions][bandwidth sharing guide] can help you get started, and
the [RPC][]/[REST][] documentation can help you find specific
commands. If you're using [`getnewaddress`][rpc getnewaddress] to
create receiving addresses, your received transactions will be fully
validated.
If you have any questions, please ask on the [forums][bcc forums] or
[chatrooms][bcc live help].
<br class="clear big">
<div class="prevnext">
<span markdown="1">**Previous Feature**<br>[Feature Overview][bcc main]</span>
<span markdown="1">**Next feature**<br>[Privacy][bcc privacy]</span>
</div>
<br class="clear">
<div class="not-displayed">
<div id="bitcoin_banks" title="Bitcoin Banks" markdown="block">
**Bitcoin banks and exchanges** are organizations that control your
bitcoins on your behalf similar to the way traditional banks control
your fiat deposits on your behalf.
</div>
<div id="spv_wallets" title="SPV Wallets" markdown="block">
**Simplified Payment Verification (SPV)** wallets are lightweight
wallets that can verify whether or not a transaction is part of a block
without downloading the {{site.text.chain_gb}} GB block chain. However,
they cannot verify whether or not the transaction is actually valid.
(Only full validation nodes like Bitcoin Core can do that.)
Honest miners who only create blocks with valid transactions currently
receive a {{site.text.subsidy_in_decimal_bitcoins}} bitcoin subsidy.
Dishonest miners who create blocks with invalid transactions don't
receive that subsidy, but they might still attempt to trick SPV
wallets if they can steal more bitcoins than they would make honestly (or
steal any amount of bitcoins from people they don't like).
</div>
</div>
{% include references.md %}

85
en/bitcoin-core/help.md
View file

@ -1,85 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: en
id: bitcoin-core-help
columns: 1
title: Get Help - Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- Help
end_of_page: |
<script src="/js/devsearch.js"></script>
---
# Getting Help For Bitcoin Core
There are many ways to get help for Bitcoin Core, including
[documentation](#documentation), [forums](#forums), and [live chatrooms](#live).
<span class="fa fa-exclamation-triangle"></span> *To report an issue,
please see the [bug reporting][bcc contribute issues] page.*
## Documentation
Bitcoin Core currently doesn't have any cohesive or complete
documentation---but we hope to improve that situation soon. For now, you
can use the following resources:
- Bitcoin Wiki pages: [running Bitcoin][bcc configuration], [data
directory][bcc data directory], and other articles in the [Bitcoin
Core documentation category][wiki bitcoin core documentation].
<form id="searchform" action="https://en.bitcoin.it/w/index.php">
<input id="searchInput" class="glossary_term" type="search" placeholder="Search the Bitcoin Wiki" name="search"></input>
</form>
- The [developer reference][RPCs] provides complete documentation of the
RPCs that can be used with `bitcoin-cli` or in third-party programs.
The [REST][rest] interface is also fully documented. Both can be searched
using the box below:
<input id="glossary_term" class="glossary_term" placeholder="Search the RPCs and more">
- The [bandwidth sharing guide][] describes installing Bitcoin Core in
detail as well as opening port 8333 to allow other Bitcoin programs to
download blocks and transactions from you.
## Forums
Bitcoin has a wide range of [communities][communities], but the following places
are the best place to ask for help using Bitcoin Core:
- [Bitcoin StackExchange][] is a community dedicated entirely to
answering questions about Bitcoin and related technology. Many
questions about Bitcoin Core can be found under the [Bitcoin-Qt
tag](http://bitcoin.stackexchange.com/questions/tagged/bitcoin-qt)
- [BitcoinTalk Technical Support][forum tech support] is a
sub-forum dedicated to providing help for Bitcoin Core and other
Bitcoin programs.
- [/r/BitcoinBeginners][bitcoin beginners] is a Reddit community for
users who have questions about anything Bitcoin-related, including
Bitcoin Core.
## Live
Internet Relay Chat (IRC) is the most popular way to get live online
help with Bitcoin Core. When you join an IRC chatroom, you must read
the topic (which is usually automatically displayed) to learn the rules
for that chatroom.
- [#bitcoin][] is the best place to ask general questions about
Bitcoin Core.
- [#bitcoin-mining][] hosts discussion about Bitcoin mining, including
decentralized mining using Bitcoin Core as part of the system.
- For more channels, please see the [comprehensive listing][irc channels]
on the Bitcoin Wiki.
{% include references.md %}

94
en/bitcoin-core/index.md
View file

@ -1,94 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
id: bitcoin-core-overview
columns: 1
lang: en
title: Bitcoin Core
breadcrumbs:
- bitcoin
- Bitcoin Core
---
# Bitcoin Core
{:.not-displayed}
![Bitcoin Core: Helping You Keep Bitcoin Decentralized](/img/bitcoin-core/en-big-logo.svg)
<br class="clear">
{% include bitcoin-core/download-bitcoin-core.html %}
<br class="clear">
<div class="show_less_more">
<div class="show_less" markdown="block">
Bitcoin Core is programmed to decide which block chain contains
valid transactions. The users of Bitcoin Core only accept
transactions for that block chain, making it the Bitcoin block
chain that everyone else wants to use
</div>
<div class="show_more" markdown="block">
It is these users who <b>keep Bitcoin decentralized.</b> They
individually run their own Bitcoin Core full nodes, and each of
those full nodes separately follows the exact same rules to decide
which block chain is valid.
There's no voting or other corruptible process involved: there's
just individual software following identical rules—"math"—to
evaluate identical blocks and coming to identical conclusions
about which block chain is valid.
This shared agreement (called consensus) allows people like you to
only accept valid bitcoins, <b>enforcing Bitcoin's rules</b> against
even the most powerful miners.
In addition to improving Bitcoin's decentralization, Bitcoin Core users get
[better security][bcc validation]
for their bitcoins,
[privacy features][bcc privacy]
not available in other wallets, a choice of
[user interfaces][bcc user interface]
and several other powerful features.
</div>
<p class="center"><button class="toggle_show_more_less js not-displayed"><span class="fa fa-caret-down"></span> Read more</button></p>
</div>
<br>
<div markdown="block" class="two-column-list">
{:.fa-ul}
- <span class="fa-li fa fa-download fa-2x"></span>
<b>[Download][bcc download]</b><br
>Download Bitcoin Core&nbsp;{{ site.DOWNLOAD_VERSION }}
- <span class="fa-li fa fa-rocket fa-2x"></span>
<b>[Features][bcc features]</b><br
>Discover what Bitcoin Core offers
- <span class="fa-li fa fa-question fa-2x"></span>
<b>[Get help][bcc help]</b><br
>Documentation, forums, chat rooms
- <span class="fa-li fa fa-code-fork fa-2x"></span>
<b>[Contribute][bcc contribute]</b><br
>Code, translations, and more
</div>
<br class="clear">
### News
<br class="clear">
<script>
if ( $( window ).width() > 400 && $( window ).height() > 600 ) {
$(".show_more").removeClass("show_more");
$(".toggle_show_more_less").removeClass("toggle_show_more_less");
}
</script>
{% include references.md %}

1555
en/full-node.md
View file

File diff suppressed because it is too large Load diff

37
es/bitcoin-core/2016-01-07-statement.md
View file

@ -1,37 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: es
id: bitcoin-core-2016-01-07-statement
columns: 1
title: Declaración de Bitcoin Core -- 2016-01-07
breadcrumbs:
- bitcoin
- bcc
- 2016-01-07 Statement
moved_url: "https://bitcoincore.org/es/2016/01/07/declaraci%C3%B3n/"
---
# Declaración de Bitcoin Core
Bitcoin es una «versión peer-to-peer de efectivo electrónico que permite mandar pagos online directamente entre personas sin necesidad de utilizar una institución financiera». Nuestra visión para Bitcoin es aumentar la flexibilidad del sistema para que funcione eficientemente a escala masiva mientras manteniendo la seguridad y las propiedades básicas de decentralización que distinguen a Bitcoin.
Creemos que Bitcoin puede lograr esto mediante el establecimiento de una base sobre la cual se pueden construir capas adicionales al protocolo y interfaces con otros sistemas. Además, nuestras metas a largo plazo incluyen proteger y mejorar la privacía de usuarios de Bitcoin.
«Bitcoin Core» se refiere a un proyecto de software de código abierto que es descendiente directo de la implementación original de Bitcoin. Como contribuyentes al proyecto, mantenemos y lanzamos software para la consideración de la comunidad de Bitcoin. Esforzamos para hacer mejoras a las reglas del consenso a base de proponer actualizaciones que creemos que tienen sentido técnico basado en nuestro entendimiento de las metas de Bitcoin y que creemos que tienen buena probabilidad de soporte y adopción masivo.
Cambios a las reglas del consenso de Bitcoin se pueden realizar a través de soft forks o hard forks (ver el Apéndice A). Soft forks permiten cambios compatibles. Con soft forks, software viejo y nuevo puede coexistir en el network. Soft forks pueden introducir nuevas funciones sin disrupción porque los usuarios que quieren utilizarlas pueden actualizarse mientras los que no quieren pueden seguir normalmente.
Hard forks rompen compatibilidad de todo el software de Bitcoin anterior y requieren que todos los participantes se actualizen a las mismas reglas por dada fecha o arriesguen pérdida financiera. Estos eventos pueden dañar los efectos de red, echando para afuera a usuarios si no toman acción y potencialmente rompiendo software y aplicaciónes dependientes del sistema.
Por estas razones, Bitcoin Core fuertemente favorece compatibilidad y cree que cada usuario debe poder elegir no actualizar las reglas de su software de Bitcoin. Casi cualquiera función nueva se puede agregar con soft fork. A veces hard forks pueden tener beneficios, y si hay acuerdo casi universal, estos beneficios pueden superar a las desventajas. Excepto para estos casos, soft forks serán preferidos. Creemos que esto es en el mejor interés de los usuarios actuales y futuros del sistema.
También se espera que a la medida que el ecosistema de Bitcoin vaya creciendo, el número de implementaciones alternativas del protocolo de Bitcoin aumentará. Es inevitable que otros proyectos hagan propuestas radicalmente diferentes a las nuestras para la consideración de la comunidad. Al fin de cuentas, los desarrolladores de Bitcoin Core no decide las reglas del consenso de Bitcoin. Sino, los usuarios que participan en Bitcoin eligen cual software usar. Por esto, el software de Bitcoin Core intencionalmente excluye función de actualización automática. Su omisión asegura la participación voluntaria de todos en cada cambio para que todos siempre tengan libre la opción de cual software usar.
## Apéndice A
Un hard fork es un cambio en las reglas del consenso en el cual bloques inválidos bajo las reglas viejas podrán ser válidos bajo las nuevas reglas.
Un soft fork es un cambio en las reglas del consenso en el cual bloques válidos bajo las reglas viejas podrán ser inválidos bajo las nuevas reglas pero todos los bloques inválidos bajo las reglas viejas siguen siendo inválidos bajo las nuevas reglas.

391
it/bitcoin-core/capacity-increases-faq.md
View file

@ -1,391 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: it
id: bitcoin-core-capacity-increases-faq
columns: 1
title: FAQ sugli Aumenti di capacità — Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- Capacity increases FAQ
moved_url: https://bitcoincore.org/it/2015/12/23/capacity-increases-faq/
---
# Domande frequenti sugli aumenti di capacità
1. Indice
{:toc}
## Quali tecnologie specifiche sono incluse nella roadmap, e per quando possiamo aspettarcele? {#roadmap-dates}
La nuova tecnologie verrà messa in campo quando sarà pronta e avrà
passato i test.
Comunque, pensiamo che la seguente sia una pianificazione ragionevole
per i miglioramenti specifici descritti nella [roadmap][]
| Dec 2015 | | Messa in campo di Segregated witness in testnet |
| Feb 2016 | 0.12.0 | [libsecp256k1 verification][] |
| Feb 2016 | | la funzionalità segregated witness è completata & pronta per la recensione generale|
| Mar 2016\* | 0.12.x | Messa in campo di OP_CHECKSEQUENCEVERIFY (BIPs [68][BIP68] & [112][BIP112]) + [BIP113][] as first [BIP9][] versionbits soft fork |
| April 2016\* | 0.12.x | Messa in campo di segregated witness |
| 2016 | | Weak blocks, IBLTs, oppure entrambi |
\* Le date con l'asterisco rappresentano quelle in cui ci aspettiamo di rilasciare il codice pronto per un soft-fork. Il codice non sarà rilasciato fino a quando non è stato ben recensito, e l'effettivo fork richiederà tempo per essere attivato ([BIP66][] si attivò nel luglio 2015 dopo qualche mese; [BIP65][] si attivò nel dicembre 2015 dopo sole 5 settimane).
- **Segregated witness testnet:** Una testnet separata (non parte
della testnet regolare) che fornisce un'opportunità ai contribtori di
Bitcoin Core di testare segregated witness (testimonianza segregata ndt) e
agli sviluppatori di wallet di cominciare a lavorarci sopra.
- **Verifica [Libsecp256k1][]:** Aumento di velocità dal 500% to 700% su
hardware x86\_64 durante la verifica per aiutare i full nodes a unirsi alla
rete e per allegerire il peso dei nodi esistenti.
- **[OP\_CHECKSEQUENCEVERIFY][BIP112]:** miglioramento del 25,000% nell'
[efficienza dei payment channels][payment channel efficiency] bi-direzioionali
attraverso la possibilità per gli utenti di lasciare il canale aperto quanto
lo desiderano.
- **[VersionBits][BIP9]:** aumenta il numero dei softforks che è possibile
mettere in campo. Da 1 a 29 rilasci di nuove versioni simultaneamente, questo
permette più veloci e più decentralizzati miglioramenti futuri del network.
- **[Segregated witness][bip-segwit]:** Aumento diretto di capacità dal 175%
al 400%, miglioramento addizionale del 66% nell'efficienza dei canali
bi-direzionali di pagamento attraverso il consolidamento delle operazioni
di apertura e di chiusura del canale, la fine delle malleabilità di terze
parti che pregiudicano la messa in campo degli smart contracts, le fraud
proofs per permettere ai clients leggeri di contribuire in modo più efficace
al rafforzamento delle verifiche di tipo economico, e la possibilità di
migliorare il linguaggio di Scripting di Bitcoin in modo che nuovi e più
potenti smart contracts possano essere concepiti.
- **IBLTs e weak blocks:** Diminuzione del 90% o maggiore della larghezza
di banda critica necessaria per distribuire i blocchi creati dai miners
che necessitano di essere propagati in fretta con un modesto
[aumento della banda utilizzata][increase in total bandwidth], portando
molti dei benefici del [Bitcoin Relay Network][] a tutti i full nodes.
Questo miglioramento è ottenuto spalmando l'utilizzo della banda utilizzata
dai full nodes nel tempo il che significa che IBLT e weak blocks potrebbero
permettere aumenti più sicuri della massima dimensione del blocco.
## La segregated witness è equivalente a un soft fork che porta la massima dimensione del blocco a 4MB, a 2MB, a 1,75MB o cosa? Continuo a sentire cifre diverse. {#segwit-size}
Nella [Proposta corrente][current proposal] per il soft fork segregated witness
(segwit) ogni byte del witness occupa 0.25 bytes corrispondenti
nel computo dello spazio limite del blocco, il che significa che il limite
massimo del blocco corrisponde teoricamente a poco meno di 4MB.
I blocchi però non sono costituiti solo da dati di witness e ciascun byte
non witness conta 1.00 bytes nei confronti del limite massimo del blocco,
per questa ragione i blocchi vicini ai 4MB di grandezza sono improbabili.
Secondo alcuni [calcoli][calculations] fatti da Anthony Towns, un blocco
pieno solamente di transazioni P2PKH a firma singola standard sarebbe circa
1.6MB e un blocco pieno solo di firme multiple 2-di-2 sarebbe di 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 sembra complicata. Sarà pronto l'ecosistema per la sua messa in campo? {#ecosystem-ready}
Alcune idee sono facili da spiegare ma difficili da realizzare. Altre idee
sono facili da realizzare ma difficili da spiegare. Segregated witness sembra
essere un'idea di quest'ultimo tipo.
Segwit può essere messa in campo in manera incrementale senza rompere la
compatibilità, per cui non è necessaria alcuna significativa preparazione da
parte dell'ecosistema. Gli sviuppatori che vogliono farsi un'esperienza
"sporcandosi le mani" possono cominciare a testare il loro software nella
testnet segwit che verrà messa in campo nel dicembre 2015.
Inizialmente solo i miners che vogliono supportarla dovranno fare l'upgrade
per attivarla e rafforzarla sulla mainnet. Le applicazioni esistenti dovranno
cambiare solo se vorranno approfittare delle nuove funzionalità.
Le transazioni Segregated witness esigeranno meno commissioni, potranno
usufruire di maggiori ottimizzazioni di performance, e potranno supportare gli
smart contracts multistage e i protocolli come i payment channels bi-direzionali
che possono permettere alla rete di scalare senza aggravio di ulteriori dati
per la Blockchain.
I wallet sono fortemente incoraggiati ad aggiornarsi ma possono continuare a
operare senza modifiche in quanto la messa in campo non rompe la conpatibilità
all'indietro.
## Segregated witness sembra ancora complessa. Perchè semplicemente non aumentare la dimensione massima del blocco? {#size-bump}
C'è un [unica riga di codice][max_block_size] in Bitcoin Core che dice che la
dimensione massima del blocco è di 1,000,000 di bytes (1MB). Il cambiamento
più semplice consisterebbe in un hard fork per aggiornare quella riga, per
esempio a 2,000,000 di bytes (2MB)
Gli Hard Forks tuttavia sono tutt'altro che semplici:
- **Non abbiamo esperienza:** I Miners, i negozianti, gli sviluppatori e gli
utenti non hanno mai messo in atto un Hard fork, per questa ragione tecniche
per farlo in modo affidabile non sono mai state testate.
Questo a differenza dei soft forks, le cui messe in campo furono
inizialmente gestite da Nakamoto, in quelle occasioni abbiamo raccolto
abbastanza esperienza dalle complicazioni del [BIP16][], abbiamo
raffinato la tecnica nella messa in campo del [BIP34][], e abbiamo
acquisito sufficienti esperienze con i BIPs [66][BIP66] e [65][BIP65] per
cominciare a gestire soft forks multipli in futuro con i bits di versione
del [BIP9].
- **L'Upgrade è obbligatorio:** Gli Hard forks necessitano che tutti i nodi
facciano l'upgrade. Compresi gli operatori dei nodi, se utilizzano
questi per proteggere il loro wallet, come anche i client leggeri che
ottengono i dati dai nodi.
- **Altri cambiamenti sono obbligatori:** Anche un cambiamento da una singola
riga di codice come quella che aumenta la dimensione massima del blocco ha
effetti su altre parti del codice, alcuni dei quali indesiderati. Ad esempio
oggi è possibile costruire una transazione che occupa quasi un 1MB di spazio e
che richiede 30 secondi o più su un computer moderno per essere validata (
blocchi contenenti transazioni del genere sono effettivamente stati minati).
Nei blocchi da 2MB, può essere costruita una transazione da 2MB che potrebbe
impiegare oltre 10 minuti per essere validata il che apre dei vettori di
attacco basati sul denial of service. Altre linee di codice dovrebbero essere
cambiate per prevenire questo tipo di attacchi.
Nonostante queste non indifferenti complessità, con le sufficienti
precauzioni, nessuna di queste complicazioni sembra fatale per un hard fork, e
noi ci aspettiamo in effetti di andare incontro ad hard forks in futuro. Con
Segregated Witness (segwit) però abbiamo un soft fork, simile ad altri soft
forks che abbiamo fatto in passato e coi quali abbiamo accresciuto le nostre
esperienze nella distribuzione e che ci fornisce in aggiunta molti benefici
permettendo che un maggior numero di transazioni sia aggiunta alla Blockchain.
Segwit non richiede cambiamenti ulteriori nella parte più alta degli strati
del software rispetto a un semplice aumento della misura massima del blocco,
ma se davvero vogliamo vedere scalare il Bitcoin, cambiamenti molto più
invasivi saranno necessari comunque, e segwit incoraggerà gentilmente la gente
a fare l'upgrade verso modelli più scalabili senza forzarli.
Gli sviluppatori, i miners, e la comunità hanno acquisito una significativa
esperienza mettendo in campo i soft forks, e noi crediamo che segwit può
essere messo in campo almeno altrettanto velocemente, e probabilmente in modo
più sicuro, rispetto ad un hard fork che aumenti la massima dimensione del
blocco.
## Ci sarà un hard fork prima o come parte della messa in funzione della segregated witness? {#pre-segwit-fork}
No. Questo non è parte della [roadmap][].
[roadmap]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
## Se ci sarà comunque un hard fork, perché non farlo adesso? {#why-not-now}
Abbiamo attualmente la capacità di aumentare la capacità del sistema attraverso
soft forks che hanno un vasto consenso senza le implicazioni di un hard fork,
come descritto in [una precedente domanda][q simple raise], per cui
l'aspettativa del fatto che ci sarà un hard fork in futuro non è una ragione
sufficiente per farlo ora.
Oltre a darci una maggiore capacità in termini di transazioni, i miglioramenti
proposti nella roadmap (combinati con altre tecnologie come i payment channels
bidirezionali) danno agli utenti la possibilità di ridurre la quantità di
spazio blockchain che usano mediamente---aumemntando in effetti la capacità
del sistema Bitcoin senza aumentare la quantità di banda utilizzata dai full
nodes.
Per esempio:
- [BIP68][] e [BIP112][] permettono ai payment channels bi-direzionali
di stare aperti indefinitamente, il che ci aspettiamo riduca il numero
di transazioni dei payment channels che devono essere confermate sulla
blockchain.
- Segregated witness permette alla transazione di chiusura di un payment
channel di combinarsi con una transazione di apertura di un altro payment
channel riducendo lo spazio della blockchain utilizzato per cambiare
canale di circa il 66%.
- Segregated witness permette ai soft forks di cambiare il Liguaggio Di
Scripting del Bitcoin in modi che potrebbero ridurre la dimensione
media di una transazione, per esempio utilizzando il
public-key-recovery-from-signatures o le firme combinate Schnorr.
- Segregated witness permette la creazione di una fraud proof compatta che
potrebbe sollevare il livello di sicurezza dei client leggeri a Verifica
di Pagamento Semplificata (SPV) fino a un livello vicino a quello dei
full nodes, il che potrebbe permettere alla rete di funzionare bene con
un numero inferiore di full nodes rispetto a quanto avviene con la tecnologia
attualmente in uso.
L'effetto reale di queste tecnologie è sconosciuto, ma scalare ora attraverso
un soft fork che gode di un largo consenso ci permette di ottenere i vantaggi
immediati, testare e misurare le potenzialità di medio termine, e usare questi
dati per i piani di lungo periodo.
## Come funzionerà la segregated witness per i wallets? {#segwit-in-wallets}
I wallets che suppartano P2SH possono migrare completamente alla segregated
witness in due fasi:
- Phase 1: Gli scripts subiscono l'operazione di hash due volte, la prima a 256
bits e poi a 160 bits. L'hash a 160 bits sarà compatibile con gli indirizzi
P2SH esistenti, in questo modo i wallet saranno in grado di mandare e ricevere
bitcoins a e da wallets attualmente esistenti.
- Phase 2: Gli script subiscono una sola operazione di hash a 256 bits.
Questo formato non sarà compatibile con i wallets esistenti ma permetterà
una più efficiente allocazione dello spazio nel blocco e offrirà una migliore
sicurezza per merito di una migliore resistenza alla collisione.
## Se nessuno è obbligato a fare l'aggiornamento perchè ci si dovrebbe preoccupare di farlo? Ho sentito che il P2SH impiegò quasi due anni per essere adottato in maniera diffusa. {#why-upgrade}
Ogni byte della parte witness di una transazione segregated witness (segwit)
occupa uno spazio corrispondente a soli 0.25 bytes in una transazione. Siccome
le commissioni della transazione sono basate sull'ampiezza della transazione,
questo è uno sconto effettivo del 75% sulle commissioni per quella parte di
transazione---ma solo per coloro che utilizzano segwit.
David Harding ha fornito una tabella dei [risparmi stimati][estimated savings]
a vari livelli di commissioni/transazioni. Da questa si rileva, che se la
commissione di una tipica transazione da 250-byte è di 0.01 USD, utilizzando
segwit si risparmieranno circa 0.003 USD quando spendiamo l'output di una
transazione P2PK-in-P2SH.
| Transazione | Bytes risparmiati | $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 |
(Non ci aspettiamo che le commissioni raggiungano i livelli che vediamo in
tabella. Questi sono riportati solo per riferimento.)
I wallet web e gli exchanges che mandano grandi quantità di transazioni ogni
giorno a prezzo fisso (come per esempio gratis oppure con l'1% di commissione
a transazione) tenderanno ad essere early adopters--per loro anche il piccolo
risparmio per spesa riportato nella tabella sopra tende a raggiungere un
ammontare significativo se ripetuto centinaia o migliaia di volte in un giorno.
## Ho sentito che stavate compromettendo le transazioni a zero conferme. Quale tecnologia nella roadmap sulla scalabilità sta permettendo questo? {#rbf}
Nessuna di queste. in condizioni normali, la versione attuale di Core non
rimpiazzerà una transazione non confermata con un'altra transazione che spende
anche uno solo degli stessi inputs. Qualcuno pensa che questo voglia dire che
la prima transazione che si vedono spendere un particolare input sia sicura,
ma questo è falso (se fosse vero, non avremmo bisogno della blockchain.)
Questa attuale policy di default non implica che coloro i quali vogliono
aggiornare le loro transazioni non confermate non possano farlo.
La versione originale di Bitcoin forniva agli utilizzatori un modo per
annunciare che volevano aggiornare una transazione, ma Nakamoto dovette
disabilitarla nel 2010 per scongiurare attacchi di tipo denial-of-service.
Gli sviluppatori recenti del Bitcoin Core hanno capito che potevano prevenire
gli attacchi DOS esigendo che le transazioni aggiornate pagassero commissioni
extra e hanno ripristinato il meccanismo di Nakamoto per indicare quando una
transazione può essere rimpiazzata. Questa funzionalità è prevista per
la versione di Bitcoin Core 0.12.0 (gennaio/febbraio 2016) ma,
come la funzionalità originale di Nakamoto, è facoltativa e gli utenti che
vogliono essere in grado di rimpiazzare la loro transazione devono usare un
wallet che supporti questa funzione.
Attualmente non ci sono wallet che supportano questa funzione, ma i wallet
che la supporteranno in futuro potranno combinare insieme transazioni multiple
per ridurre lo spazio che queste occupano nella blockchain così come aumentare
le commissioni che pagano su transazioni che stanno impiegando molto tempo per
la conferma, evitando che le transazioni rimangano sospese (un problema di
usabilità noto).
## I weak blocks e IBLTs recano semplicemente "2016" nella pianificazione della roadmap. questo significa che non avete la minima idea di quando saranno disponibili? {#weak-blocks-iblts}
[Weak blocks and IBLTs][] sono due tecnologie separate che sono ancora
[studiate intensamente][actively studied] per scegliere i giusti paramentri ma
il numero di sviluppatori che lavorano su di esse è limitato per questo è
difficile stimare quando saranno realizzate.
Weak blocks e IBLTs possono essere entrambe messe in campo come miglioramenti
di rete puri (non sono richiesti forks nè soft nè hard) il che significa che
ci sarà solo un breve lasso di tempo tra il completamento della fase di test al
momento in cui i loro benefici saranno disponibili a tutti i nodi che
avranno fatto l'upgrade. Noi speriamo che ciò avvenga nel corso del 2016.
Dopo la messa in campo, entrambi Weak Blocks e IBLTs potrebbero beneficiare
di un piccolo soft fork
([l'ordinamento canonico di transazione][canonical transaction ordering]), che
dovrebbe essere facile da attuare utilizzando il sistema versionbits del
[BIP9][] descritto altrove in questa FAQ.
[canonical transaction ordering]: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions
## Perchè i miners dovrebbero adottare segwit, visto che non fornisce alcun risparmio di banda, storage, o tempo di processamento per loro? {#why-mine-segwit}
Neanche la maggior parte dei [soft forks precedenti][previous soft forks] ha
procurato ai miners benefici in questi termini. Ad esempio:
| [BIP16][] (P2SH) | Nuovo tipo di transazione |
| [BIP30][] (duplicate txids) | Controllo richiesto per i txids duplicati |
| [BIP34][] (height in coinbase) | Ridotto lo spazio a disposizione del miner per la coinbase di 4 byte |
| [BIP65][] (OP_CLTV) | Nuovo opcode |
Il soft fork relativo al [BIP66][] (strict DER) che si attivò nel Luglio 2015
fornì immediatamente tempi di processamento ridotti rendendo possibile il
passaggio a libsecp256k1 per la validazione come descritto da qualche altra
parte in questa FAQ. La riduzione del tempo di verifica fa di questo
soft fork una gradita novità in quanto fornisce immediati vantaggi ai miners.
Ciò che fa Segregated Witness (segwit) è fornire vari benefici importanti
a chiunque lo utilizzi per creare transazioni:
Un rimedio permanente per la malleabilità che permette agli smart contracts
a più stage di fiorire, una lieve riduzione delle commissioni, facili
aggiornamenti futuri del Linguaggio di Scripting Bitcoin che permettono ai
wallet di avere accesso a nuove funzionalità.
Attraverso i soft forks e atraverso discussoni come quella della
[sessione dei miners][Miners' Panel] allo Scaling Bitcoin di Hong Kong, i
miners hanno ripetutamente dimostrato che vogliono che il Bitcoin sia il
più utile sistema possibile anche se non dovessero ricevere nessun beneficio
diretto da questo. Segwit e altri miglioramenti nella roadmap forniscono
significativi avanzamenti di usabilità.
In aggiunta, segwit permette ai miners di mettere più transazioni nei loro
blocchi il che permette di aumentare i loro ricavi per blocco minato.
## Come posso contribuire?
Comincia con il leggere la pagina del
[contributor di Bitcoin Core][Bitcoin Core contributor] su Bitcoin.org.
in particolare, la [revisione del codice][code review] è una parte critica nel
mettere in atto i soft fork.
Per ricevere suggerimenti specifici su come si può contribuire, unisciti
al canale IRC [#bitcoin-dev][].
[#bitcoin-dev]: https://webchat.freenode.net/?channels=bitcoin-dev&amp;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]: /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

38
it/bitcoin-core/capacity-increases.md
View file

@ -1,38 +0,0 @@
---
# 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: Aumenti di capacità per il sistema Bitcoin -- Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- Capacity increases
moved_url: https://bitcoincore.org/it/2015/12/21/capacity-increase/
---
# Aumenti di capacità per il sistema Bitcoin
Noi, i firmatari, supportiamo la roadmap in [Capacity increases for the
Bitcoin system.][1] Abbiamo lavorato sulla scalabilità per
molti anni all'interno del progetto Bitcoin Core e consideriamo
questa la migliore possibile continuazione dei nostri sforzi.
Per maggiori informazione prego consultare
[FAQ](/it/bitcoin-core/capacity-increases-faq).
{% include bitcoin-core/capability-increases-sigs.md %}
---
Altre versioni di questa pagina:
- [简体中文](/zh_CN/bitcoin-core/capacity-increases)
- [繁體中文](/zh_TW/bitcoin-core/capacity-increases)
Le firme possono essere aggiunte alla pull request di Bitcoin.org [#1165](https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165)
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

38
ru/bitcoin-core/2016-01-07-statement.md
View file

@ -1,38 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: ru
id: bitcoin-core-2016-01-07-statement
columns: 1
title: Сообщение от Bitcoin Core -- 2016-01-07
breadcrumbs:
- bitcoin
- bcc
- 2016-01-07 Statement
moved_url: "https://bitcoincore.org/ru/2016/01/07/c%D0%BE%D0%BE%D0%B1%D1%89%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BE%D1%82-bitcoin-core/"
---
# Сообщение от Bitcoin Core 2016-01-07
Bitcoin является “пиринговой электронной валютой, позволяющей совершать онлайн-платежи напрямую между участниками минуя финансовые организации”. Наше видение развития Bitcoin — это повышение гибкости системы, позволяющее достичь её эффективной работы в условиях предельно высокого количества транзакций без ущерба для безопасности и уникальных фундаментальных принципов децентрализации.
Мы уверены в том, что эти цели достижимы путём создания фундаментальной основы для развития надстроек, дополняющих протокол Bitcoin, и интерфейсов с другими системами. Наши долгосрочные цели также включают обеспечение защиты и конфиденциальности использования Bitcoin.
"Bitcoin Core" — это название проекта открытого программного обеспечения, основанного на изначальной реализации Bitcoin. Задача участников проекта — это поддержка и выпуск общедоступных версий Bitcoin. Мы сосредоточены на улучшении протокола системы путём внесения изменений, отвечающих критериям технической целесообразности, соответствия целям Bitcoin и глобальной приемлемости для пользователей системы.
Изменения параметров системы вступают в силу по алгоритму soft fork либо hard fork (см. приложение A). Алгоритм soft fork позволяет вносить изменения, не прерывая работу как старых так и новых узлов системы, что позволяет обновлять программное обеспечение Bitcoin только тем узлам, которые хотели бы использовать новые функции, при этом не нарушается функционирование необновившихся узлов.
Алгоритм hard fork делает обновившиеся и не обновившиеся узлы системы несовместимыми; каждый участник системы должен обновить своё программное обеспечение Bitcoin до заранее назначенного момента времени во избежание финансовых потерь. Не обновившиеся вовремя узлы выпадают из сети Bitcoin, чем ослабляют её. Кроме того, стороннее программное обеспечение, работающее с необновившимися узлами, может перестать функционировать корректно.
В связи с этим Bitcoin Core считает наиболее важным фактором совместимость и считает использование либо неиспользование новейших правил протокола Bitcoin выбором каждого пользователя. Существует техническая возможность производить большую часть изменений протокола по алгоритму soft fork. Однако, иногда hard fork имеет преимущества перед soft fork, в таких случаях, при согласии большей части сообщества, такие преимущества считаются решающими. За исключением подобных нечастых случаев, предпочтителен soft fork. Мы считаем такой подход наиболее отвечающим интересам текущих и будущих пользователей системы.
По мере роста экосистемы Bitcoin, веротяно, будет появляться больше и больше альтернативных систем, работающих по протоколу Bitcoin. В таком случае разработчики альтернативных систем неизбежно будут предлагать существенные изменения в протоколе. Принятие или непринятие таких изменений — задача и ответственность не разработчиков Bitcoin Core, но пользователей Bitcoin. Именно по этой причине Bitcoin Core не включает в себя функцию автообновления: решая, какую версию Bitcoin использовать, пользователи активно участвуют в принятии или непринятии изменений в протокол.
## Приложение A
Алгоритм hard fork - это изменение в правила согласованности, при котором блоки, некорректные по старым правилам, могут стать корректными по новым.
Алгоритм soft fork - это изменение в правила согласованности, при котором блоки, корректные по старым правилам, могут стать некорректными по новым, но все блоки, некорректные по старым правилам, остаются некорректными и по новым.

39
zh_CN/bitcoin-core/2016-01-07-statement.md
View file

@ -1,39 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: zh_CN
id: bitcoin-core-2016-01-07-statement
columns: 1
title: Bitcoin Core 声明 -- 2016-01-07
breadcrumbs:
- bitcoin
- bcc
- 2016-01-07 Statement
moved_url: "https://bitcoincore.org/zh_CN/2016/01/07/bitcoin-core-%E5%A3%B0%E6%98%8E/"
---
# Bitcoin Core 声明 -- 2016-01-07
比特币是「点对点电子货币，无需经过任何金融机构，就可以在网上由一人直接付款给另一人」。我们的理想，是把比特币系统的灵活性扩充至可以有效处理极大规模的交易，而同时保障安全以及去中心化的核心性质，因为这是令比特币独一无二的要素。
我们相信比特币要达到这目标，就要在其之上建立多个层次的服务，并与其它系统接合。除此以外，我们的长远目标还包括保护及增加比特币用户的隐私。
「Bitcoin Core」是一个开源软体计划，直接承接了原本的比特币软件设定。作为计划的贡献者，我们为比特币社群维护并发行软件，让用户考虑使用。我们致力改进比特币的共识协定，提出的升级方案，都是按我们所认知的比特币目标所提出，在技术上可行，而且有合理机会被广泛支持并应用。
比特币的共识协定可以透过软分叉或硬分叉改动 (参考附件A)。软分叉容许具兼容性的改动，新旧软件可以在网络上同时存在。通过软分叉来实现新功能不会造成扰乱，因为只有希望使用新功能的用户才需要升级，其它用户可以继续正常使用原有软件。
硬分叉则会破坏对所有现有比特币软件的兼容性，所有用户必须在指定期限前升级，否则会有损失金钱的风险。这情况可能逼使不升级的用户离开网络，并可能令各种下游软件及应用不能运作，对比特币的网络效应造成损害。
由於以上原因，Bitcoin Core 强烈地倾向保持兼容性，并相信应该由每个用户决定是否升级他们正在使用的比特币软件。事实上利用软分叉可以加入几乎任何新功能。在某些情况下，硬分叉可能有些好处，如果能得到几乎一致的同意，这些好处或可以胜过其缺点。但除了这些罕有情况，软分叉仍然是首选。我们相信这是最合乎系统内现在和未来用户的利益。
随着比特币的生态系统的成长，我们也预计会有更多其它运行比特币协定的软件设定，且无可避免地这些软件计划可能会提出彻底不同的方案，让比特币的生态系统作考虑。最终而言，Bitcoin Core的开发团队并不决定比特币的共识规则；相对地，是由比特币用户选择他们自己运行什么比特币软件。因此 Bitcoin Core 刻意地没有自动升级功能，这确保每次升级都是用户自愿进行，令用户可以保持选择运行什么软件的权力。
### 附件 A
硬分叉 是指在更改共识规则後，在旧规则下无效的区块可能会在新规则下变得有效。
软分叉 是指在更改共识规则後，在旧规则下有效的区块可能会在新规则下变得无效，但所有原来是无效的区块仍然保持为无效。

201
zh_CN/bitcoin-core/capacity-increases-faq.md
View file

@ -1,201 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: zh_CN
id: bitcoin-core-capacity-increases-faq
columns: 1
title: 系统扩展常见问题解答 — Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- Capacity increases FAQ
moved_url: "https://bitcoincore.org/zh_CN/2015/12/21/%E7%B3%BB%E7%BB%9F%E6%89%A9%E5%B1%95%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98%E8%A7%A3%E7%AD%94/"
---
# 系统扩展常见问题解答
1. toc
{:toc}
## 路线图包括什么新技术，预期在什么时候可以使用？ {#roadmap-dates}
在[路线图][roadmap]提及到以下的技术，在充分的测试后，预计可以在以下时间完成。
| 2015年12月 | | 隔离见证测试网 |
| 2016年2月 | 0.12.0 | [libsecp256k1验证][libsecp256k1 verification] |
| 2016年2月 | | 隔离见证功能完成并作审核 |
| 2016年3月\* | 0.12.x | 完成OP_CHECKSEQUENCEVERIFY (BIP[68][BIP68] 及 [112][BIP112]) + [BIP113][] 并作为首个以 [BIP9][] versionbits 实施的软分叉 |
| 2016年4月\* | 0.12.x | 完成隔离见证 |
| 2016年 | | 弱区块, IBLTs, 或者二者都实现 |
\* 有星号的日期是预计完成代码的时间。代码只会在充分审核后才会发表，而软分叉完成也需要时间。([BIP66][]经历数月时间在2015年7月生效，[BIP65][]则只用了五周时间在2015年12月生效)
- **隔离见证测试网:** 一个独立的测试网，并非平常测试网的一部分。让 Bitcoin Core 开发员及钱包开发员测试隔离见证功能。
- **Libsecp256k1验证:** 在x86\_64硬件上提升交易验证速度五至七倍。帮助新节点加入网络并减轻现有节点的负担。
- **OP\_CHECKSEQUENCEVERIFY:** 让双向[支付通道][payment channel efficiency]可以无限期使用，提升效率达25倍。
- **VersionBits:** 允许1至29个软分叉同时实施，让系统升级的过程更快，更去中心化。
- **隔离见证:** 允许交易容量上升到1.75至4倍，解决第三方延展性让智能合约更安全，双向支付通道效率提升66%，提供欺诈证明让轻量节点也可以执行系统规则，更容易对脚本系统升级以允许更强大的合约功能。
- **IBLT及弱区块:** 只需要把[总带宽增加少许][increase in total bandwidth]，就可以把区块传播所必须的带宽减低90%以上，让矿工可以在最短时间內把区块传播出去，把[比特币广播网络][Bitcoin Relay Network]的好处带给所有全节点。IBLT及弱区块可以把全节点所需的带宽变得更平均，让将来可以更安全地增加最大区块容量。
## 隔离见证软分叉究竟相当于多少的区块大小增加？我听过不同讲法，如4MB、2MB、1.75MB。 {#segwit-size}
[现在的方案][current proposal]是以软分叉来实现隔离见证，并把每字节的见证内容算为0.25字节，因此最大的区块体积会是稍低于4MB。
然而，区块并不应该只有见证内容，而计算非见证内容的体积时不会有折扣，因此并不可能有4MB的体积。
根据Anthony Towns的[计算][calculations]，如果区块装满了标准的单签名P2PKH交易，体积大概为1.6MB；如果是2-of-2多重签名交易，则大概为2.0MB。
[current proposal]: https://youtu.be/fst1IK_mrng?t=2234
[calculations]: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html
## 隔离见证好像很复杂，比特币生态各环节准备好没有？ {#ecosystem-ready}
有些想法是容易解释但执行很难，有些却是解释很难但执行容易，隔离见证似乎是后者。
由于隔离见证可以逐步实行而不会破坏兼容性，因此生态内各环节无需特别准备。开发员可以在2015年12月推出的测试网得到实际的使用经验并同时测试他们的软件。
最初，只有希望支持隔离见证的矿工需要升级，让新规则可以在主网实行。现有的应用程序只有需要使用新功能才需要改变。
隔离见证交易收取较低交易费，有更佳的性能，而且支持多重签名智能合约，如双向支付通道，可以作大量交易却无需在区块链作额外纪录。我们强烈建议钱包升级，但即使不升级，现有钱包仍然可以继续正常使用。
## 我还是觉得隔离见证很复杂，为什么不简单地提高区块体积？ {#size-bump}
在Bitcoin Core有[一句代码][max_block_size]指定区块最大是 1,000,000 字节 (1MB)。最简单的方法是用硬分叉改变这句代码，例如变为 2,000,000 字节 (2MB)。
但硬分叉本身绝不简单:
- **我们并没有经验:** 矿工，商户，开发员，用户都没有硬分叉的经验，因此让硬分叉可以安全实行的技术也未经测试。
软分叉则不同。软分叉最初由中本聪管理，然后我们又从实行[BIP16][]所遇到的问题中得到经验，让我们以改良了的方法实行[BIP34][]，以及后来的BIP[66][BIP66] 和 [65][BIP65]。在将来的软分叉，我们正准备使用[BIP9][] version bits，让多个软分叉方案可以同时进行。
- **强制升级:** 硬分叉要求所有全节点升级，任何使用旧版本节点的人都可能会损失金钱，这不但包括全节点钱包的运行者本身，还包括依靠该全节点提供数据的轻量钱包。
- **需要其它的改动:** 即使只是改一行代码来增加最大区块容量，也会影响到系统内其它代码，有些更是不良的影响。例如现在可以制造一个接近1MB的交易，而现代的电脑验证该交易需时超过30秒 (这样的交易已存在于区块链上)。在2MB的区块下，验证一个2MB的交易需时10分钟，将成为一个很危险的攻击方法。为了避免这种攻击，就有必要改动其它代码。
虽然有以上的问题，但只要有充足的准备，硬分叉并不会出现致命问题，而我们也预计将来会有硬分叉。但隔离见证可以用我们更熟悉的软分叉完成，而且带来增加交易量以外更多的好处。
和简单提升区块体积相比，隔离见证需要在不同的软件层面作更多改动。但如果我们真的希望比特币可以扩展，我们无论如何也需要根本性的改动，而隔离见证可以逐渐地鼓励人们升级至更具扩展性的方案，却无需强逼他们这样做。
开发员，矿工，以及社群已对软分叉有充分经验，我们相信实行隔离见证所需时间并不比提升容量的硬分叉为多，而且会更安全。
## 在实行隔离见证前会有硬分叉吗？隔离见证方案会本身又会否包括硬分叉？ {#pre-segwit-fork}
不会，这并非[路线图][roadmap]的一部分。
[roadmap]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
## 如果最终还是要硬分叉，为何现在不做？ {#why-not-now}
利用有广泛共识的软分叉，我们能够把系统扩展而没有硬分叉的[副作用][q simple raise]，因此即使预期会有硬分叉，这并不是现在就要做的充分理由。
在路线图提到的改进，除提供额外的交易容量以外，配合其它技术如双向支付通道，可以让用户减少使用区块链，变相提高了比特币系统的容量，却不用增加全节点使用的带宽。例如：
- [BIP68][] 及 [BIP112][] 允许无限期的双向支付通道，可以大为减少纪录在区块链的交易。
- 隔离见证允许在关闭支付通道的同时开设新的支付通道，减少因为更换通道所需的区块链空间约66%。
- 隔离见证允许将来更容易以软分叉改变比特币的脚本语言，例如从签名提取公钥，或使用Schnorr联合签名算法，从而减少交易的平均大小。
- 实行隔离见证后，当无效区块出现时就可以产生很简洁的欺诈证明，这会让进行简单交易验证 (SPV) 的轻量节点的安全性更接近全节点，可以让整个网络在较少的全节点下仍能运作。
这些技术的实际效果仍然未知，但实行一个具广泛共识的软分叉可让我们立即得益并且测试和评估中期的可能性，以及用这些数据作长期的规划。
## 钱包会如何使用隔离见证？ {#segwit-in-wallets}
现在支持 P2SH 的钱包可以分两阶段转移至完整的隔离见证：
- 第一阶段：脚本需要经过两次哈希运算，首先是变成256字节，然后再变成160字节。这个160字节的哈希和现有的P2SH地址兼容，因此已升级的钱包和现有的钱包之间可以互相收付款项。
- 第二阶段：脚本只需一次哈希运算变为256字节。这格式和现有钱包不相容，但允许更有效率地使用区块空间，及提供更强的防碰撞攻击性能。
## 如果没有人被逼升级，为何会有人升级？听说P2SH用了差不多两年时间才得到广泛应用。 {#why-upgrade}
在隔离见证交易中，见证部分的每字节只算为0.25字节，也就是说这部分的交易费有75%的折扣，但只限于隔离见证的用户。
David Harding 提供了下表以[估计][estimated savings]在不同费用和交易类型下可以节省的费用。例如如果一个常见的250字节交易收费是0.01美元，用隔离见证花费一个P2PK-in-P2SH输出就可以节省约0.003美元。
| 交易 | 节省字节 | $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 多签 | 83/112 | $0.003 | $0.016 | $0.083 | $0.332 |
| 2-of-2 P2SH 多签 | 163/219 | $0.006 | $0.032 | $0.163 | $0.652 |
| 2-of-3 P2SH 多签 | 189/254 | $0.007 | $0.037 | $0.189 | $0.756 |
(费用金额只作参考，我们并不预期交易费会达到上表显示的最高情况。)
收取固定比例费用 (如免费或1%交易额) 的网页钱包和交易所会最早应用隔离见证，因为即使每个交易节省很少，每天数以千计的交易加起来都会非常可观。
## 听说你们会让零确认不能再用，这是路线图内哪一项技术？ {#rbf}
这并不是路线图的一部分。作为现在 Bitcoin Core 版本的默认设置，在收到一个未确认交易后，就不会再接受其它有相同输入的交易。有些人认为这表示他们首个见到的交易就是安全的，但其实不是；如果真的是这样，我们根本不需要区块链。
在现时的默认设置下，人们并不能更新他们未确认的交易。在最初的 Bitcoin 版本，其实是有方法让使用者表明他希望交易可被更新，但为了防止拒绝服务攻击，中本聪在2010年关闭了这功能。
最近 Bitcoin Core 的开发员发现只要要求更新交易的同时要求使用者要付出更多的交易费，就可以防止上述的拒绝服务攻击，因此他们重开了中本聪那个允许交易被替换的机制。这功能会在预计2016年1至2月在 Bitcoin Core 0.12.0 推出，但和中本聪原本的设计一样，只有希望可以替换交易的使用者才需要选择使用支持该功能的钱包。
现在并没有钱包提供这功能，但将来这类钱包可以把多个未确认交易合并以减少所需要的区块链空间，也可以让用户提高未确认交易的费用，不会因为之前付费不足让交易「阻塞」在钱包内。
## 在路线图上弱区块和IBLT只注明是2016年，你们是否也不知道它们什么时候才可以完成？ {#weak-blocks-iblts}
弱区块和IBLT是两种仍在研究的技术，需要选择适当的参数，但因为参与的开发员有限，我们难以估计在什么时候才能推出。
弱区块和IBLT都只涉及网络改善而不是软分叉或硬分叉，因此只需要较短的测试时间就可以推出让节点升级，我们希望可以在2016年内完成。
在推出弱区块和IBLT后，我们可以利用一个简单而无争议的软分叉来[规范交易次序][canonical transaction ordering]让它们更有效率，这软分叉可以透过BIP9 versionBits 推出。
[canonical transaction ordering]: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions
## 「如果隔离见证不能减少矿工所用的带宽，储存空间，和处理时间，为什么他们要支持？」 {#why-mine-segwit}
其实大部分[以前的软分叉][previous soft forks]都没有为矿工带来这些好处，例如：
| BIP16 (P2SH) | 新交易种类 |
| BIP30 (重覆交易ID) | 要求检查重覆交易ID |
| BIP34 (Coinbase 内记录区块高度) | 让矿工可用的coinbase空间减少 4 字节 |
| BIP65 (OP_CLTV) | 新脚本命令 |
在2015年7月正式执行的 BIP66 (严格 DER 签名) 软分叉让我们可以转用libsecp256k1作交易验证，让验证时间大减，让矿工得益。
而隔离见证可以为其使用者带来以下好处：
这永久地解决第三方延展性，让多阶段智能合约得以实现；减低交易费；让比特币脚本升级更容易，钱包更容易得到新功能。
通过以前的软分叉和沟通，例如在香港比特币扩展性会议内的矿工座谈会，矿工一再表达了即使他们未必有直接得益，他们也希望比特币成为一个最有用的系统。隔离见证和路线图上其它改进可以显着地提升比特币的可用性。
另外，隔离见证允许矿工在区块内加入更多交易，因此也可提升在每个区块内得到的收入。
## 我可以怎样帮忙？
首先阅读在 Bitcoin.org 上的 [Bitcoin Core贡献者][Bitcoin Core contributor]网页。
其中[代码审阅][code review]是实行软分叉极重要的一部分。
如果你想得到更多有关如何贡献的建议，请加入[#bitcoin-dev][] IRC 频道讨论。
[#bitcoin-dev]: https://webchat.freenode.net/?channels=bitcoin-dev&amp;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

30
zh_CN/bitcoin-core/capacity-increases.md
View file

@ -1,30 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: zh_CN
id: bitcoin-core-capacity-increases
columns: 1
title: 比特币系统扩展
breadcrumbs:
- bitcoin
- bcc
- Capacity increases
moved_url: "https://bitcoincore.org/zh_CN/2015/12/21/%E6%AF%94%E7%89%B9%E5%B8%81%E7%B3%BB%E7%BB%9F%E6%89%A9%E5%B1%95/"
---
# 比特币系统扩展
我们连署支持 [比特币系统扩展][1] 路线图。我们已在Bitcoin Core计划内为可扩展性工作多年，认为这是最可以延续我们一直以来努力的方向。
有关更多详情请参阅 [常见问题解答][FAQ]。
{% include bitcoin-core/capability-increases-sigs.md %}
---
如果你想参与连署，请到[#1165](https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165)。
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
[FAQ]: /zh_CN/bitcoin-core/capacity-increases-faq

37
zh_TW/bitcoin-core/2016-01-07-statement.md
View file

@ -1,37 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: zh_TW
id: bitcoin-core-2016-01-07-statement
columns: 1
title: Bitcoin Core 聲明 -- 2016-01-07
breadcrumbs:
- bitcoin
- bcc
- 2016-01-07 Statement
moved_url: "https://bitcoincore.org/zh_TW/2016/01/07/bitcoin-core-%E8%81%B2%E6%98%8E/"
---
# Bitcoin Core 聲明 -- 2016-01-07
比特幣是「點對點電子貨幣，無需經過任何金融機構，就可以在網上由一人直接付款給另一人」。我們的理想，是把比特幣系統的靈活性擴充至可以有效處理極大規模的交易，而同時保障安全以及去中心化的核心性質，因為這是令比特幣獨一無二的要素。
我們相信比特幣要達到這目標，就要在其之上建立多個層次的服務，並與其它系統接合。除此以外，我們的長遠目標還包括保護及增加比特幣用戶的隱私。
「Bitcoin Core」是一個開源軟體計劃，直接承接了原本的比特幣軟件設定。作為計劃的貢獻者，我們為比特幣社群維護並發行軟件，讓用戶考慮使用。我們致力改進比特幣的共識協定，提出的升級方案，都是按我們所認知的比特幣目標所提出，在技術上可行，而且有合理機會被廣泛支持並應用。
比特幣的共識協定可以透過軟分叉或硬分叉改動 (參考附件A)。軟分叉容許具兼容性的改動，新舊軟件可以在網絡上同時存在。通過軟分叉來實現新功能不會造成擾亂，因為只有希望使用新功能的用戶才需要升級，其它用戶可以繼續正常使用原有軟件。
硬分叉則會破壞對所有現有比特幣軟件的兼容性，所有用戶必須在指定期限前升級，否則會有損失金錢的風險。這情況可能逼使不升級的用戶離開網絡，並可能令各種下游軟件及應用不能運作，對比特幣的網絡效應造成損害。
由於以上原因，Bitcoin Core 強烈地傾向保持兼容性，並相信應該由每個用戶決定是否升級他們正在使用的比特幣軟件。事實上利用軟分叉可以加入幾乎任何新功能。在某些情況下，硬分叉可能有些好處，如果能得到幾乎一致的同意，這些好處或可以勝過其缺點。但除了這些罕有情況，軟分叉仍然是首選。我們相信這是最合乎系統內現在和未來用戶的利益。
隨著比特幣的生態系統的成長，我們也預計會有更多其它運行比特幣協定的軟件設定，且無可避免地這些軟件計劃可能會提出徹底不同的方案，讓比特幣的生態系統作考慮。最終而言，Bitcoin Core的開發團隊並不決定比特幣的共識規則；相對地，是由比特幣用戶選擇他們自己運行什麼比特幣軟件。因此 Bitcoin Core 刻意地沒有自動升級功能，這確保每次升級都是用戶自願進行，令用戶可以保持選擇運行什麼軟件的權力。
### 附件 A
硬分叉 是指在更改共識規則後，在舊規則下無效的區塊可能會在新規則下變得有效。
軟分叉 是指在更改共識規則後，在舊規則下有效的區塊可能會在新規則下變得無效，但所有原來是無效的區塊仍然保持為無效。

201
zh_TW/bitcoin-core/capacity-increases-faq.md
View file

@ -1,201 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: zh_TW
id: bitcoin-core-capacity-increases-faq
columns: 1
title: 系統擴展常見問題解答 — Bitcoin Core
breadcrumbs:
- bitcoin
- bcc
- Capacity increases FAQ
moved_url: "https://bitcoincore.org/zh_TW/2015/12/21/%E7%B3%BB%E7%B5%B1%E6%93%B4%E5%B1%95%E5%B8%B8%E8%A6%8B%E5%95%8F%E9%A1%8C%E8%A7%A3%E7%AD%94/"
---
# 系統擴展常見問題解答
1. toc
{:toc}
## 路線圖包括什麼新技術，預期在什麼時候可以使用？ {#roadmap-dates}
在[路線圖][roadmap]提及到以下的技術，在充分的測試後，預計可以在以下時間完成。
| 2015年12月 | | 隔離見證測試網 |
| 2016年2月 | 0.12.0 | [libsecp256k1驗證][libsecp256k1 verification] |
| 2016年2月 | | 隔離見證功能完成並作審核 |
| 2016年3月\* | 0.12.x | 完成OP_CHECKSEQUENCEVERIFY (BIP[68][BIP68] 及 [112][BIP112]) + [BIP113][] 並作為首個以 [BIP9][] versionbits 實施的軟分叉 |
| 2016年4月\* | 0.12.x | 完成隔離見證 |
| 2016年 | | 弱區塊, IBLTs, 或者二者都實現 |
\* 有星號的日期是預計完成代碼的時間。代碼只會在充分審核後才會發表，而軟分叉完成也需要時間。([BIP66][]經歷數月時間在2015年7月生效，[BIP65][]則只用了五周時間在2015年12月生效)
- **隔離見證測試網:** 一個獨立的測試網，並非平常測試網的一部分。讓 Bitcoin Core 開發員及錢包開發員測試隔離見證功能。
- **Libsecp256k1驗證:** 在x86\_64硬件上提升交易驗證速度五至七倍。幫助新節點加入網絡並減輕現有節點的負擔。
- **OP\_CHECKSEQUENCEVERIFY:** 讓雙向[支付通道][payment channel efficiency]可以無限期使用，提升效率達25倍。
- **VersionBits:** 允許1至29個軟分叉同時實施，讓系統升級的過程更快，更去中心化。
- **隔離見證:** 允許交易容量上升到1.75至4倍，解決第三方延展性讓智能合約更安全，雙向支付通道效率提升66%，提供欺詐證明讓輕量節點也可以執行系統規則，更容易對腳本系統升級以允許更強大的合約功能。
- **IBLT及弱區塊:** 只需要把[總帶寬增加少許][increase in total bandwidth]，就可以把區塊傳播所必須的帶寬減低90%以上，讓礦工可以在最短時間內把區塊傳播出去，把[比特幣廣播網絡][Bitcoin Relay Network]的好處帶給所有全節點。IBLT及弱區塊可以把全節點所需的帶寬變得更平均，讓將來可以更安全地增加最大區塊容量。
## 隔離見證軟分叉究竟相當於多少的區塊大小增加？我聽過不同講法，如4MB、2MB、1.75MB。 {#segwit-size}
[現在的方案][current proposal]是以軟分叉來實現隔離見證，並把每字節的見證內容算為0.25字節，因此最大的區塊體積會是稍低於4MB。
然而，區塊並不應該只有見證內容，而計算非見證內容的體積時不會有折扣，因此並不可能有4MB的體積。
根據Anthony Towns的[計算][calculations]，如果區塊裝滿了標準的單簽名P2PKH交易，體積大概為1.6MB；如果是2-of-2多重簽名交易，則大概為2.0MB。
[current proposal]: https://youtu.be/fst1IK_mrng?t=2234
[calculations]: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011869.html
## 隔離見證好像很複雜，比特幣生態各環節準備好沒有？ {#ecosystem-ready}
有些想法是容易解釋但執行很難，有些卻是解釋很難但執行容易，隔離見證似乎是後者。
由於隔離見證可以逐步實行而不會破壞兼容性，因此生態內各環節無需特別準備。開發員可以在2015年12月推出的測試網得到實際的使用經驗並同時測試他們的軟件。
最初，只有希望支持隔離見證的礦工需要升級，讓新規則可以在主網實行。現有的應用程序只有需要使用新功能才需要改變。
隔離見證交易收取較低交易費，有更佳的性能，而且支持多重簽名智能合約，如雙向支付通道，可以作大量交易卻無需在區塊鏈作額外紀錄。我們強烈建議錢包升級，但即使不升級，現有錢包仍然可以繼續正常使用。
## 我還是覺得隔離見證很複雜，為什麼不簡單地提高區塊體積？ {#size-bump}
在Bitcoin Core有[一句代碼][max_block_size]指定區塊最大是 1,000,000 字節 (1MB)。最簡單的方法是用硬分叉改變這句代碼，例如變為 2,000,000 字節 (2MB)。
但硬分叉本身絕不簡單:
- **我們並沒有經驗:** 礦工，商戶，開發員，用戶都沒有硬分叉的經驗，因此讓硬分叉可以安全實行的技術也未經測試。
軟分叉則不同。軟分叉最初由中本聰管理，然後我們又從實行[BIP16][]所遇到的問題中得到經驗，讓我們以改良了的方法實行[BIP34][]，以及後來的BIP[66][BIP66] 和 [65][BIP65]。在將來的軟分叉，我們正準備使用[BIP9][] version bits，讓多個軟分叉方案可以同時進行。
- **強制升級:** 硬分叉要求所有全節點升級，而任何使用舊版本節點的人都可能會損失金錢，這不但包括全節點錢包的運行者本身，還包括依靠該全節點提供數據的輕量錢包。
- **需要其它的改動:** 即使只是改一行代碼來增加最大區塊容量，也會影響到系統內其它代碼，有些更是不良的影響。例如現在可以制造一個接近1MB的交易，而現代的電腦驗證該交易需時超過30秒 (這樣的交易已存在於區塊鏈上)。在2MB的區塊下，驗證一個2MB的交易需時10分鐘，將成為一個很危險的攻擊方法。為了避免這種攻擊，就有必要改動其它代碼。
雖然有以上的問題，但只要有充足的準備，硬分叉並不會出現致命問題，而我們也預計將來會有硬分叉。但隔離見證可以用我們更熟悉的軟分叉完成，而且帶來增加交易量以外更多的好處。
和簡單提升區塊體積相比，隔離見證需要在不同的軟件層面作更多改動。但如果我們真的希望比特幣可以擴展，我們無論如何也需要根本性的改動，而隔離見證可以逐漸地鼓勵人們升級至更具擴展性的方案，卻無需強逼他們這樣做。
開發員，礦工，以及社群已對軟分叉有充分經驗，我們相信實行隔離見證所需時間並不比提升容量的硬分叉為多，而且會更安全。
## 在實行隔離見證前會有硬分叉嗎？隔離見證方案會本身又會否包括硬分叉？ {#pre-segwit-fork}
不會，這並非[路線圖][roadmap]的一部分。
[roadmap]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
## 如果最終還是要硬分叉，為何現在不做？ {#why-not-now}
利用有廣泛共識的軟分叉，我們能夠把系統擴展而沒有硬分叉的[副作用][q simple raise]，因此即使預期會有硬分叉，這並不是現在就要做的充分理由。
在路線圖提到的改進，除提供額外的交易容量以外，配合其它技術如雙向支付通道，可以讓用戶減少使用區塊鏈，變相提高了比特幣系統的容量，卻不用增加全節點使用的帶寬。例如：
- [BIP68][] 及 [BIP112][] 允許無限期的雙向支付通道，可以大為減少紀錄在區塊鏈的交易。
- 隔離見證允許在關閉支付通道的同時開設新的支付通道，減少因為更換通道所需的區塊鏈空間約66%。
- 隔離見證允許將來更容易以軟分叉改變比特幣的腳本語言，例如從簽名提取公鑰，或使用Schnorr聯合簽名算法，從而減少交易的平均大小。
- 實行隔離見證後，當無效區塊出現時就可以產生很簡潔的欺詐證明，這會讓進行簡單交易驗證 (SPV) 的輕量節點的安全性更接近全節點，可以讓整個網絡在較少的全節點下仍能運作。
這些技術的實際效果仍然未知，但實行一個具廣泛共識的軟分叉可讓我們立即得益並且測試和評估中期的可能性，以及用這些數據作長期的規劃。
## 錢包會如何使用隔離見證？ {#segwit-in-wallets}
現在支持 P2SH 的錢包可以分兩階段轉移至完整的隔離見證：
- 第一階段：腳本需要經過兩次雜湊運算，首先是變成256字節，然後再變成160字節。這個160字節的雜湊和現有的P2SH地址兼容，因此已升級的錢包和現有的錢包之間可以互相收付款項。
- 第二階段：腳本只需一次雜湊運算變為256字節。這格式和現有錢包不相容，但允許更有效率地使用區塊空間，及提供更強的防碰撞攻擊性能。
## 如果沒有人被逼升級，為何會有人升級？聽說P2SH用了差不多兩年時間才得到廣泛應用。 {#why-upgrade}
在隔離見證交易中，見證部分的每字節只算為0.25字節，也就是說這部分的交易費有75%的折扣，但只限於隔離見證的用戶。
David Harding 提供了下表以[估計][estimated savings]在不同費用和交易類型下可以節省的費用。例如如果一個常見的250字節交易收費是0.01美元，用隔離見證花費一個P2PK-in-P2SH輸出就可以節省約0.003美元。
| 交易 | 節省字節 | $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 多簽 | 83/112 | $0.003 | $0.016 | $0.083 | $0.332 |
| 2-of-2 P2SH 多簽 | 163/219 | $0.006 | $0.032 | $0.163 | $0.652 |
| 2-of-3 P2SH 多簽 | 189/254 | $0.007 | $0.037 | $0.189 | $0.756 |
(費用金額只作參考，我們並不預期交易費會達到上表顯示的最高情況。)
收取固定比例費用 (如免費或1%交易額) 的網頁錢包和交易所會最早應用隔離見證，因為即使每個交易節省很少，每天數以千計的交易加起來都會非常可觀。
## 聽說你們會讓零確認不能再用，這是路線圖內哪一項技術？ {#rbf}
這並不是路線圖的一部分。作為現在 Bitcoin Core 版本的默認設置，在收到一個未確認交易後，就不會再接受其它有相同輸入的交易。有些人認為這表示他們首個見到的交易就是安全的，但其實不是；如果真的是這樣，我們根本不需要區塊鏈。
在現時的默認設置下，人們並不能更新他們未確認的交易。在最初的 Bitcoin 版本，其實是有方法讓使用者表明他希望交易可被更新，但為了防止拒絕服務攻擊，中本聰在2010年關閉了這功能。
最近 Bitcoin Core 的開發員發現只要要求更新交易的同時要求使用者要付出更多的交易費，就可以防止上述的拒絕服務攻擊，因此他們重開了中本聰那個允許交易被替換的機制。這功能會在預計2016年1至2月在 Bitcoin Core 0.12.0 推出，但和中本聰原本的設計一樣，只有希望可以替換交易的使用者才需要選擇使用支持該功能的錢包。
現在並沒有錢包提供這功能，但將來這類錢包可以把多個未確認交易合並以減少所需要的區塊鏈空間，也可以讓用戶提高未確認交易的費用，不會因為之前付費不足讓交易「阻塞」在錢包內。
## 在路線圖上弱區塊和IBLT只注明是2016年，你們是否也不知道它們什麼時候才可以完成？ {#weak-blocks-iblts}
弱區塊和IBLT是兩種仍在研究的技術，需要選擇適當的參數，但因為參與的開發員有限，我們難以估計在什麼時候才能推出。
弱區塊和IBLT都只涉及網絡改善而不是軟分叉或硬分叉，因此只需要較短的測試時間就可以推出讓節點升級，我們希望可以在2016年內完成。
在推出弱區塊和IBLT後，我們可以利用一個簡單而無爭議的軟分叉來[規範交易次序][canonical transaction ordering]讓它們更有效率，這軟分叉可以透過BIP9 versionBits 推出。
[canonical transaction ordering]: https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2#canonical-ordering-of-transactions
## 「如果隔離見證不能減少礦工所用的帶寬，儲存空間，和處理時間，為什麼他們要支持？」 {#why-mine-segwit}
其實大部分[以前的軟分叉][previous soft forks]都沒有為礦工帶來這些好處，例如：
| BIP16 (P2SH) | 新交易種類 |
| BIP30 (重覆交易ID) | 要求檢查重覆交易ID |
| BIP34 (Coinbase 內記錄區塊高度) | 讓礦工可用的coinbase空間減少 4 字節 |
| BIP65 (OP_CLTV) | 新腳本命令 |
在2015年7月正式執行的 BIP66 (嚴格 DER 簽名) 軟分叉讓我們可以轉用libsecp256k1作交易驗證，讓驗證時間大減，讓礦工得益。
而隔離見證可以為其使用者帶來以下好處：
這永久地解決第三方延展性，讓多階段智能合約得以實現；減低交易費；讓比特幣腳本升級更容易，錢包更容易得到新功能。
通過以前的軟分叉和溝通，例如在香港比特幣擴展性會議內的礦工座談會，礦工一再表達了即使他們未必有直接得益，他們也希望比特幣成為一個最有用的系統。隔離見證和路線圖上其它改進可以顯著地提升比特幣的可用性。
另外，隔離見證允許礦工在區塊內加入更多交易，因此也可提升在每個區塊內得到的收入。
## 我可以怎樣幫忙？
首先閱讀在 Bitcoin.org 上的 [Bitcoin Core貢獻者][Bitcoin Core contributor]網頁。
其中[代碼審閱][code review]是實行軟分叉極重要的一部分。
如果你想得到更多有關如何貢獻的建議，請加入[#bitcoin-dev][] IRC 頻道討論。
[#bitcoin-dev]: https://webchat.freenode.net/?channels=bitcoin-dev&amp;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

31
zh_TW/bitcoin-core/capacity-increases.md
View file

@ -1,31 +0,0 @@
---
# This file is licensed under the MIT License (MIT) available on
# http://opensource.org/licenses/MIT.
layout: base-core
lang: zh_TW
id: bitcoin-core-capacity-increases
columns: 1
title: 比特幣系統擴展
breadcrumbs:
- bitcoin
- bcc
- Capacity increases
moved_url: "https://bitcoincore.org/zh_TW/2015/12/21/%E6%AF%94%E7%89%B9%E5%B9%A3%E7%B3%BB%E7%B5%B1%E6%93%B4%E5%B1%95/"
---
# 比特幣系統擴展
我們連署支持[比特幣系統擴展][1]路線圖。我們已在Bitcoin
Core計劃內為可擴展性工作多年，認為這是最可以延續我們一直以來努力的方向。
有關更多詳情請參閱 [常見問題解答][FAQ]。
{% include bitcoin-core/capability-increases-sigs.md %}
---
如果你想參與連署，請到[#1165](https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165)。
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
[FAQ]: /zh_TW/bitcoin-core/capacity-increases-faq