Using the getblockchaininfo RPC command :
if initialblockdownload is true, your node is currently syncing with the network for the first time.
if the headers field number is superior to the blocks field number, your node is catching up with the current state (likely after having been restarted)
else if the headers field number is equal to the blocks ...
The only place clear is used on the mempool is after all peers are down. Presumably there are references to it that you can't just leave dangling.
See CTxMemPool::Expire in txmempool.cpp for how expiration works. It wouldn't be hard to modify that existing function to just remove everything at a particular point.
I assume you're the author of http://people....
Your client will make use of transactions it relays to build an estimation : by caching it (and the block height) when it first sees it it will we able to tell how much time (# of blocks) it took for it to be confirmed.
To build a reliable estimation, it will fill "buckets" (basically, a pack of transactions sharing a common characteristic) according to the ...
If you want your wallet database (file) to be in a different directory than your data directory, you can use the -wallet=<path> startup option to specify a custom path to your wallet.
Quoting the manpage:
-wallet=< path >
Specify wallet database path. Can be specified multiple times to
load multiple wallets. Path is interpreted relative to <...
Electrum servers are simply not compatible with Bitcoin Core on a development or operational level. They require a vast amount of indexes created which the node does not have, and must be created by an external tool. With the state of the art electrs Electrum server, it needs upwards of a day of time to create these indexes, and more than 50GB of additional ...
You cannot say for sure.
The three options are potentially true.
However, many clients build transactions with the change output as the last output.
So, following this convention, I would say option 2 is the most likely.
The problem is that you have 0 connections. Your node isn't connecting to other nodes on the network. It is able to connect to the DNS seeders and get node IPs to connect to, but something is preventing it from making the actual connection itself.
Make sure there isn't something preventing your node from making outbound connections to port 8333. This could ...
As a third party to the transaction, its hard to say what the most likely case is. You can guess, but there are a number of possibilities, and some wallet software will deliberately create transactions which confuse this sort of analysis.
To add to your list of possibilities:
Someone sent 25.99 bitcoin to another person/organization
Someone sent 1 bitcoin ...
2 confirmations means the transaction was included in a valid block and that block was continued by another valid block.
Option 3, although it should be next block (older than the one that contains the transaction) instead of previous block.
I think the preferred technique to use 'bitcoin core as a wallet backend' is through block filters, like the new compact block filters (an improvement over bloom filters). The protocol is known as Neutrino and lowers the CPU and storage requirements for your bitcoin core node (an electrumx database takes around 50 GB right now). To create these filters in ...
Identity leaks usually happen in two places.
Off Chain Leaks
Here, the address is somehow linked to you off chain - this could be because you shared it from an account or network that can be traced to you (it's largely impossible to avoid being tagged online if a well funded and skilled group, such as nation states, is targeting you).
Alternatively, if you ...
I have found this article https://bitcointechtalk.com/an-introduction-to-bitcoin-core-fee-estimation-27920880ad0 which give you a pretty good summary of this bitcoin function.
Notice that estimatesmartfee return is based on the data of what happened in the past in the blockchain, it is not trying to predict what will happen in the future but what should ...
Setting the nLockTime field of a transaction restricts confirmation of the current transaction until a certain block height.
Using a CLTV op in the locking script of an output of the current transaction will restrict the confirmation of the next transaction (i.e. the one that spends this output), by forcing the next transaction's nLockTime to be equal to the ...
Removal of internal miner
As CPU mining has been useless for a long time, the internal miner has been removed in this release, and replaced with a simpler implementation for the test framework.
The overall result of this is that setgenerate RPC call has been removed, as well as the -gen and -genproclimit command-line options.
For testing, the generate call ...