Now, in order to better grasp some of the design choices made by BDK, it’s important to understand the main concept driving the development of this project, and the goal that it’s trying to achieve.
BDK is aiming first of all to be a set of libraries and tools, all meant to be very reusable and adaptable. Developers working on their own wallets or other projects that are trying to integrate Bitcoin can pick the tools they need and piece them together to prototype and quickly ship a working product. This means that the REPL that we’ve just installed is designed to be a very thin layer over the APIs exposed by the various components of the library, not a full, end-user-ready Bitcoin wallet.
This concept leads to a few design choices that are arguably very bad for the “UX” of this wallet, but that allow developers to work more directly with the underlying library. For instance:
~/.bdk-bitcoin. The database will never contain any data that can’t be recreated purely by looking at the blockchain. Keys, descriptors, Electrum endpoints are not stored in there. This explains why you’ll have to specify them every time in the command line. It can be seen more like a cache and can be safely deleted without risking funds.
synccommand that has to be called by the user.
broadcastcommand that does this. Moreover, the command doesn’t accept a normal Bitcoin raw transaction, but instead a PSBT. That’s because internally transactions are always moved as PSBTs, and again, the
broadcastcommand is just a very thin wrapper over the raw library call.
There are probably more of these examples, but hopefully by this point you’ll have more or less understood the gist of it. If you are not a developer, some parts of this will feel weird, inefficient, hard to understand, and that’s absolutely normal. Just try to survive through the pain and you’ll be rewarded!