sikkienl/dash
1
0
Fork 0
mirror of https://github.com/dashpay/dash.git synced 2024-12-26 04:22:55 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity
07825088f9
dash/doc
History
Wladimir J. van der Laan 4366f61cc9
Merge #11862: Network specific conf sections 
c25321f Add config changes to release notes (Anthony Towns)
5e3cbe0 [tests] Unit tests for -testnet/-regtest in [test]/[regtest] sections (Anthony Towns)
005ad26 ArgsManager: special handling for -regtest and -testnet (Anthony Towns)
608415d [tests] Unit tests for network-specific config entries (Anthony Towns)
68797e2 ArgsManager: Warn when ignoring network-specific config setting (Anthony Towns)
d1fc4d9 ArgsManager: limit some options to only apply on mainnet when in default section (Anthony Towns)
8a9817d [tests] Use regtest section in functional tests configs (Anthony Towns)
30f9407 [tests] Unit tests for config file sections (Anthony Towns)
95eb66d ArgsManager: support config file sections (Anthony Towns)
4d34fcc ArgsManager: drop m_negated_args (Anthony Towns)
3673ca3 ArgsManager: keep command line and config file arguments separate (Anthony Towns)

Pull request description:

  The weekly meeting on [2017-12-07](http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-07-19.00.log.html) discussed allowing options to bitcoin to have some sensitivity to what network is in use. @theuni suggested having sections in the config file:

      <cfields> an alternative to that would be sections in a config file. and on the
                cmdline they'd look like namespaces. so, [testnet] port=5. or -testnet::port=5.

  This approach is (more or less) supported by `boost::program_options::detail::config_file_iterator` -- when it sees a `[testnet]` section with `port=5`, it will treat that the same as "testnet.port=5". So `[testnet] port=5` (or `testnet.port=5` without the section header) in bitcoin.conf and `-testnet.port=5` on the command line.

  The other aspect to this question is possibly limiting some options so that there is no possibility of accidental cross-contamination across networks. For example, if you're using a particular wallet.dat on mainnet, you may not want to accidentally use the same wallet on testnet and risk reusing keys.

  I've set this up so that the `-addnode` and `-wallet` options are `NETWORK_ONLY`, so that if you have a bitcoin.conf:

      wallet=/secret/wallet.dat
      upnp=1

  and you run `bitcoind -testnet` or `bitcoind -regtest`, then the `wallet=` setting will be ignored, and should behave as if your bitcoin.conf had specified:

      upnp=1

      [main]
      wallet=/secret/wallet.dat

  For any `NETWORK_ONLY` options, if you're using `-testnet` or `-regtest`, you'll have to add the prefix to any command line options. This was necessary for `multiwallet.py` for instance.

  I've left the "default" options as taking precedence over network specific ones, which might be backwards. So if you have:

      maxmempool=200
      [regtest]
      maxmempool=100

  your maxmempool will still be 200 on regtest. The advantage of doing it this way is that if you have `[regtest] maxmempool=100` in bitcoin.conf, and then say `bitcoind -regtest -maxmempool=200`, the same result is probably in line with what you expect...

  The other thing to note is that I'm using the chain names from `chainparamsbase.cpp` / `ChainNameFromCommandLine`, so the sections are `[main]`, `[test]` and `[regtest]`; not `[mainnet]` or `[testnet]` as might be expected.

  Thoughts? Ping @MeshCollider @laanwj @jonasschnelli @morcos

