Changing the txindex setting no longer requires a reindex since version 0.17.0 (see https://bitcoincore.org/en/releases/0.17.0/, under "Transaction index changes). It'll update just the txindex itself whenever it's out of sync automatically.
It doesn't inject a reindex (which would cause throwing away the entire chainstate database, and rebuilding ...
There's no particular issues with running both the daemon and the QT using the same data directory, you're also protected against running them both at once due to locking. Most versions, especially within a single major release, are compatible so there's no burning concern about keeping them exactly in sync with one another.
ie: notably one where I don't specify things like rpcuser, rpcpassword - is this insecure?
No, Bitcoin Core by default creates a RPC cookie file in the data directory on startup which is used in place of static authentication. Specifying a rpcuser and rpcpassword is deprecated, and they can't be blank regardless.
I was studying, no one can track a person on the bitcoin network. Is that true?
Users can be tracked IF they don't follow the best practices. Although lot of on-chain analysis and investigation works on assumptions.
Every transaction on-chain has lot of information associated with it including address, amount, type of transaction etc.
Not every user ...
Yes, this is true. Because one person can generate new public and private key for each transaction. Bitcoin coin Blockchain provides anonymity.
However, it's just possible if we are working proactively. Means Don't share confidential information regarding transactions or accounts with people. Moreover, as I already said, generate new addresses for each ...
No, according to the bitcoin network, the system generates a different digital signature for each transaction. Because the sender generates a digital signature from a transaction message and his private key. That's why you can create a new public key and private key for each transaction.
Your bitcoin client is generating a P2WPKH (bech32 encoded) address, which is a newer address format which has some benefits compared to legacy formats. The address is valid, but for whatever reason, the exchange mentioned has not upgraded it's code to recognize and send to this address type yet.
The fix is easy: you just need to tell bitcoin-core to ...
By default, yes and no.
No, most of the code is compiled for generic target hardware. If you want something optimized for your actual hardware, you can add -march=native to your compilation flags (e.g. you'd run ./configure CFLAGS="-march=native" CXXFLAGS="-march=native"). This will result in a binary that may not work on other hardware ...
The auth cookie lives in the data_dir for bitcoind.
lnd finds the data_dir by first finding the bitcoin.conf file, which it finds based on the bitcoind.dir argument passed at runtime. It then parses that for the data_dir directive.
You can see this in the src code:
So, if you are using a non-...
It was discussed at an anonymized Sydney Socratic Seminar in July. I'm assuming MacOS will continue to be supported but it is becoming harder "to build and distribute binaries in the completely reproducible, trustless manner" that Bitcoin Core would like to.
Apple is introducing these notarization requirements where we would
have to build our ...
Of course. QT, the GUI framework Bitcoin Core uses, is one of the most portable GUI frameworks. Sooner or later, Apple Silicon support will be added. Meanwhile you can track the progress here: https://bugreports.qt.io/browse/QTBUG-85279
Then Core developers will do the rest: https://github.com/bitcoin/bitcoin/issues/20371
While my answer doesn't cover the "auto" part of your question, to load multiple wallets on Bitcoin Core restart, add this to bitcoin.conf before restarting:
Full path isn't required if you created the wallets in the default directory (aka datadir).
The wallet= line is necessary to load the default wallet.
For transactions? https://en.bitcoin.it/wiki/Protocol_documentation#tx
This is the internal format, for communication between Bitcoin nodes. As such this won't be as useful as the JSON format, since you will need to parse it on your own.
This is also equivalent to calling the RPC decoderawtransaction with tx received in the hex format.
You can't. The cookie file is for bitcoind to write it's automatically generated credentials to for other software to read. If you want to set the RPC credentials, you need to do so within the bitcoin.conf file using the rpcauth option (or rpcuser and rpcpassword but these are deprecated). These could also be specified on the command line.
2MtLR5mKgWRZBYtCYiSuaKpTUSuney9Cg2V is your new address which is derived from scriptHash 0x0bf37781383277cbb4e544c402f5265a51f4d8289. Go all the way back to step 2 and send 0.005 & 0.004 to 2MtLR5mKgWRZBYtCYiSuaKpTUSuney9Cg2V. scriptPubKey of those transactions will be both OP_HASH160 0bf37781383277cbb4e544c402f5265a51f4d828 OP_EQUAL.
Retrieve those ...
As long as the underlying OS image is susceptible to changes, you will not get a reproducible build system that guarantees reproducibility over a long period of time. If the OS can update compiler toolchains, libc versions and whatever tools are used during a gitian build, changes in the future to the output are expected. Since this is the case since gitian ...
Your redeem script hash should be:
Which results this address:
I've done a rebuild of 0.20.1 and I get the same results that you do. This would indicate that a build dependency has updated to produce slightly different results than the version that was in use at the time of the release. The build dependency versions are pinned unlike the actual software dependencies. IIRC this is common for gitian builds and attempting ...
You are in blocks only mode as you have blocksonly=1 set in your bitcoin.conf. This means that your node will not receive or relay unconfirmed transactions. You only see blocks and the transactions that come in blocks. Thus the first time your node will see an incoming transaction is when it is first included in a block.
I highly recommend bcoin:
It is a nodejs library that can also run a fully validating node, SPV node, and BIP44 wallet. It's used in production by many long-standing bitcoin companies such as Purse.io
You can even use the bcoin client to make RPC calls to bitcoin core, and of course you do not need to run ...
As result, you have the most popular library that exists at the moment!
I used bitcoind-rpc by bitpay and worked well for me, but can exist some other library that works for you just search on github/gitlab and another repository.
The challenge with creating reproducible builds is that you need to ensure that the build process matches exactly across different operating systems and different architectures. Bitcoin uses Gitian, a deterministic build process to achieve that.
Bitcoin Core provides the configuration and build instructions for various operating systems in the /contrib/...
The keypool is ordered, not just a set of keys being watched. This allows for addresses to be given out in derivation order, as well as maintaining the gap limit. When an address is used, all keys that come before it will also be marked as used. This is done to ensure that already used addresses are not accidentally reused.
So when you give out and use a ...
Not sure but I think it's marking keys as used and doing the topup as described in this PR: https://github.com/bitcoin/bitcoin/pull/11022
Logs about "keypool index %d removed" : https://github.com/bitcoin/bitcoin/pull/11044 which I see now in src/wallet/scriptpubkeyman.cpp https://github.com/bitcoin/bitcoin/blob/...
This is implementation dependent, but in Bitcoin Core there is not just a single UTXO set:
The UTXO set on disk in the chainstate/ directory in a database. It corresponds to the state as of the last flushed block (and does not include the effects of any mempool transaction, or of any block since the last flush).
The in-memory coins cache is a cache on top ...
Yes you need to provide the UTXO details when building a transaction in bitcoinjs. One should not have to trust a library to provide blockchain data, the library works like a calculator and processes the data that it is given. It's not unreasonable at all, these details are easy to get from your node or an explorer.
Is it possible to perform createrawtranscation , signrawtransaction and sendrawtransaction rpc call using bitcoin in prune mode?
I did the transactions in below link using pruned node:
rescanblockchain might be required if you are using any imported addresses in the transactions and it will work only for ...