9

The introduction of descriptor wallets presents an opportunity to introduce a new database backend as descriptor wallets are backwards incompatible. The following is taken from Andrew Chow's blog post on what's coming to the Bitcoin Core wallet in 0.21. (There was also discussion on this GitHub Issue.) Why move from Berkeley DB? Not designed to be used as ...


6

You can use a self-hosted (but low-burden!) instance of Esplora. Blockstream is also exposing an instance for free (at the moment) at blockstream.info. Disclaimer: if you take part of Bitcoin as an economic actor (as an application providing account balances may imply), you should really consider using your own source of truth and self-host the instance. It'...


3

Historically bdb was used for the UTXO as well, so you could justify using it for the wallet as well for consistency. It makes absolutely no sense today, other than that it will always need to be supported to some extent for compatibility. Really the wallet could be replaced with any key value store at all and it would function completely fine. You would ...


2

The Bitcoin Core documentation describes dbcache as the cache for the UTXO database. Wikipedia describes a cache as a: software component that stores data so that future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation or a copy of data stored elsewhere. Greg Maxwell added on IRC: There ...


2

This is normal, especially on testnet. What you are seeing are known as stale blocks (or also incorrectly as orphan blocks). These occur when miners complete a block at around the same time so some nodes receive the two blocks in a different order. The conflict resolves when the next block is found. You will commonly see stale blocks on testnet due to ...


2

The only data exchanged over the Bitcoin peer-to-peer network are the raw blocks and transactions. Everything else has to be generated locally from that data. Litecoin and other forks work the same, as far as I know. Of course, there could be some client implementations that get other data from other sources (not via the main peer-to-peer network), such ...


1

Why this is hard Bitcoin Core is chiefly a tool to synchronize with the current state of the network and to enforce the consensus rules with a self-owned piece of hardware. Beside being on the same page regarding the rules, this requires the node only to keep track of the ledger, the Unspent Transaction Output (UTXO) set. Bitcoin transactions need to be ...


1

Blockchain: Chain of blocks +++++----------++++---------++++++---------+++++++ Who creates the blocks? Miners Who validates, saves and relay these blocks? Full nodes https://bitcoin.stackexchange.com/a/103172/ Different full node implementations for Bitcoin: Core, btcd, bcoin, gocoin, libbitcoin, knots, etc. Database used by Bitcoin Core: Bitcoin Core ...


1

I can't imagine any other reason as to why BDB wasn't dumped altogether if it wasn't for backwards support. There simply is none. The wallet file doesn't need to be a database, it could be a flat text file and that would operate just as well. BDB will remain for compatibility for the foreseeable future, and change is risky, so it remains.


1

Backwards compatibility is a massive priority for Core and it is generally very conservative in its technology choices. I don't think it would consider a new (database) technology until it had been proven over many years on other projects. It is providing a consensus engine and infrastructure and doesn't have the same tolerance as startups or bigger ...


1

Otherwise, it is advised to use the REST HTTP API with parallel queries, am I right? No. That would just add an extra layer of complexity and delay. Either the net result would be that some piece of code winds up trying to do more than one read at a time or it doesn't. If it does result in some piece of code trying to do more than one read at a time, you'...


Only top voted, non community-wiki answers of a minimum length are eligible