Tree-SHA512: f00b5eb75f006189987e5c15e154a42b66ee251777768c1e185d764279070fcb7c41947d8794092b912a03d985843c82e5189871416995436a6260520fb7a4db
2018-04-16 20:52:38 +02:00
..
man doc: Update manpages to 0.16.99 2018-01-30 14:24:59 +01:00
release-notes doc: Add historical release notes for 0.16.0 2018-02-26 12:25:01 +01:00
.gitignore Ignore Doxyfile generated from Doxyfile.in template. 2017-04-07 16:28:12 +02:00
assets-attribution.md
benchmarking.md Updating benchmarkmarking.md with an updated sample output and help options 2018-01-19 11:41:56 -06:00
bips.md [Doc] Fix link for bip 159 pull request 2018-01-11 11:39:10 +09:00
bitcoin_logo_doxygen.png
build-netbsd.md [doc] Create build-netbsd.md 2018-01-30 07:47:27 +08:00
build-openbsd.md doc: Update OpenBSD build instructions for 6.2 2017-12-22 10:08:53 +01:00
build-osx.md doc: add qrencode to brew install instructions 2018-04-07 16:59:49 +02:00
build-unix.md doc: Mention configure without wallet in FreeBSD instructions 2018-03-06 22:07:20 +01:00
build-windows.md Ubuntu xenial first dependencies 2018-03-11 15:11:07 +01:00
dependencies.md Merge #12607: depends: Remove ccache 2018-03-07 21:12:47 -05:00
developer-notes.md Refine travis check for duplicate includes 2018-04-10 15:12:42 -04:00
dnsseed-policy.md
Doxyfile.in doc: Make build system insert version in Doxyfile 2017-04-05 09:40:56 +02:00
files.md Update files.md for new wallets/ subdirectory 2017-12-13 23:36:43 +13:00
fuzzing.md [test] Speed up fuzzing by ~200x when using afl-fuzz 2017-05-19 07:28:46 +02:00
gitian-building.md doc: move gitian building to external repo 2017-09-25 15:45:38 +02:00
init.md docs: clarified systemd installation instructions in init.md for Ubuntu users. 2018-02-17 17:23:06 -07:00
README_osx.md Fix typos and cleanup 2018-03-02 23:00:25 +02:00
README_windows.txt doc: Remove version numbers from READMEs 2017-04-05 09:40:48 +02:00
README.md Add NetBSD build instruction links 2018-01-30 21:03:58 +00:00
reduce-traffic.md
release-notes-pr12823.md Add config changes to release notes 2018-04-11 23:15:28 +10:00
release-notes-pr12892.md [docs] Add release notes for wallet 'label' API. 2018-04-10 19:27:28 -04:00
release-notes.md [docs] Add release notes for wallet 'label' API. 2018-04-10 19:27:28 -04:00
release-process.md Give hint about gitian not able to download 2018-03-06 17:14:29 -05:00
REST-interface.md Fix typos and cleanup 2018-03-02 23:00:25 +02:00
shared-libraries.md
tor.md doc: Use bitcoind in Tor documentation 2018-04-05 09:40:20 +02:00
translation_process.md Fix typos and cleanup 2018-03-02 23:00:25 +02:00
translation_strings_policy.md
travis-ci.md [doc] Rework docs 2016-10-04 13:27:38 +02:00
zmq.md Fix typos and cleanup 2018-03-02 23:00:25 +02:00

README.md

Bitcoin Core

Setup

Bitcoin Core is the original Bitcoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Bitcoin transactions (which is currently more than 100 GBs); depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to a day or more.

To download Bitcoin Core, visit bitcoincore.org.

Running

The following are some helpful notes on how to run Bitcoin on your native platform.

Unix

Unpack the files into a directory and run:

  • bin/bitcoin-qt (GUI) or
  • bin/bitcoind (headless)

Windows

Unpack the files into a directory, and then run bitcoin-qt.exe.

OS X

Drag Bitcoin-Core to your applications folder, and then run Bitcoin-Core.

Need Help?

Building

The following are developer notes on how to build Bitcoin on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.

Development

The Bitcoin repo's root README contains relevant information on the development process and automated testing.

Resources

Miscellaneous

License

Distributed under the MIT software license. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. This product includes cryptographic software written by Eric Young (eay@cryptsoft.com), and UPnP software written by Thomas Bernard.