Bitcoin core no block source available

This can often prevent an extra roundtrip before the actual block is downloaded. There was no upper bound on the size of the mempool and attackers could send a large number of transactions paying just slighly more than the default minimum relay fee to crash nodes with relatively low RAM.

A temporary workaround for previous versions of Bitcoin Core was to raise the default minimum relay fee. The default value is MB and can be configured with the -maxmempool parameter.

The initial minimum relay feerate is set to satoshis per kB. These limits can be overriden using command line arguments; see the extended help --help -help-debug for more information.

It is now possible to replace transactions in the transaction memory pool of Bitcoin Core 0. Moreover, a replacement transaction may only be accepted when it pays sufficient fee, as described in [BIP ] https: Transactions signaling replacement under BIP will still be allowed into the mempool in this configuration, but replacements will be rejected.

This option is intended for miners who want to continue the transaction selection behavior of previous releases. The -mempoolreplacement option is not recommended for wallet users seeking to avoid receipt of unconfirmed opt-in transactions, because this option does not prevent transactions which are replaceable under BIP from being accepted only subsequent replacements, which other nodes on the network that implement BIP are likely to relay and mine.

Note that the wallet in Bitcoin Core 0. This file is generated with random content when the daemon starts, and deleted when it exits. Its contents are used as authentication token. Read access to this file controls who can access through RPC. By default it is stored in the data directory but its location can be overridden with the option -rpccookiefile. This calculation is used for relaying of transactions which do not pay the minimum relay fee, and can be used as an alternative way of sorting transactions for mined blocks.

In Bitcoin Core 0. Transactions which do not meet this higher effective minimum relay fee will not be relayed or mined even if they rank highly according to the priority heuristic. The mining of transactions based on their priority is also now disabled by default. Additionally, as a result of computational simplifications, the priority value used for transactions received with unconfirmed inputs is lower than in prior versions due to avoiding recomputing the amounts as input transactions confirm.

External miner policy set via the prioritisetransaction RPC to rank transactions already in the mempool continues to work as it has previously. Note, however, that if mining priority transactions is left disabled, the priority delta will be ignored and only the fee metric will be effective. This internal automatic prioritization handling is being considered for removal entirely in Bitcoin Core 0.

Community direction on this topic is particularly requested to help set project priorities. Starting with Tor version 0. Bitcoin Core has been updated to make use of this. This means that if Tor is running and proper authorization is available , Bitcoin Core automatically creates a hidden service to listen on, without manual configuration.

Bitcoin Core will also use Tor automatically to connect to other. This will positively affect the number of available. This new feature is enabled by default if Bitcoin Core is listening, and a connection to Tor can be made. It can be configured with the -listenonion , -torcontrol and -torpassword settings. Bitcoind can now optionally asynchronously notify clients through a ZMQ-based PUB socket of the arrival of new transactions and blocks. By default, Bitcoin Core will use floating fees.

Based on past transaction data, floating fees approximate the fees required to get into the m th block from now. Sometimes, it is not possible to give good estimates, or an estimate at all. Furthermore, Bitcoin Core will never create transactions paying less than the current minimum relay fee. The wallet will now report a negative number for confirmations that indicates how deep in the block chain the conflict is found.

For example, if a transaction A has 5 confirmations and spends the same input as a wallet transaction B, B will be reported as having -5 confirmations. If another wallet transaction C spends an output from B, it will also be reported as having -5 confirmations.

To detect conflicts with historical transactions in the chain a one-time -rescan may be needed. Unlike earlier versions, unconfirmed but non-conflicting transactions will never get a negative confirmation count. Previously, every wallet transaction stored a Merkle branch to prove its presence in blocks. When loading a 0. This can reduce the disk usage from currently around 60 GB to around 2 GB.

However, rescans as well as the RPCs importwallet , importaddress , importprivkey are disabled. A value of 0 disables pruning. The minimal value above 0 is Your wallet is as secure with high values as it is with low ones. Higher values merely ensure that your node will not shut down upon blockchain reorganizations of more than 2 days - which are unlikely to happen in practice.

In future releases, a higher value may also help the network as a whole: For further information about pruning, you may also consult the release notes of v0.

BIP defines a service bit to allow peers to advertise that they support bloom filters such as used by SPV clients explicitly. It also bumps the protocol version to allow peers to identify old nodes which allow bloom filtering of the connection despite lacking the new service bit. For the next major version it is planned that this restriction will be removed.

Command line options are now parsed strictly in the order in which they are specified. For more information about the implementation, see https: This release seeks to consensus enforce the rule. Bitcoin transactions currently may specify a locktime indicating when they may be added to a valid block. Current consensus rules require that blocks have a block header time greater than the locktime specified in any transaction in that block. Miners get to choose what time they use for their header time, with the consensus rule being that no node will accept a block whose time is more than two hours in the future.

The consensus rules also specify that valid blocks may have a header time greater than that of the median of the 11 previous blocks. This GetMedianTimePast time has a key feature we generally associate with time: Mempool inclusion rules currently require transactions to be valid for immediate inclusion in a block in order to be accepted into the mempool. This release begins applying the BIP rule to received transactions, so transaction whose time is greater than the GetMedianTimePast will no longer be accepted into the mempool.

Any transactions which are valid under the current rules but not yet valid under the BIP rules will either be mined by other miners or delayed until they are valid under BIP Note, however, that time-based locktime transactions are more or less unseen on the network currently. GetMedianTimePast always trails behind the current time, so a transaction locktime set to the present time will be rejected by nodes running this release until the median time moves forward.

To compensate, subtract one hour 3, seconds from your locktimes to allow those transactions to be included in mempools at approximately the expected time. The p2p alert system is off by default.