LBRYCommunity/lbcd
1
0
Fork 0
Code Issues 17 Pull requests 4 Packages Projects Releases 28 Wiki Activity
lbcd/sample-btcd.conf

346 lines
13 KiB
Plaintext
Raw Normal View History

Initial import.
2013-08-06 23:55:22 +02:00
[Application Options]
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
Expand environment variables in datadir. This commit adds environment variable expansion and path cleaning to the data directory. This allows the user to specify data paths in the config file such as datadir=~/.btcd/data and datadir=$SOMEVAR/btcd. It also adds usage instructions and an example to the sample btcd.conf file.
2013-09-18 07:13:36 +02:00
; ------------------------------------------------------------------------------
; Data settings
; ------------------------------------------------------------------------------
; The directory to store data such as the block chain and peer addresses. The
; block chain takes several GB, so this location must have a lot of free space.
Migrate to new app data directories. This commit makes use of the new btcutil.AppDataDir function which chooses appropriate data directories for each supported operating system. It also adds code to the upgrade path to properly migrate existing data from the old to new locations. This is part of work toward issue #30.
2013-11-11 00:12:45 +01:00
; The default is ~/.btcd/data on POSIX OSes, $LOCALAPPDATA/Btcd/data on Windows,
; ~/Library/Application Support/Btcd/data on Mac OS, and $home/btcd/data on
; Plan9. Environment variables are expanded so they may be used. NOTE: Windows
Expand environment variables in datadir. This commit adds environment variable expansion and path cleaning to the data directory. This allows the user to specify data paths in the config file such as datadir=~/.btcd/data and datadir=$SOMEVAR/btcd. It also adds usage instructions and an example to the sample btcd.conf file.
2013-09-18 07:13:36 +02:00
; environment variables are typically %VARIABLE%, but they must be accessed with
Migrate to new app data directories. This commit makes use of the new btcutil.AppDataDir function which chooses appropriate data directories for each supported operating system. It also adds code to the upgrade path to properly migrate existing data from the old to new locations. This is part of work toward issue #30.
2013-11-11 00:12:45 +01:00
; $VARIABLE here. Also, ~ is expanded to $LOCALAPPDATA on Windows.
Expand environment variables in datadir. This commit adds environment variable expansion and path cleaning to the data directory. This allows the user to specify data paths in the config file such as datadir=~/.btcd/data and datadir=$SOMEVAR/btcd. It also adds usage instructions and an example to the sample btcd.conf file.
2013-09-18 07:13:36 +02:00
; datadir=~/.btcd/data
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
; ------------------------------------------------------------------------------
; Network settings
; ------------------------------------------------------------------------------
Initial import.
2013-08-06 23:55:22 +02:00
; Use testnet.
; testnet=1
Update sample config file with recent changes. This commit updates the sample config file to add the new listen option and update the semantics regarding the combination of --proxy and --tor flags.
2013-11-14 03:20:32 +01:00
; Connect via a SOCKS5 proxy. NOTE: Specifying a proxy will disable listening
; for incoming connections unless listen addresses are provided via the 'listen'
; option.
Move sample proxy config near top of net settings.
2013-08-08 04:49:10 +02:00
; proxy=127.0.0.1:9050
; proxyuser=
; proxypass=
Enable use of a different proxy for .onion addresses. This implements --onion (and --onionuser/--onionpass) that enable a different proxy to be used to connect to .onion addresses. If no main proxy is supplied then no proxy will be used for non-onion addresses. Additionally we add --noonion that blocks connection attempts to .onion addresses entirely (and avoids using tor for proxy dns lookups). the --tor option has been supersceded and thus removed. Closes #47
2013-12-17 16:10:59 +01:00
; The SOCKS5 proxy above is assumed to be Tor (https://www.torproject.org).
Update sample config file. This commit adds a couple of options which were not details in the sample config file. It also fixes a couple of typos and makes the example default maxpeers setting in the config file match the actual default used in btcd.
2014-09-18 22:11:17 +02:00
; If the proxy is not tor the following may be used to prevent using tor
; specific SOCKS queries to lookup addresses (this increases anonymity when tor
; is used by preventing your IP being leaked via DNS).
Unexport and comment btcDial and btcLookup func. These functions are at the package level and only apply within btcd, so unexport them to be consistent.
2014-01-10 08:31:20 +01:00
; noonion=1
Enable use of a different proxy for .onion addresses. This implements --onion (and --onionuser/--onionpass) that enable a different proxy to be used to connect to .onion addresses. If no main proxy is supplied then no proxy will be used for non-onion addresses. Additionally we add --noonion that blocks connection attempts to .onion addresses entirely (and avoids using tor for proxy dns lookups). the --tor option has been supersceded and thus removed. Closes #47
2013-12-17 16:10:59 +01:00
; Use an alternative proxy to connect to .onion addresses. The proxy is assumed
; to be a Tor node. Non .onion addresses will be contacted with the main proxy
; or without a proxy if none is set.
; onion=127.0.0.1:9051
Update sample config file. This commit adds a couple of options which were not details in the sample config file. It also fixes a couple of typos and makes the example default maxpeers setting in the config file match the actual default used in btcd.
2014-09-18 22:11:17 +02:00
; onionuser=
; onionpass=
Add new option --torisolation Tor stream isolation randomizes proxy user credentials resulting in Tor creating a new circuit for each connection. This makes it more difficult to correlate connections. Idea from Wladimir J. van der Laan via Bitcoin Core.
2015-05-13 22:34:33 +02:00
; Enable Tor stream isolation by randomizing proxy user credentials resulting in
; Tor creating a new circuit for each connection. This makes it more difficult
; to correlate connections.
; torisolation=1
Update sample config file. This commit adds a couple of options which were not details in the sample config file. It also fixes a couple of typos and makes the example default maxpeers setting in the config file match the actual default used in btcd.
2014-09-18 22:11:17 +02:00
; Use Universal Plug and Play (UPnP) to automatically open the listen port
; and obtain the external IP address from supported devices. NOTE: This option
; will have no effect if exernal IP addresses are specified.
; upnp=1
; Specify the external IP addresses your node is listening on. One address per
; line. btcd will not contact 3rd-party sites to obtain external ip addresses.
; This means if you are behind NAT, your node will not be able to advertise a
; reachable address unless you specify it here or enable the 'upnp' option (and
; have a supported device).
; externalip=1.2.3.4
; externalip=2002::1234
Move sample proxy config near top of net settings.
2013-08-08 04:49:10 +02:00
Update the sample config file. This commit adds a few more available options to the sample config file and clarifies a few things.
2013-10-04 08:38:41 +02:00
; ******************************************************************************
Update sample config file with recent changes. This commit updates the sample config file to add the new listen option and update the semantics regarding the combination of --proxy and --tor flags.
2013-11-14 03:20:32 +01:00
; Summary of 'addpeer' versus 'connect'.
;
Update the sample config file. This commit adds a few more available options to the sample config file and clarifies a few things.
2013-10-04 08:38:41 +02:00
; Only one of the following two options, 'addpeer' and 'connect', may be
; specified. Both allow you to specify peers that you want to stay connected
; with, but the behavior is slightly different. By default, btcd will query DNS
; to find peers to connect to, so unless you have a specific reason such as
; those described below, you probably won't need to modify anything here.
;
; 'addpeer' does not prevent connections to other peers discovered from
; the peers you are connected to and also lets the remote peers know you are
; available so they can notify other peers they can to connect to you. This
; option might be useful if you are having problems finding a node for some
; reason (perhaps due to a firewall).
;
; 'connect', on the other hand, will ONLY connect to the specified peers and
Update sample config file with recent changes. This commit updates the sample config file to add the new listen option and update the semantics regarding the combination of --proxy and --tor flags.
2013-11-14 03:20:32 +01:00
; no others. It also disables listening (unless you explicitly set listen
; addresses via the 'listen' option) and DNS seeding, so you will not be
Update the sample config file. This commit adds a few more available options to the sample config file and clarifies a few things.
2013-10-04 08:38:41 +02:00
; advertised as an available peer to the peers you connect to and won't accept
; connections from any other peers. So, the 'connect' option effectively allows
Minor cleanup of some documentation and comments.
2013-11-18 17:38:24 +01:00
; you to only connect to "trusted" peers.
Update the sample config file. This commit adds a few more available options to the sample config file and clarifies a few things.
2013-10-04 08:38:41 +02:00
; ******************************************************************************
Move sample proxy config near top of net settings.
2013-08-08 04:49:10 +02:00
Update sample config for recent go-flags fix. The configuration file can now contain multiple entries for the configuration options which allow more than one to be specified (addpeer, connect).
2013-09-19 16:17:15 +02:00
; Add persistent peers to connect to as desired. One peer per line.
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
; You may specify each IP address with or without a port. The default port will
; be added automatically if one is not specified here.
Update sample config for recent go-flags fix. The configuration file can now contain multiple entries for the configuration options which allow more than one to be specified (addpeer, connect).
2013-09-19 16:17:15 +02:00
; addpeer=192.168.1.1
; addpeer=10.0.0.2:8333
; addpeer=fe80::1
; addpeer=[fe80::2]:8333
Initial import.
2013-08-06 23:55:22 +02:00
Update the sample config file. This commit adds a few more available options to the sample config file and clarifies a few things.
2013-10-04 08:38:41 +02:00
; Add persistent peers that you ONLY want to connect to as desired. One peer
; per line. You may specify each IP address with or without a port. The
; default port will be added automatically if one is not specified here.
Update sample config file with recent changes. This commit updates the sample config file to add the new listen option and update the semantics regarding the combination of --proxy and --tor flags.
2013-11-14 03:20:32 +01:00
; NOTE: Specifying this option has other side effects as described above in
; the 'addpeer' versus 'connect' summary section.
Update the sample config file. This commit adds a few more available options to the sample config file and clarifies a few things.
2013-10-04 08:38:41 +02:00
; connect=192.168.1.1
; connect=10.0.0.2:8333
; connect=fe80::1
; connect=[fe80::2]:8333
Initial import.
2013-08-06 23:55:22 +02:00
; Maximum number of inbound and outbound peers.
Update sample config file. This commit adds a couple of options which were not details in the sample config file. It also fixes a couple of typos and makes the example default maxpeers setting in the config file match the actual default used in btcd.
2014-09-18 22:11:17 +02:00
; maxpeers=125
Initial import.
2013-08-06 23:55:22 +02:00
Implement banning based on dynamic ban scores Dynamic ban scores consist of a persistent and a decaying component. The persistent score can be used to create simple additive banning policies simlar to those found in other bitcoin node implementations. The decaying score enables the creation of evasive logic which handles misbehaving peers (especially application layer DoS attacks) gracefully by disconnecting and banning peers attempting various kinds of flooding. Dynamic ban scores allow these two approaches to be used in tandem. This pull request includes the following: - Dynamic ban score type & functions, with tests for core functionality - Ban score of connected peers can be queried via rpc (getpeerinfo) - Example policy with decaying score increments on mempool and getdata - Logging of misbehavior once half of the ban threshold is reached - Banning logic can be disabled via configuration (enabled by default) - User defined ban threshold can be set via configuration
2016-01-23 04:11:22 +01:00
; Disable banning of misbehaving peers.
; nobanning=1
sampleconfig: Remove floating grave accent
2018-09-27 18:41:34 +02:00
; Maximum allowed ban score before disconnecting and banning misbehaving peers.
Implement banning based on dynamic ban scores Dynamic ban scores consist of a persistent and a decaying component. The persistent score can be used to create simple additive banning policies simlar to those found in other bitcoin node implementations. The decaying score enables the creation of evasive logic which handles misbehaving peers (especially application layer DoS attacks) gracefully by disconnecting and banning peers attempting various kinds of flooding. Dynamic ban scores allow these two approaches to be used in tandem. This pull request includes the following: - Dynamic ban score type & functions, with tests for core functionality - Ban score of connected peers can be queried via rpc (getpeerinfo) - Example policy with decaying score increments on mempool and getdata - Logging of misbehavior once half of the ban threshold is reached - Banning logic can be disabled via configuration (enabled by default) - User defined ban threshold can be set via configuration
2016-01-23 04:11:22 +01:00
; banthreshold=100
Initial import.
2013-08-06 23:55:22 +02:00
; How long to ban misbehaving peers. Valid time units are {s, m, h}.
; Minimum 1s.
; banduration=24h
; banduration=11h30m15s
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
config: Add --whitelist support.
2017-08-31 15:59:43 +02:00
; Add whitelisted IP networks and IPs. Connected peers whose IP matches a
; whitelist will not have their ban score increased.
; whitelist=127.0.0.1
; whitelist=::1
; whitelist=192.168.0.0/24
; whitelist=fd00::/16
Update the sample config file. This commit adds a few more available options to the sample config file and clarifies a few things.
2013-10-04 08:38:41 +02:00
; Disable DNS seeding for peers. By default, when btcd starts, it will use
; DNS to query for available peers to connect with.
; nodnsseed=1
Update sample config file with recent changes. This commit updates the sample config file to add the new listen option and update the semantics regarding the combination of --proxy and --tor flags.
2013-11-14 03:20:32 +01:00
; Specify the interfaces to listen on. One listen address per line.
Make RPC section of sample-btcd.conf consistent.
2013-11-19 18:00:55 +01:00
; NOTE: The default port is modified by some options such as 'testnet', so it is
; recommended to not specify a port and allow a proper default to be chosen
; unless you have a specific reason to do otherwise.
Remove comments interpreted as settings in go-flags/ini_private.go in function readIni there is no mechanism for adding inline comments. Only comments that have a semicolon as the first non-whitespace character are ignored. According to Wikipedia http://en.wikipedia.org/wiki/INI_file#Comments inline comments are not universally supported. This change adds some white space for readability, but name := strings.TrimSpace(line[1 : len(line)-1]) removes accidental whitespace left in later. Closes #135.
2014-06-09 06:48:56 +02:00
; All interfaces on default port (this is the default):
; listen=
; All ipv4 interfaces on default port:
; listen=0.0.0.0
; All ipv6 interfaces on default port:
; listen=::
; All interfaces on port 8333:
; listen=:8333
; All ipv4 interfaces on port 8333:
; listen=0.0.0.0:8333
; All ipv6 interfaces on port 8333:
; listen=[::]:8333
; Only ipv4 localhost on port 8333:
; listen=127.0.0.1:8333
; Only ipv6 localhost on port 8333:
; listen=[::1]:8333
; Only ipv4 localhost on non-standard port 8336:
; listen=127.0.0.1:8336
; All interfaces on non-standard port 8336:
; listen=:8336
; All ipv4 interfaces on non-standard port 8336:
; listen=0.0.0.0:8336
; All ipv6 interfaces on non-standard port 8336:
; listen=[::]:8336
Update sample config file with recent changes. This commit updates the sample config file to add the new listen option and update the semantics regarding the combination of --proxy and --tor flags.
2013-11-14 03:20:32 +01:00
; Disable listening for incoming connections. This will override all listeners.
Update the sample config file. This commit adds a few more available options to the sample config file and clarifies a few things.
2013-10-04 08:38:41 +02:00
; nolisten=1
wire: Implement SFNodeBloom (BIP0111). SFNodeBloom is a new service flag that a node is required to use to indicate that it supports bloom filtering. This includes a protocol version bump to 70011 and a wire version bump to 0.3.0. btcd: The SFNodeBloom flag is set by default. A new configuration option --nopeerbloomfilters has been added to to disable bloom filtering. Any node advertising a version greater than or equal to 70011 that attempts to use bloom filtering will be disconnected if bloom filtering is disabled. This mimics Bitcoin Core commit afb0ccaf9c9e4e8fac7db3564c4e19c9218c6b03
2015-08-24 17:48:59 +02:00
; Disable peer bloom filtering. See BIP0111.
; nopeerbloomfilters=1
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
blockchain: Allow adding additional checkpoints Introduces a `--checkpoint` flag that allows the user to specify additional checkpoints or override the default ones provided in the chain params.
2016-12-02 00:54:41 +01:00
; Add additional checkpoints. Format: '<height>:<hash>'
; addcheckpoint=<height>:<hash>
config: Add user agent comments flag --uacomment Just like Core's -uacomment, this flag allows to specify user agent comments like defined in BIP 14.
2017-04-14 03:08:05 +02:00
; Add comments to the user agent that is advertised to peers.
; Must not include characters '/', ':', '(' and ')'.
; uacomment=
blockchain: Rework to use new db interface. This commit is the first stage of several that are planned to convert the blockchain package into a concurrent safe package that will ultimately allow support for multi-peer download and concurrent chain processing. The goal is to update btcd proper after each step so it can take advantage of the enhancements as they are developed. In addition to the aforementioned benefit, this staged approach has been chosen since it is absolutely critical to maintain consensus. Separating the changes into several stages makes it easier for reviewers to logically follow what is happening and therefore helps prevent consensus bugs. Naturally there are significant automated tests to help prevent consensus issues as well. The main focus of this stage is to convert the blockchain package to use the new database interface and implement the chain-related functionality which it no longer handles. It also aims to improve efficiency in various areas by making use of the new database and chain capabilities. The following is an overview of the chain changes: - Update to use the new database interface - Add chain-related functionality that the old database used to handle - Main chain structure and state - Transaction spend tracking - Implement a new pruned unspent transaction output (utxo) set - Provides efficient direct access to the unspent transaction outputs - Uses a domain specific compression algorithm that understands the standard transaction scripts in order to significantly compress them - Removes reliance on the transaction index and paves the way toward eventually enabling block pruning - Modify the New function to accept a Config struct instead of inidividual parameters - Replace the old TxStore type with a new UtxoViewpoint type that makes use of the new pruned utxo set - Convert code to treat the new UtxoViewpoint as a rolling view that is used between connects and disconnects to improve efficiency - Make best chain state always set when the chain instance is created - Remove now unnecessary logic for dealing with unset best state - Make all exported functions concurrent safe - Currently using a single chain state lock as it provides a straight forward and easy to review path forward however this can be improved with more fine grained locking - Optimize various cases where full blocks were being loaded when only the header is needed to help reduce the I/O load - Add the ability for callers to get a snapshot of the current best chain stats in a concurrent safe fashion - Does not block callers while new blocks are being processed - Make error messages that reference transaction outputs consistently use <transaction hash>:<output index> - Introduce a new AssertError type an convert internal consistency checks to use it - Update tests and examples to reflect the changes - Add a full suite of tests to ensure correct functionality of the new code The following is an overview of the btcd changes: - Update to use the new database and chain interfaces - Temporarily remove all code related to the transaction index - Temporarily remove all code related to the address index - Convert all code that uses transaction stores to use the new utxo view - Rework several calls that required the block manager for safe concurrency to use the chain package directly now that it is concurrent safe - Change all calls to obtain the best hash to use the new best state snapshot capability from the chain package - Remove workaround for limits on fetching height ranges since the new database interface no longer imposes them - Correct the gettxout RPC handler to return the best chain hash as opposed the hash the txout was found in - Optimize various RPC handlers: - Change several of the RPC handlers to use the new chain snapshot capability to avoid needlessly loading data - Update several handlers to use new functionality to avoid accessing the block manager so they are able to return the data without blocking when the server is busy processing blocks - Update non-verbose getblock to avoid deserialization and serialization overhead - Update getblockheader to request the block height directly from chain and only load the header - Update getdifficulty to use the new cached data from chain - Update getmininginfo to use the new cached data from chain - Update non-verbose getrawtransaction to avoid deserialization and serialization overhead - Update gettxout to use the new utxo store versus loading full transactions using the transaction index The following is an overview of the utility changes: - Update addblock to use the new database and chain interfaces - Update findcheckpoint to use the new database and chain interfaces - Remove the dropafter utility which is no longer supported NOTE: The transaction index and address index will be reimplemented in another commit.
2015-08-26 06:03:18 +02:00
CBFilter -> CFilter, discussed with davec@
2017-01-18 09:09:05 +01:00
; Disable committed peer filtering (CF).
; nocfilters=1
Create a knob to switch CBFs off. While having them on by default. We may want to revisit this and make no CBFs the default.
2016-12-13 11:03:15 +01:00
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
; ------------------------------------------------------------------------------
; RPC server options - The following options control the built-in RPC server
; which is used to control and query information from a running btcd process.
;
Create limited RPC user. The limited user is specified with the --rpclimituser and --rpclimitpass options (or the equivalent in the config file). The config struct and loadConfig() are updated to take the new options into account. The limited user can have neither the same username nor the same password as the admin user. The package-level rpcLimit map in rpcserver.go specifies the RPC commands accessible by limited users. This map includes both HTTP/S and websocket commands. The checkAuth function gets a new return parameter to signify whether the user is authorized to change server state. The result is passed to the jsonRPCRead function and to the WebsocketHandler function in rpcwebsocket.go. The wsClient struct is updated with an "isAdmin" field signifying that the client is authorized to change server state, written by WebsocketHandler and handleMessage. The handleMessage function also checks the field to allow or disallow an RPC call. The following documentation files are updated: - doc.go - sample-btcd.conf - docs/README.md - docs/json_rpc_api.md - docs/configure_rpc_server_listen_interfaces.md
2015-03-30 19:45:31 +02:00
; NOTE: The RPC server is disabled by default if rpcuser AND rpcpass, or
; rpclimituser AND rpclimitpass, are not specified.
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
; ------------------------------------------------------------------------------
Create limited RPC user. The limited user is specified with the --rpclimituser and --rpclimitpass options (or the equivalent in the config file). The config struct and loadConfig() are updated to take the new options into account. The limited user can have neither the same username nor the same password as the admin user. The package-level rpcLimit map in rpcserver.go specifies the RPC commands accessible by limited users. This map includes both HTTP/S and websocket commands. The checkAuth function gets a new return parameter to signify whether the user is authorized to change server state. The result is passed to the jsonRPCRead function and to the WebsocketHandler function in rpcwebsocket.go. The wsClient struct is updated with an "isAdmin" field signifying that the client is authorized to change server state, written by WebsocketHandler and handleMessage. The handleMessage function also checks the field to allow or disallow an RPC call. The following documentation files are updated: - doc.go - sample-btcd.conf - docs/README.md - docs/json_rpc_api.md - docs/configure_rpc_server_listen_interfaces.md
2015-03-30 19:45:31 +02:00
; Secure the RPC API by specifying the username and password. You can also
; specify a limited username and password. You must specify at least one
; full set of credentials - limited or admin - or the RPC server will
; be disabled.
; rpcuser=whatever_admin_username_you_want
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
; rpcpass=
Create limited RPC user. The limited user is specified with the --rpclimituser and --rpclimitpass options (or the equivalent in the config file). The config struct and loadConfig() are updated to take the new options into account. The limited user can have neither the same username nor the same password as the admin user. The package-level rpcLimit map in rpcserver.go specifies the RPC commands accessible by limited users. This map includes both HTTP/S and websocket commands. The checkAuth function gets a new return parameter to signify whether the user is authorized to change server state. The result is passed to the jsonRPCRead function and to the WebsocketHandler function in rpcwebsocket.go. The wsClient struct is updated with an "isAdmin" field signifying that the client is authorized to change server state, written by WebsocketHandler and handleMessage. The handleMessage function also checks the field to allow or disallow an RPC call. The following documentation files are updated: - doc.go - sample-btcd.conf - docs/README.md - docs/json_rpc_api.md - docs/configure_rpc_server_listen_interfaces.md
2015-03-30 19:45:31 +02:00
; rpclimituser=whatever_limited_username_you_want
; rpclimitpass=
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
Make RPC section of sample-btcd.conf consistent.
2013-11-19 18:00:55 +01:00
; Specify the interfaces for the RPC server listen on. One listen address per
; line. NOTE: The default port is modified by some options such as 'testnet',
; so it is recommended to not specify a port and allow a proper default to be
Correct sample-btcd.conf RPC listen comment. The comment for the RPC listen section in the sample-btcd.conf incorrectly claimed that the default for the RPC server listener is to listen on all interfaces by default. In reality, it only listens on localhost for IPv4 and IPv6 by default. Closes #208.
2015-01-11 23:59:28 +01:00
; chosen unless you have a specific reason to do otherwise. By default, the
; RPC server will only listen on localhost for IPv4 and IPv6.
; All interfaces on default port:
Remove comments interpreted as settings in go-flags/ini_private.go in function readIni there is no mechanism for adding inline comments. Only comments that have a semicolon as the first non-whitespace character are ignored. According to Wikipedia http://en.wikipedia.org/wiki/INI_file#Comments inline comments are not universally supported. This change adds some white space for readability, but name := strings.TrimSpace(line[1 : len(line)-1]) removes accidental whitespace left in later. Closes #135.
2014-06-09 06:48:56 +02:00
; rpclisten=
; All ipv4 interfaces on default port:
; rpclisten=0.0.0.0
; All ipv6 interfaces on default port:
; rpclisten=::
; All interfaces on port 8334:
; rpclisten=:8334
; All ipv4 interfaces on port 8334:
; rpclisten=0.0.0.0:8334
; All ipv6 interfaces on port 8334:
; rpclisten=[::]:8334
; Only ipv4 localhost on port 8334:
; rpclisten=127.0.0.1:8334
; Only ipv6 localhost on port 8334:
; rpclisten=[::1]:8334
; Only ipv4 localhost on non-standard port 8337:
; rpclisten=127.0.0.1:8337
; All interfaces on non-standard port 8337:
; rpclisten=:8337
; All ipv4 interfaces on non-standard port 8337:
; rpclisten=0.0.0.0:8337
; All ipv6 interfaces on non-standard port 8337:
; rpclisten=[::]:8337
Make RPC section of sample-btcd.conf consistent.
2013-11-19 18:00:55 +01:00
Add --rpcmaxclients option with default of 10. This commit adds a new configuration option, --rpcmaxclients, to limit the number of max standard RPC clients that are served concurrently. Note that this value does not apply to websocket connections. A future commit will add support for limiting those separately. Closes #68.
2014-02-19 03:44:37 +01:00
; Specify the maximum number of concurrent RPC clients for standard connections.
; rpcmaxclients=10
Add --rpcmaxwebsockets option with default of 25. This commit adds a new configuration option, --rpcmaxwebsockets, to limit the number of max RPC websocket clients that are served concurrently.
2014-02-19 04:05:42 +01:00
; Specify the maximum number of concurrent RPC websocket clients.
; rpcmaxwebsockets=25
rpcserver: Improve JSON-RPC compatibility Avoid compatibility issues with software that relies on the behavior of bitcoind's JSON-RPC implementation. The JSON-RPC 1.0 spec defines that notifications must have their "id" set to null and states that notifications do not have a response. A JSON-RPC 2.0 notification is a request with "json-rpc":"2.0", and without an "id" member. The specification states that notifications must not be responded to. JSON-RPC 2.0 permits the null value as a valid request id, therefore such requests are not notifications. Bitcoin Core serves requests with "id":null or even an absent "id", and responds to such requests with "id":null in the response. Btcd does not respond to any request without and "id" or with "id":null, regardless the indicated JSON-RPC protocol version. In order to avoid compatibility issues with software relying on Core's behavior, this commit implements "quirks mode" as follows: - quirks mode can be enabled via configuration (disabled by default) - If no JSON-RPC version is indicated in the request, accept and respond to request with "id":null - If no JSON-RPC version is indicated in the request, accept and respond to requests without an "id" member - In both cases above, use "id":null in the response - Do not respond to request without an "id" or with "id":null when JSON-RPC version is indicated in the request (process as notification)
2016-03-02 19:43:50 +01:00
; Mirror some JSON-RPC quirks of Bitcoin Core -- NOTE: Discouraged unless
; interoperability issues need to be worked around
; rpcquirks=1
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
; Use the following setting to disable the RPC server even if the rpcuser and
; rpcpass are specified above. This allows one to quickly disable the RPC
; server without having to remove credentials from the config file.
; norpc=1
Allow disabling RPC server TLS for localhost only. This commit introduces a new flag, --notls, which can be used to disable TLS for the RPC server. However, the flag can only be used when the RPC server is bound to localhost interfaces. This is intended to prevent the situation where someone decides they want to expose the RPC server to the web for remote management/access, but forgot they have TLS disabled.
2014-12-21 01:04:07 +01:00
; Use the following setting to disable TLS for the RPC server. NOTE: This
; option only works if the RPC server is bound to localhost interfaces (which is
; the default).
; notls=1
blockchain: Rework to use new db interface. This commit is the first stage of several that are planned to convert the blockchain package into a concurrent safe package that will ultimately allow support for multi-peer download and concurrent chain processing. The goal is to update btcd proper after each step so it can take advantage of the enhancements as they are developed. In addition to the aforementioned benefit, this staged approach has been chosen since it is absolutely critical to maintain consensus. Separating the changes into several stages makes it easier for reviewers to logically follow what is happening and therefore helps prevent consensus bugs. Naturally there are significant automated tests to help prevent consensus issues as well. The main focus of this stage is to convert the blockchain package to use the new database interface and implement the chain-related functionality which it no longer handles. It also aims to improve efficiency in various areas by making use of the new database and chain capabilities. The following is an overview of the chain changes: - Update to use the new database interface - Add chain-related functionality that the old database used to handle - Main chain structure and state - Transaction spend tracking - Implement a new pruned unspent transaction output (utxo) set - Provides efficient direct access to the unspent transaction outputs - Uses a domain specific compression algorithm that understands the standard transaction scripts in order to significantly compress them - Removes reliance on the transaction index and paves the way toward eventually enabling block pruning - Modify the New function to accept a Config struct instead of inidividual parameters - Replace the old TxStore type with a new UtxoViewpoint type that makes use of the new pruned utxo set - Convert code to treat the new UtxoViewpoint as a rolling view that is used between connects and disconnects to improve efficiency - Make best chain state always set when the chain instance is created - Remove now unnecessary logic for dealing with unset best state - Make all exported functions concurrent safe - Currently using a single chain state lock as it provides a straight forward and easy to review path forward however this can be improved with more fine grained locking - Optimize various cases where full blocks were being loaded when only the header is needed to help reduce the I/O load - Add the ability for callers to get a snapshot of the current best chain stats in a concurrent safe fashion - Does not block callers while new blocks are being processed - Make error messages that reference transaction outputs consistently use <transaction hash>:<output index> - Introduce a new AssertError type an convert internal consistency checks to use it - Update tests and examples to reflect the changes - Add a full suite of tests to ensure correct functionality of the new code The following is an overview of the btcd changes: - Update to use the new database and chain interfaces - Temporarily remove all code related to the transaction index - Temporarily remove all code related to the address index - Convert all code that uses transaction stores to use the new utxo view - Rework several calls that required the block manager for safe concurrency to use the chain package directly now that it is concurrent safe - Change all calls to obtain the best hash to use the new best state snapshot capability from the chain package - Remove workaround for limits on fetching height ranges since the new database interface no longer imposes them - Correct the gettxout RPC handler to return the best chain hash as opposed the hash the txout was found in - Optimize various RPC handlers: - Change several of the RPC handlers to use the new chain snapshot capability to avoid needlessly loading data - Update several handlers to use new functionality to avoid accessing the block manager so they are able to return the data without blocking when the server is busy processing blocks - Update non-verbose getblock to avoid deserialization and serialization overhead - Update getblockheader to request the block height directly from chain and only load the header - Update getdifficulty to use the new cached data from chain - Update getmininginfo to use the new cached data from chain - Update non-verbose getrawtransaction to avoid deserialization and serialization overhead - Update gettxout to use the new utxo store versus loading full transactions using the transaction index The following is an overview of the utility changes: - Update addblock to use the new database and chain interfaces - Update findcheckpoint to use the new database and chain interfaces - Remove the dropafter utility which is no longer supported NOTE: The transaction index and address index will be reimplemented in another commit.
2015-08-26 06:03:18 +02:00
Add new option -maxorphantx The option -maxorphantx allows the user to specify the number of orphan transactions to keep in memory. Also, lower the default max orphan count from 10000 to 1000.
2015-05-05 16:53:15 +02:00
; ------------------------------------------------------------------------------
; Mempool Settings - The following options
; ------------------------------------------------------------------------------
Document limitfreerelay and norelaypriority options.
2015-07-13 18:52:17 +02:00
config: New option --minrelaytxfee --minrelaytxfee allows the user to specify the minimum transaction fee in BTC/kB in which the fee is considered a non-zero fee.
2015-10-19 22:21:31 +02:00
; Set the minimum transaction fee to be considered a non-zero fee,
; minrelaytxfee=0.00001
Document limitfreerelay and norelaypriority options.
2015-07-13 18:52:17 +02:00
; Rate-limit free transactions to the value 15 * 1000 bytes per
; minute.
; limitfreerelay=15
; Require high priority for relaying free or low-fee transactions.
; norelaypriority=0
mempool: Modify default orphan tx policy. The current max orphan transaction size causes problems with dependent transaction relay due to its artificially small size in relation to the max standard transaction size. Consequently, this modifies the orphan transaction policy by increasing the max size of each orphan to the same value allowed for standard non-orphan transactions and reducing the default max allowed number of orphans to 100. From a memory usage standpoint, the worst case max mem usage prior to this change was 5MB plus structure and tracking overhead (1000 max orphans * 5KB max each). With this, that is raised to 10MB (100 max orphans * 100KB max each) in the worst case. It is important to note that the values were originally implemented as a naive means to control the size of the orphan pool before several of the recent enhancements which more aggressively remove orphans from the orphan pool were added, so they needed to be evaluated again. For a very long time prior to recent changes, the orphan pool would quickly reach the max allowed worst-case usage and effectively stay there forever whereas with more recent changes, the actual run-time orphan pool usage is usually much smaller. Finally, as another point in favor of this change, as the network has evolved, nodes have generally become better about orphan management and as such missing ancestors will typically either be broadcast or mined fairly quickly resulting in fewer overall orphans.
2016-10-25 07:07:21 +02:00
; Limit orphan transaction pool to 100 transactions.
; maxorphantx=100
Add new option -maxorphantx The option -maxorphantx allows the user to specify the number of orphan transactions to keep in memory. Also, lower the default max orphan count from 10000 to 1000.
2015-05-05 16:53:15 +02:00
config: New option --blocksonly (#553) The --blocksonly configuration option disables accepting transactions from remote peers. It will still accept, relay, and rebroadcast valid transactions sent via RPC or websockets.
2016-04-08 01:16:46 +02:00
; Do not accept transactions from remote peers.
; blocksonly=1
config: introduce new flags to accept/reject non-std transactions This commit adds two new cli flags: one for accepting non-std transactions, and the other for rejecting non-std transactions. The two flag are rejected when using concurrently. Config parsing is set up such that, the desired policy expressed via the config always overrides the policy set by default for a particular chain. The doc.go files and the sample-btcd.conf file have been updated to document the new flags exposing further policy control.
2016-08-23 03:02:53 +02:00
; Relay non-standard transactions regardless of default network settings.
; relaynonstd=1
; Reject non-standard transactions regardless of default network settings.
; rejectnonstd=1
blockchain: Rework to use new db interface. This commit is the first stage of several that are planned to convert the blockchain package into a concurrent safe package that will ultimately allow support for multi-peer download and concurrent chain processing. The goal is to update btcd proper after each step so it can take advantage of the enhancements as they are developed. In addition to the aforementioned benefit, this staged approach has been chosen since it is absolutely critical to maintain consensus. Separating the changes into several stages makes it easier for reviewers to logically follow what is happening and therefore helps prevent consensus bugs. Naturally there are significant automated tests to help prevent consensus issues as well. The main focus of this stage is to convert the blockchain package to use the new database interface and implement the chain-related functionality which it no longer handles. It also aims to improve efficiency in various areas by making use of the new database and chain capabilities. The following is an overview of the chain changes: - Update to use the new database interface - Add chain-related functionality that the old database used to handle - Main chain structure and state - Transaction spend tracking - Implement a new pruned unspent transaction output (utxo) set - Provides efficient direct access to the unspent transaction outputs - Uses a domain specific compression algorithm that understands the standard transaction scripts in order to significantly compress them - Removes reliance on the transaction index and paves the way toward eventually enabling block pruning - Modify the New function to accept a Config struct instead of inidividual parameters - Replace the old TxStore type with a new UtxoViewpoint type that makes use of the new pruned utxo set - Convert code to treat the new UtxoViewpoint as a rolling view that is used between connects and disconnects to improve efficiency - Make best chain state always set when the chain instance is created - Remove now unnecessary logic for dealing with unset best state - Make all exported functions concurrent safe - Currently using a single chain state lock as it provides a straight forward and easy to review path forward however this can be improved with more fine grained locking - Optimize various cases where full blocks were being loaded when only the header is needed to help reduce the I/O load - Add the ability for callers to get a snapshot of the current best chain stats in a concurrent safe fashion - Does not block callers while new blocks are being processed - Make error messages that reference transaction outputs consistently use <transaction hash>:<output index> - Introduce a new AssertError type an convert internal consistency checks to use it - Update tests and examples to reflect the changes - Add a full suite of tests to ensure correct functionality of the new code The following is an overview of the btcd changes: - Update to use the new database and chain interfaces - Temporarily remove all code related to the transaction index - Temporarily remove all code related to the address index - Convert all code that uses transaction stores to use the new utxo view - Rework several calls that required the block manager for safe concurrency to use the chain package directly now that it is concurrent safe - Change all calls to obtain the best hash to use the new best state snapshot capability from the chain package - Remove workaround for limits on fetching height ranges since the new database interface no longer imposes them - Correct the gettxout RPC handler to return the best chain hash as opposed the hash the txout was found in - Optimize various RPC handlers: - Change several of the RPC handlers to use the new chain snapshot capability to avoid needlessly loading data - Update several handlers to use new functionality to avoid accessing the block manager so they are able to return the data without blocking when the server is busy processing blocks - Update non-verbose getblock to avoid deserialization and serialization overhead - Update getblockheader to request the block height directly from chain and only load the header - Update getdifficulty to use the new cached data from chain - Update getmininginfo to use the new cached data from chain - Update non-verbose getrawtransaction to avoid deserialization and serialization overhead - Update gettxout to use the new utxo store versus loading full transactions using the transaction index The following is an overview of the utility changes: - Update addblock to use the new database and chain interfaces - Update findcheckpoint to use the new database and chain interfaces - Remove the dropafter utility which is no longer supported NOTE: The transaction index and address index will be reimplemented in another commit.
2015-08-26 06:03:18 +02:00
indexers: Implement optional tx/address indexes. This introduces a new indexing infrastructure for supporting optional indexes using the new database and blockchain infrastructure along with two concrete indexer implementations which provide both a transaction-by-hash and a transaction-by-address index. The new infrastructure is mostly separated into a package named indexers which is housed under the blockchain package. In order to support this, a new interface named IndexManager has been introduced in the blockchain package which provides methods to be notified when the chain has been initialized and when blocks are connected and disconnected from the main chain. A concrete implementation of an index manager is provided by the new indexers package. The new indexers package also provides a new interface named Indexer which allows the index manager to manage concrete index implementations which conform to the interface. The following is high level overview of the main index infrastructure changes: - Define a new IndexManager interface in the blockchain package and modify the package to make use of the interface when specified - Create a new indexers package - Provides an Index interface which allows concrete indexes to plugin to an index manager - Provides a concrete IndexManager implementation - Handles the lifecycle of all indexes it manages - Tracks the index tips - Handles catching up disabled indexes that have been reenabled - Handles reorgs while the index was disabled - Invokes the appropriate methods for all managed indexes to allow them to index and deindex the blocks and transactions - Implement a transaction-by-hash index - Makes use of internal block IDs to save a significant amount of space and indexing costs over the old transaction index format - Implement a transaction-by-address index - Makes use of a leveling scheme in order to provide a good tradeoff between space required and indexing costs - Supports enabling and disabling indexes at will - Support the ability to drop indexes if they are no longer desired The following is an overview of the btcd changes: - Add a new index logging subsystem - Add new options --txindex and --addrindex in order to enable the optional indexes - NOTE: The transaction index will automatically be enabled when the address index is enabled because it depends on it - Add new options --droptxindex and --dropaddrindex to allow the indexes to be removed - NOTE: The address index will also be removed when the transaction index is dropped because it depends on it - Update getrawtransactions RPC to make use of the transaction index - Reimplement the searchrawtransaction RPC that makes use of the address index - Update sample-btcd.conf to include sample usage for the new optional index flags
2016-02-19 05:51:18 +01:00
; ------------------------------------------------------------------------------
; Optional Indexes
; ------------------------------------------------------------------------------
; Build and maintain a full hash-based transaction index which makes all
; transactions available via the getrawtransaction RPC.
; txindex=1
; Build and maintain a full address-based transaction index which makes the
; searchrawtransactions RPC available.
; addrindex=1
sampleconfig: Remove duplicate setting. `addrindex` was present twice.
2018-01-28 17:25:55 +01:00
; Delete the entire address index on start up, then exit.
; dropaddrindex=0
indexers: Implement optional tx/address indexes. This introduces a new indexing infrastructure for supporting optional indexes using the new database and blockchain infrastructure along with two concrete indexer implementations which provide both a transaction-by-hash and a transaction-by-address index. The new infrastructure is mostly separated into a package named indexers which is housed under the blockchain package. In order to support this, a new interface named IndexManager has been introduced in the blockchain package which provides methods to be notified when the chain has been initialized and when blocks are connected and disconnected from the main chain. A concrete implementation of an index manager is provided by the new indexers package. The new indexers package also provides a new interface named Indexer which allows the index manager to manage concrete index implementations which conform to the interface. The following is high level overview of the main index infrastructure changes: - Define a new IndexManager interface in the blockchain package and modify the package to make use of the interface when specified - Create a new indexers package - Provides an Index interface which allows concrete indexes to plugin to an index manager - Provides a concrete IndexManager implementation - Handles the lifecycle of all indexes it manages - Tracks the index tips - Handles catching up disabled indexes that have been reenabled - Handles reorgs while the index was disabled - Invokes the appropriate methods for all managed indexes to allow them to index and deindex the blocks and transactions - Implement a transaction-by-hash index - Makes use of internal block IDs to save a significant amount of space and indexing costs over the old transaction index format - Implement a transaction-by-address index - Makes use of a leveling scheme in order to provide a good tradeoff between space required and indexing costs - Supports enabling and disabling indexes at will - Support the ability to drop indexes if they are no longer desired The following is an overview of the btcd changes: - Add a new index logging subsystem - Add new options --txindex and --addrindex in order to enable the optional indexes - NOTE: The transaction index will automatically be enabled when the address index is enabled because it depends on it - Add new options --droptxindex and --dropaddrindex to allow the indexes to be removed - NOTE: The address index will also be removed when the transaction index is dropped because it depends on it - Update getrawtransactions RPC to make use of the transaction index - Reimplement the searchrawtransaction RPC that makes use of the address index - Update sample-btcd.conf to include sample usage for the new optional index flags
2016-02-19 05:51:18 +01:00
Integrate a valid ECDSA signature cache into btcd Introduce an ECDSA signature verification into btcd in order to mitigate a certain DoS attack and as a performance optimization. The benefits of SigCache are two fold. Firstly, usage of SigCache mitigates a DoS attack wherein an attacker causes a victim's client to hang due to worst-case behavior triggered while processing attacker crafted invalid transactions. A detailed description of the mitigated DoS attack can be found here: https://bitslog.wordpress.com/2013/01/23/fixed-bitcoin-vulnerability-explanation-why-the-signature-cache-is-a-dos-protection/ Secondly, usage of the SigCache introduces a signature verification optimization which speeds up the validation of transactions within a block, if they've already been seen and verified within the mempool. The server itself manages the sigCache instance. The blockManager and txMempool respectively now receive pointers to the created sigCache instance. All read (sig triplet existence) operations on the sigCache will not block unless a separate goroutine is adding an entry (writing) to the sigCache. GetBlockTemplate generation now also utilizes the sigCache in order to avoid unnecessarily double checking signatures when generating a template after previously accepting a txn to the mempool. Consequently, the CPU miner now also employs the same optimization. The maximum number of entries for the sigCache has been introduced as a config parameter in order to allow users to configure the amount of memory consumed by this new additional caching.
2015-09-25 01:22:00 +02:00
; ------------------------------------------------------------------------------
; Signature Verification Cache
; ------------------------------------------------------------------------------
; Limit the signature cache to a max of 50000 entries.
; sigcachemaxsize=50000
blockchain: Rework to use new db interface. This commit is the first stage of several that are planned to convert the blockchain package into a concurrent safe package that will ultimately allow support for multi-peer download and concurrent chain processing. The goal is to update btcd proper after each step so it can take advantage of the enhancements as they are developed. In addition to the aforementioned benefit, this staged approach has been chosen since it is absolutely critical to maintain consensus. Separating the changes into several stages makes it easier for reviewers to logically follow what is happening and therefore helps prevent consensus bugs. Naturally there are significant automated tests to help prevent consensus issues as well. The main focus of this stage is to convert the blockchain package to use the new database interface and implement the chain-related functionality which it no longer handles. It also aims to improve efficiency in various areas by making use of the new database and chain capabilities. The following is an overview of the chain changes: - Update to use the new database interface - Add chain-related functionality that the old database used to handle - Main chain structure and state - Transaction spend tracking - Implement a new pruned unspent transaction output (utxo) set - Provides efficient direct access to the unspent transaction outputs - Uses a domain specific compression algorithm that understands the standard transaction scripts in order to significantly compress them - Removes reliance on the transaction index and paves the way toward eventually enabling block pruning - Modify the New function to accept a Config struct instead of inidividual parameters - Replace the old TxStore type with a new UtxoViewpoint type that makes use of the new pruned utxo set - Convert code to treat the new UtxoViewpoint as a rolling view that is used between connects and disconnects to improve efficiency - Make best chain state always set when the chain instance is created - Remove now unnecessary logic for dealing with unset best state - Make all exported functions concurrent safe - Currently using a single chain state lock as it provides a straight forward and easy to review path forward however this can be improved with more fine grained locking - Optimize various cases where full blocks were being loaded when only the header is needed to help reduce the I/O load - Add the ability for callers to get a snapshot of the current best chain stats in a concurrent safe fashion - Does not block callers while new blocks are being processed - Make error messages that reference transaction outputs consistently use <transaction hash>:<output index> - Introduce a new AssertError type an convert internal consistency checks to use it - Update tests and examples to reflect the changes - Add a full suite of tests to ensure correct functionality of the new code The following is an overview of the btcd changes: - Update to use the new database and chain interfaces - Temporarily remove all code related to the transaction index - Temporarily remove all code related to the address index - Convert all code that uses transaction stores to use the new utxo view - Rework several calls that required the block manager for safe concurrency to use the chain package directly now that it is concurrent safe - Change all calls to obtain the best hash to use the new best state snapshot capability from the chain package - Remove workaround for limits on fetching height ranges since the new database interface no longer imposes them - Correct the gettxout RPC handler to return the best chain hash as opposed the hash the txout was found in - Optimize various RPC handlers: - Change several of the RPC handlers to use the new chain snapshot capability to avoid needlessly loading data - Update several handlers to use new functionality to avoid accessing the block manager so they are able to return the data without blocking when the server is busy processing blocks - Update non-verbose getblock to avoid deserialization and serialization overhead - Update getblockheader to request the block height directly from chain and only load the header - Update getdifficulty to use the new cached data from chain - Update getmininginfo to use the new cached data from chain - Update non-verbose getrawtransaction to avoid deserialization and serialization overhead - Update gettxout to use the new utxo store versus loading full transactions using the transaction index The following is an overview of the utility changes: - Update addblock to use the new database and chain interfaces - Update findcheckpoint to use the new database and chain interfaces - Remove the dropafter utility which is no longer supported NOTE: The transaction index and address index will be reimplemented in another commit.
2015-08-26 06:03:18 +02:00
Implement a built-in concurrent CPU miner. This commit implements a built-in concurrent CPU miner that can be enabled with the combination of the --generate and --miningaddr options. The --blockminsize, --blockmaxsize, and --blockprioritysize configuration options wich already existed prior to this commit control the block template generation and hence affect blocks mined via the new CPU miner. The following is a quick overview of the changes and design: - Starting btcd with --generate and no addresses specified via --miningaddr will give an error and exit immediately - Makes use of multiple worker goroutines which independently create block templates, solve them, and submit the solved blocks - The default number of worker threads are based on the number of processor cores in the system and can be dynamically changed at run-time - There is a separate speed monitor goroutine used to collate periodic updates from the workers to calculate overall hashing speed - The current mining state, number of workers, and hashes per second can be queried - Updated sample-btcd.conf file has been updated to include the coin generation (mining) settings - Updated doc.go for the new command line options In addition the old --getworkkey option is now deprecated in favor of the new --miningaddr option. This was changed for a few reasons: - There is no reason to have a separate list of keys for getwork and CPU mining - getwork is deprecated and will be going away in the future so that means the --getworkkey flag will also be going away - Having the work 'key' in the option can be confused with wanting a private key while --miningaddr make it a little more clear it is an address that is required Closes #137. Reviewed by @jrick.
2014-06-12 03:09:38 +02:00
; ------------------------------------------------------------------------------
; Coin Generation (Mining) Settings - The following options control the
; generation of block templates used by external mining applications through RPC
; calls as well as the built-in CPU miner (if enabled).
; ------------------------------------------------------------------------------
; Enable built-in CPU mining.
;
; NOTE: This is typically only useful for testing purposes such as testnet or
btcd/multi: fix a number of typos in comments.
2017-10-29 20:56:03 +01:00
; simnet since the difficulty on mainnet is far too high for CPU mining to be
Implement a built-in concurrent CPU miner. This commit implements a built-in concurrent CPU miner that can be enabled with the combination of the --generate and --miningaddr options. The --blockminsize, --blockmaxsize, and --blockprioritysize configuration options wich already existed prior to this commit control the block template generation and hence affect blocks mined via the new CPU miner. The following is a quick overview of the changes and design: - Starting btcd with --generate and no addresses specified via --miningaddr will give an error and exit immediately - Makes use of multiple worker goroutines which independently create block templates, solve them, and submit the solved blocks - The default number of worker threads are based on the number of processor cores in the system and can be dynamically changed at run-time - There is a separate speed monitor goroutine used to collate periodic updates from the workers to calculate overall hashing speed - The current mining state, number of workers, and hashes per second can be queried - Updated sample-btcd.conf file has been updated to include the coin generation (mining) settings - Updated doc.go for the new command line options In addition the old --getworkkey option is now deprecated in favor of the new --miningaddr option. This was changed for a few reasons: - There is no reason to have a separate list of keys for getwork and CPU mining - getwork is deprecated and will be going away in the future so that means the --getworkkey flag will also be going away - Having the work 'key' in the option can be confused with wanting a private key while --miningaddr make it a little more clear it is an address that is required Closes #137. Reviewed by @jrick.
2014-06-12 03:09:38 +02:00
; worth your while.
; generate=false
mining: drop getwork support. Since the Midstate is no longer needed, switch to using crypto/sha256.
2017-01-11 16:00:16 +01:00
; Add addresses to pay mined blocks to for CPU mining and potentially in the
; block templates generated for the getblocktemplate RPC. One address per line.
Implement a built-in concurrent CPU miner. This commit implements a built-in concurrent CPU miner that can be enabled with the combination of the --generate and --miningaddr options. The --blockminsize, --blockmaxsize, and --blockprioritysize configuration options wich already existed prior to this commit control the block template generation and hence affect blocks mined via the new CPU miner. The following is a quick overview of the changes and design: - Starting btcd with --generate and no addresses specified via --miningaddr will give an error and exit immediately - Makes use of multiple worker goroutines which independently create block templates, solve them, and submit the solved blocks - The default number of worker threads are based on the number of processor cores in the system and can be dynamically changed at run-time - There is a separate speed monitor goroutine used to collate periodic updates from the workers to calculate overall hashing speed - The current mining state, number of workers, and hashes per second can be queried - Updated sample-btcd.conf file has been updated to include the coin generation (mining) settings - Updated doc.go for the new command line options In addition the old --getworkkey option is now deprecated in favor of the new --miningaddr option. This was changed for a few reasons: - There is no reason to have a separate list of keys for getwork and CPU mining - getwork is deprecated and will be going away in the future so that means the --getworkkey flag will also be going away - Having the work 'key' in the option can be confused with wanting a private key while --miningaddr make it a little more clear it is an address that is required Closes #137. Reviewed by @jrick.
2014-06-12 03:09:38 +02:00
; miningaddr=1yourbitcoinaddress
; miningaddr=1yourbitcoinaddress2
; miningaddr=1yourbitcoinaddress3
; Specify the minimum block size in bytes to create. By default, only
; transactions which have enough fees or a high enough priority will be included
; in generated block templates. Specifying a minimum block size will instead
; attempt to fill generated block templates up with transactions until it is at
; least the specified number of bytes.
; blockminsize=0
; Specify the maximum block size in bytes to create. This value will be limited
Update sample config file. This commit adds a couple of options which were not details in the sample config file. It also fixes a couple of typos and makes the example default maxpeers setting in the config file match the actual default used in btcd.
2014-09-18 22:11:17 +02:00
; to the consensus limit if it is larger than that value.
Implement a built-in concurrent CPU miner. This commit implements a built-in concurrent CPU miner that can be enabled with the combination of the --generate and --miningaddr options. The --blockminsize, --blockmaxsize, and --blockprioritysize configuration options wich already existed prior to this commit control the block template generation and hence affect blocks mined via the new CPU miner. The following is a quick overview of the changes and design: - Starting btcd with --generate and no addresses specified via --miningaddr will give an error and exit immediately - Makes use of multiple worker goroutines which independently create block templates, solve them, and submit the solved blocks - The default number of worker threads are based on the number of processor cores in the system and can be dynamically changed at run-time - There is a separate speed monitor goroutine used to collate periodic updates from the workers to calculate overall hashing speed - The current mining state, number of workers, and hashes per second can be queried - Updated sample-btcd.conf file has been updated to include the coin generation (mining) settings - Updated doc.go for the new command line options In addition the old --getworkkey option is now deprecated in favor of the new --miningaddr option. This was changed for a few reasons: - There is no reason to have a separate list of keys for getwork and CPU mining - getwork is deprecated and will be going away in the future so that means the --getworkkey flag will also be going away - Having the work 'key' in the option can be confused with wanting a private key while --miningaddr make it a little more clear it is an address that is required Closes #137. Reviewed by @jrick.
2014-06-12 03:09:38 +02:00
; blockmaxsize=750000
; Specify the size in bytes of the high-priority/low-fee area when creating a
; block. Transactions which consist of large amounts, old inputs, and small
; sizes have the highest priority. One consequence of this is that as low-fee
; or free transactions age, they raise in priority thereby making them more
; likely to be included in this section of a new block. This value is limited
; by the blackmaxsize option and will be limited as needed.
; blockprioritysize=50000
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
; ------------------------------------------------------------------------------
; Debug
; ------------------------------------------------------------------------------
; Debug logging level.
Update sample conf regarding debuglevel subsystems. The debuglevel parameter has accepted subsystems in additional to an overall level for quite some time, but the sample config file was not updated to reflect that. This commit updates the sample config file accordingly.
2014-02-28 16:52:44 +01:00
; Valid levels are {trace, debug, info, warn, error, critical}
; You may also specify <subsystem>=<level>,<subsystem2>=<level>,... to set
; log level for individual subsystems. Use btcd --debuglevel=show to list
; available subsystems.
Improve sample-btcd.conf. This commit improves the sample-btcd.conf file by including some explanatory text and adding a few more available options.
2013-08-07 19:12:46 +02:00
; debuglevel=info
Add profile option to sample configuration file.
2013-09-18 00:28:07 +02:00
; The port used to listen for HTTP profile requests. The profile server will
; be disabled if this option is not specified. The profile information can be
; accessed at http://localhost:<profileport>/debug/pprof once running.
; profile=6061
Reference in a new issue Copy permalink