mirror of
https://github.com/dashpay/dash.git
synced 2024-12-27 13:03:17 +01:00
a8820d894f
fab558612278909df93bdf88f5727b04f13aef0f doc: Use precise permission flags where possible (MarcoFalke)
Pull request description:
Instead of mentioning the all-encompassing `-whitelist*` settings, change the docs to mention the exact permission flag that will influence the behaviour.
This is needed because in the future, the too-broad `-whitelist*` settings (they either include *all* permission flags or apply to *all* peers) might be deprecated to require the permission flags to be enumerated.
Alternatively, in the future there could be an RPC to set the net permission flags on an existing connection, in which case the `-whitelist*` terminology is of no help.
ACKs for top commit:
jnewbery:
reACK fab558612278909df93bdf88f5727b04f13aef0f
fjahr:
Code review ACK fab558612278909df93bdf88f5727b04f13aef0f
jonatack:
ACK fab558612278909df93bdf88f5727b04f13aef0f
Tree-SHA512: c7dea3e577d90103bb2b0ffab7b7c8640b388932a3a880f69e2b70747fc9213dc1f437085671fd54c902ec2a578458b8a2fae6dbe076642fb88efbf9fa9e679c
57 lines
2.4 KiB
Markdown
57 lines
2.4 KiB
Markdown
Reduce Traffic
|
|
==============
|
|
|
|
Some node operators need to deal with bandwidth caps imposed by their ISPs.
|
|
|
|
By default, Dash Core allows up to 125 connections to different peers, 10 of
|
|
which are outbound. You can therefore, have at most 115 inbound connections.
|
|
Of the 10 outbound peers, there can be 8 full-relay connections and 2
|
|
block-relay-only ones.
|
|
|
|
The default settings can result in relatively significant traffic consumption.
|
|
|
|
Ways to reduce traffic:
|
|
|
|
## 1. Use `-maxuploadtarget=<MiB per day>`
|
|
|
|
A major component of the traffic is caused by serving historic blocks to other nodes
|
|
during the initial blocks download phase (syncing up a new node).
|
|
This option can be specified in MiB per day and is turned off by default.
|
|
This is *not* a hard limit; only a threshold to minimize the outbound
|
|
traffic. When the limit is about to be reached, the uploaded data is cut by no
|
|
longer serving historic blocks (blocks older than one week).
|
|
Keep in mind that new nodes require other nodes that are willing to serve
|
|
historic blocks.
|
|
|
|
Whitelisted peers will never be disconnected, although their traffic counts for
|
|
calculating the target.
|
|
|
|
## 2. Disable "listening" (`-listen=0`)
|
|
|
|
Disabling listening will result in fewer nodes connected (remember the maximum of 10
|
|
outbound peers). Fewer nodes will result in less traffic usage as you are relaying
|
|
blocks and transactions to fewer nodes.
|
|
|
|
## 3. Reduce maximum connections (`-maxconnections=<num>`)
|
|
|
|
Reducing the maximum connected nodes to a minimum could be desirable if traffic
|
|
limits are tiny. Keep in mind that dash's trustless model works best if you are
|
|
connected to a handful of nodes.
|
|
|
|
## 4. Turn off transaction relay (`-blocksonly`)
|
|
|
|
Forwarding transactions to peers increases the P2P traffic. To only sync blocks
|
|
with other peers, you can disable transaction relay.
|
|
|
|
Be reminded of the effects of this setting.
|
|
|
|
- Fee estimation will no longer work.
|
|
- It sets the flag "-walletbroadcast" to be "0", only if it is currently unset.
|
|
Doing so disables the automatic broadcasting of transactions from wallet. Not
|
|
relaying other's transactions could hurt your privacy if used while a wallet
|
|
is loaded or if you use the node to broadcast transactions.
|
|
- If a peer has the forcerelay permission, we will still receive and relay
|
|
their transactions.
|
|
- It makes block propagation slower because compact block relay can only be
|
|
used when transaction relay is enabled.
|