Be careful when changing the settings below as they may cause issues
with other apps on your Umbrel that connect to your Bitcoin node. Only make
changes if you understand the potential effects on connected apps or
wallets.
Peer Settings
Configure how your node connects and interacts with peers (other nodes) on the network.
Connect to peers available on the clearnet (publicly accessible internet).
Connect to peers available on the Tor network.
Connect to peers available on the clearnet via Tor to preserve your anonymity at the cost of slightly less security.
Connect to peers available on the I2P network.
Broadcast your node to the Bitcoin network to help other nodes
access the blockchain. You may need to set up port forwarding on
your router to allow incoming connections from clearnet-only peers.
Share compact block filter data with connected light clients (like wallets) connected to your node, allowing them to get only the transaction information they are
interested in from your node without having to download the entire blockchain. Enabling this will automatically enable Block Filter Index below.
Note: If you disable Peer Block Filters, you will need to also manually toggle off Block Filter Index if you
want to stop storing block filter data.
Store an index of compact block filters which allows faster wallet re-scanning.
In order to serve compact block filters to peers, you must also enable Peer Block Filters above.
Note: To use 'Block Filter Index' with a pruned node, you must enable it when you start the 'Prune Old Blocks' process under the Optimization category.
If your node is already pruned and 'Block Filter Index' is off, enabling it will prevent your node from starting. To fix this while keeping 'Block Filter Index' on, you will need to either reindex your node or turn off 'Prune Old Blocks'.
Enable support for BIP37, a feature used by older light clients (like wallets) to get only the transaction information they are interested in from your node without having to download the entire blockchain.
Note: Bloom filters can have privacy and denial-of-service (DoS) risks, especially if your node is publicly reachable; its use is discouraged in favour of the more modern compact block filters.
Set the duration (in seconds) that a peer will be banned from connecting to your node if they violate protocol rules or exhibit suspicious behavior.
By adjusting bantime, you can maintain your node's security and network integrity, while preventing repeat offenders from causing disruptions.
A longer bantime increases the ban period, discouraging misbehavior, while a shorter bantime allows for quicker reconnections but may require more frequent manual monitoring of peer activity.
Set the maximum number of peers your node can connect to simultaneously. By managing this, you can optimize your node's network usage and system resources based on your device's capacity.
A higher value enables your node to maintain more connections, potentially improving network stability and data sharing. A lower value conserves system resources and bandwidth,
which may be beneficial for devices with limited capabilities.
Set the maximum amount of memory (in kilobytes) allocated for storing incoming data from other nodes in the network.
A larger buffer size allows your node to handle more incoming data simultaneously, while a smaller size reduces memory consumption but may limit the amount of data your node can process at once.
Set the maximum memory (in kilobytes) dedicated to storing outgoing data sent to other nodes in the network.
A larger buffer size enables your node to send more data simultaneously, while a smaller size conserves memory but may
restrict the volume of data your node can transmit at once.
Set the maximum allowed time adjustment (in seconds) your node can make based on the time data received from other nodes in the network.
By controlling it, you can maintain your node's time accuracy while reducing the risk of incorrect time adjustments that could affect block validation and other time-sensitive processes.
A lower value provides a stricter limit on time corrections, while a higher value allows more flexibility based on network data.
Set the maximum time (in seconds) that your node will wait for a response from a connected peer before considering it unresponsive and disconnecting.
Adjusting peertimeout helps you maintain stable connections with responsive peers while ensuring your node doesn't waste resources on unresponsive ones.
A shorter timeout value allows for quicker disconnection from unresponsive peers, while a longer timeout provides more time for slow-responding peers to maintain a connection.
Set the maximum time (in seconds) that your node will wait for a response from a newly connecting peer during the initial handshake process before considering it unresponsive and disconnecting.
Fine-tuning it helps you ensure your node establishes stable connections with responsive peers while avoiding unresponsive ones. A shorter timeout value leads to faster disconnection from unresponsive peers,
while a longer timeout allows more time for slow-responding peers to complete the handshake.
Limit the maximum amount of data (in MB) your node will upload to other peers in the network within a 24-hour period. Setting this to 0 (default) means that there is no limit.
By adjusting it, you can optimize your node's bandwidth usage and maintain a balance between sharing data with the network and conserving your internet resources.
A higher upload target allows your node to contribute more data to the network, while a lower target helps you save bandwidth for other uses.
Note: Peers that are whitelisted are exempt from this limit. By default, your node whitelists apps on your Umbrel (e.g., Electrs).
However, external apps and wallets that are connected via the P2P port may fail to receive data from your node if your node hits the 24-hour upload limit.
Optimization
Fine tune the performance and resource usage of your node.
Choose the size of the UTXO set to store in RAM. A larger cache can
speed up the initial synchronization of your Bitcoin node, but after
the initial sync is complete, a larger cache value does not significantly
improve performance and may use more RAM than needed.
Allow any transaction in the mempool of your Bitcoin node to be replaced with
a newer version of the same transaction that includes a higher fee.
Relay and mine data carrier transactions.
Adjust the maximum size of relayed transactions containing arbitrary data.
Note: datacarrier takes precedence over datacarriersize.
Reject parasitic transactions that are non-monetary.
Reject token transactions (runes).
Relay non-P2SH multisig.
Fee rates (in BTC/kB) smaller than this are considered zero fee for relaying, mining and transaction creation
Equivalent bytes per sigop in transactions for relay and mining
Minimum bytes per sigop in transactions we relay and mine
Do not accept transactions if number of in-mempool ancestors is or more
Do not accept transactions whose size with all in-mempool ancestors exceeds kilobytes
Do not accept transactions if any ancestor would have or more in-mempool descendants
Do not accept transactions if any ancestor would have more than kilobytes of in-mempool descendants
Relay legacy pubkey outputs.
Maximum size of scripts we relay and mine, in bytes
Treat extra data in transactions as at least N vbytes per actual byte
Treat extra data in transactions as at least N vbytes per actual byte
Fee rate (in BTC/kvB) used to define dust, the value of an output such that it will cost more than its value in fees at this fee rate to spend it.
Set maximum block size in bytes
Set maximum BIP141 block weight
Extra transactions to keep in memory for compact block reconstructions
Save storage space by pruning (deleting) old blocks and keeping only
a limited copy of the blockchain. Use the slider to choose the size
of the blockchain you want to store. It may take some time for your
node to be online after you turn on pruning. If you turn off pruning
after turning it on, you'll need to download the entire blockchain
Set the maximum size that your node will allocate (in RAM) for storing unconfirmed transactions before they are included in a block.
By adjusting maxmempool, you can optimize your node's performance and balance memory usage based on your device's capabilities.
A larger maxmempool allows your node to store more unconfirmed transactions, providing more accurate statistics on explorer apps like Mempool.
Set the time threshold (in hours) for unconfirmed transactions to remain in your node's mempool before being removed.
By adjusting it, you can manage your node's memory usage and ensure outdated, unconfirmed transactions are discarded.
A shorter expiry time helps keep your mempool up-to-date and reduces memory usage, while a longer expiry time allows transactions
to remain in the pool for an extended period in case of network congestion or delayed confirmations.
Saves unconfirmed transactions in your node's mempool when it's shutting down and reloads them upon startup.
Enabling this setting helps maintain a consistent mempool and prevents the loss of unconfirmed transactions during a restart.
Disabling this setting will clear the mempool upon restart, which may reduce startup time but requires your node to rebuild its mempool from scratch.
Set the maximum number of orphan transactions (transactions missing one or more of their inputs) that your node will keep in memory.
By fine-tuning it, you can optimize your node's memory usage and manage its performance based on your device's capabilities.
A larger limit allows your node to store more orphan transactions, potentially increasing the chances of finding missing inputs.
A smaller limit conserves memory but will result in your node evicting some orphan transactions from memory when the limit is reached.
RPC and REST
Configure RPC and REST API access to your node.
Enabling the public REST API can help you connect certain wallets and apps to your node. However, because the REST API access is unauthenticated, it can lead to unauthorized access, privacy degradation, and denial-of-service (DoS) attacks.
Set the maximum number of queued Remote Procedure Call (RPC) requests your node can handle
(e.g., from connected wallets or other apps), helping you strike a balance between performance and resource usage.
Higher values can improve processing speed at the cost of increased system resources.
Network Selection
Switch between mainnet, testnet, regtest, and signet.
Choose which blockchain your node will connect to.
If you change the chain, restart your Umbrel to make sure any
apps connected to your node continue to work properly.
Please fix the following errors and try again:
{{ error }}
Restore Default Settings
Save and Restart Bitcoin Node