New answers tagged

1

As pointed out by Peter in the comments of your question, you will need to wait until your node has synced with the longest chain. At the time of your comment, you are 169,245 blocks behind which, unless your transaction took place ~3 years ago, will not be known to your node yet. As soon as the block containing your transaction is verified by your node, you ...


0

As @MartinSolie noted, it might be helpful to look into the debug.log file. Based on what you describe, it sounds like your Bitcoin Core node crashes at some point while synchronizing. You mentioned that you copied the chain from another device. Since you mentioned you are waiting for the blocks to match the headers, I'm not sure the transferred chain is ...


1

This is a common issue for any service with BTC incomings/outgoings. The answer is simply to consolidate all your inputs in a large transaction all at once, so you remove possibly hundreds of small outputs, and get one big at the end. Usually people do this semi-regularly, though you also see people waiting until mempool fees are super low. One reason ...


3

No, it would not. --reindex only handles the data that is stored on disk. Blocks are stored in the order that they are received, which is what brought you to your current view of the blockchain. So all that would happen is that you end up at that same state. Switching to another blockchain fork requires your node to be aware of it, so you need to have ...


0

Running a mainnet full node uses up closer to 300 GB as of the time of this answer, not 160 GB. Once your node is synced, any transactions you make will be part of the bitcoin mainnet, and thus persistent. However, you are still responsible for backing up and maintaining access to your private keys - if you delete or otherwise reset the wallet, you will ...


2

It refers to actual disk space. RAM is memory, not storage. The term "disk space" is very specific. Then a while later this: [2020-01-20T09:05:59Z Reindexing finished] But bitcoind continued grinding on... Well then what is all this? :: Your node was not fully synced, so after it finished reindexing the blocks on disk, it continued to download ...


1

You can see all available command options by running the command bitcoind -?. Similarly, in the GUI you can check out "HELP" -> "Command Line Options" in the task bar. This will return a list of all available commands, as well as their default values (when applicable). Note that this just returns all possible command options, not specifics about what you ...


2

The getblockchaininfo RPC will tell you have many blocks and headers you have. When the number of headers is larger, you're still synchronizing.


0

Alternatively, you can use printtoconsole to redirect the debug output to the console instead of the debug.log file.


0

bitcoin-cli is generating a P2WPKH address (bc1...), but then on the user side you are generating a P2PKH address (1....). You may also need to check to ensure the same address derivation path is being used (Bitcoin-core uses hardened derivation). For more info on address encodings see: What is P2PK, P2PKH, P2SH, P2WPKH - ELI5 What is the size of ...


0

Generation of blocks uses the proof of work algorithm that includes a nonce that ensures randomness, if we could somehow recreate all these things the whole system of cryptocurrency would break down. The short answer is no.


2

In a sense, such a command would be trusting a third party: any putative answer would be that given by whoever supplied that code to you; and it may not be trustworthy - it could tell you it was 21 million, but behind the scenes actually use, say, 42 million. The nearest you could do would be to download the source code from a proper source and, having ...


Top 50 recent answers are included