mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 01:36:13 +00:00
Remove Bitcoin Core stuff
This commit is contained in:
thephez
parent
a865e21b2b
commit
c45c79ec53
44 changed files with 2 additions and 5675 deletions
|
|
@ -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)
|
||||
|
||||
|
|
@ -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 %}
|
||||
|
|
@ -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&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
|
||||
|
|
@ -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
|
||||
|
|
@ -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 %}
|
||||
|
|
@ -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 %}
|
||||
|
|
@ -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 %}
|
||||
|
|
@ -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 %}
|
||||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
From the page listing a specific release, you can click the Translate
|
||||
button.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
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 %}
|
||||
|
|
@ -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 %}
|
||||
|
|
@ -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}
|
||||
|
||||
|
||||
|
||||
{% 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 %}
|
||||
|
|
@ -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}
|
||||
|
||||
|
||||
|
||||
{% 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:
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
**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">
|
||||
|
||||
|
||||
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">
|
||||
|
||||
|
||||
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">
|
||||
|
||||
|
||||
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 %}
|
||||
|
|
@ -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}
|
||||
|
||||
|
||||
|
||||
{% 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).
|
||||
|
||||
|
||||
**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 %}
|
||||
|
|
@ -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}
|
||||
|
||||
|
||||
|
||||
{% 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.
|
||||
|
||||
|
||||
|
||||
**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].
|
||||
|
||||
|
||||
|
||||
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].
|
||||
|
||||
|
||||
|
||||
<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 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">
|
||||
|
||||
|
||||
{% 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">
|
||||
|
||||
</div>
|
||||
|
||||
<div id="gui_fee_slider" title="Fee Slider" markdown="block">
|
||||
|
||||
</div>
|
||||
|
||||
<div id="gui_coin_control" title="Coin Control" markdown="block">
|
||||
|
||||
</div>
|
||||
|
||||
<div id="gui_qr_codes" title="QR Codes" markdown="block">
|
||||
|
||||
</div>
|
||||
|
||||
<div id="gui_unique_invoices" title="Unique Invoices" markdown="block">
|
||||
|
||||
</div>
|
||||
|
||||
<div id="gui_proxy_configuration" title="Proxy Configuration" markdown="block">
|
||||
|
||||
</div>
|
||||
|
||||
<div id="gui_network_monitoring" title="Network monitoring" markdown="block">
|
||||
|
||||
</div>
|
||||
|
||||
<div id="gui_watch_only" title="Watching-only Wallets" markdown="block">
|
||||
|
||||
</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 %}
|
||||
|
|
@ -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}
|
||||
|
||||
|
||||
|
||||
{% 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.
|
||||
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
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 %}
|
||||
|
|
@ -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 %}
|
||||
|
|
@ -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}
|
||||
|
||||
|
||||
|
||||
<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 {{ 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
1555
en/full-node.md
File diff suppressed because it is too large
Load diff
Loading…
Add table
Add a link
Reference in a new issue