BitcoinLib: wallets, keys, scripts and transactions in Python

The whole stack in one library

BitcoinLib gives Python developers a wide range of tools for working with Bitcoin, and the list of what it covers is long enough to show that this is more than a wrapper around a few API calls.

You can create and manage wallets. You can use different key structures, including hierarchical deterministic wallets following the BIP32 standard. You can interact with the blockchain, retrieving and decoding its data. You can build, sign, and verify transactions and signatures, and the library is explicit that this is not limited to the standard case: a segwit transaction is one shape, and multisig, nulldata, and custom made transactions are others. You can create, analyse, and run Bitcoin scripts. You can generate addresses and represent them in the different formats, P2PKH, P2SH, Bech32 among them. You can create private keys and work with mnemonic password phrases.

The back end is equally broad. External service providers can be used to fetch address, transaction, unspent output, and blockchain data, and you can connect to a local Bitcoin Core, Bcoin, Blockbook, or ElectrumX node, with a separate setup page for each in the documentation.

The last two entries are the ones that decide whether this fits your project. The library can be extended to other cryptocurrencies by configuring custom parameters, and Litecoin, Dogecoin, and various test networks are supported out of the box. That means a dogecoin wallet is a configuration change rather than a fork, and the same is true for a chain the project has never heard of if you are willing to describe its parameters.

The project is AGPL-3.0 licensed, which is the detail to note for any project that intends to use it in a service. The documentation is published on Read the Docs, the package is on the Python package index, and the last push to the repository was on 2026-10-18.

The library is used by the Blocksmurfer Explorer and by other projects, and the repository links a list of the projects that depend on it.

The wallet example, from an empty key to a sent transaction

The example in the project documentation is short, and it walks through the three operations that a wallet application actually needs.

The wallet implementation is backed by SQLite3 or SQLAlchemy, and it imports, creates, and manages keys in a hierarchical deterministic way. Creating a wallet and asking it for the next key looks like this.

>>> from bitcoinlib.wallets import Wallet
>>> w = Wallet.create('Wallet1')
>>> w.get_key().address
'bc1qk25wwkvz3am9smmm3372xct5s7cwf0hmnq8szj'

The address that comes back is a bech32 one, which is the address format the library is configured to produce by default for the network in use.

The next step is scanning. When someone sends a small amount to that address, the wallet needs to know about it, and the scan method is what updates the transaction list and the unspent outputs.

>>> w.scan()
>>> w.info()  # Shows wallet information, keys, transactions and UTXO's

The third step is spending. The send method takes a destination address and an amount, and it has an offline flag, which is the switch that decides whether the transaction is built and signed locally or handed to a service provider.

>>> t = w.send_to('bc1qemtr8ywkzg483g8m34ukz2l4pl3730776vzq54', '0.001 BTC', offline=False)
>>> t.info  # Shows transaction information and send results

The return value is a transaction identifier, and the info attribute on it holds the details of what was sent.

Three things are worth noticing across those calls. The wallet is created by name and persists in the database, so the second run of a script finds the same keys. The scan is separate from the send, which is what makes an offline workflow possible: you can build and sign a transaction on a machine with no network, and the offline flag is how the same code path is used in both cases. And the amount is given as a string with the unit, so the conversion and the rounding are the library's problem rather than the caller's.

The proposals the library implements

The list of Bitcoin Improvement Proposals is the clearest statement of the scope, and it is worth reading as a compatibility list rather than as a list of features.

Hierarchical deterministic wallets, BIP32, are the foundation, and with them come the purpose field for deterministic wallets, BIP43, and the multi-account hierarchy for deterministic wallets, BIP44. Those three together are what make a seed phrase produce a tree of addresses in a predictable way, and a library that implements them is implementing the same derivation every other wallet does.

The passphrase-protected private key format, BIP38, is there for encrypting a single key rather than a whole wallet, and the mnemonic code for generating deterministic keys, BIP39, is the word list that turns a seed into something a person can write down.

The multisig side is BIP45, the structure for deterministic P2SH multisignature wallets, and the transaction formats are the segwit pair, BIP141 and BIP143 for native and P2SH nested transactions. The address formats are BIP173, bech32 with base32 for the native witness outputs of version 0 to 16, and BIP350, bech32m for the version 1 and later witness addresses.

The bech32m entry is the one to check first if you are working with anything recent, because the two address formats are not interchangeable and a wallet that produces the wrong one for a given output type is a wallet that sends to an address some nodes will reject. The library's own list ends there and says the rest is covered by the catch-all of many more.

What is not in that list is as informative as what is. Taproot and Schnorr signatures appear in the roadmap rather than in the implemented proposals, and so do timelocks and advanced scripts. A project that needs Taproot output is looking at a different library.

Nodes, service providers, and where the data comes from

A Bitcoin library has to answer one question before anything else, which is where the chain data comes from, and the library offers three kinds of answer.

The first is a node you run yourself. The documentation has a separate setup page for each of the four: Bitcoin Core, Bcoin, Blockbook, and ElectrumX. The names matter because they are different things, with a full node validating the chain, Blockbook and ElectrumX being index servers, and Bcoin an alternative implementation. The project treats them as interchangeable sources rather than insisting on one, and each setup page covers the connection for that specific service.

The second is an external service provider, used to fetch address, transaction, unspent output, and blockchain data. The library keeps the provider interface abstract, and the examples directory includes scripts for the service providers themselves, for measuring their execution times, and for the services module in general.

The third is parsing data you already have, and there is an example for that, one for the standard format and one for the Bcoin format, which shows that the parser is written against a specific structure rather than a generic one.

The examples directory is a good map of the library's real surface, because the file names are the feature names. There is a script for encrypted private keys, for the bitcoind client, for a regtest network, for blockchain parsing, for blocks, for the database and for an encrypted database, for encoding, for keys, for message signing, for mnemonics, for networks, for scripts, for transactions, for decomposing a transaction, for values, for connecting a wallet to a bitcoind node, for a three of five multisig wallet, for wallets, for bumping a fee, and for deleting unconfirmed transactions.

Two of those are worth singling out. The fee bumping example and the delete unconfirmed transactions example are the two operations every wallet application needs and most tutorials never show, because a library that cannot raise a fee on a stuck transaction is a library you will write the missing part of yourself.

Storage, cryptography, and the packaging

The dependency list tells you what the library is built on, and it is a small set with a few heavyweight members.

The cryptography is three libraries. There is a pure Python elliptic curve implementation for the signature work, a fast compiled one for the same, and a cryptographic library for the symmetric side. The compiled library is why the install instructions begin with a system package step.

$ sudo apt install build-essential python3-dev libgmp3-dev

Those are the compiler toolchain, the Python headers, and the development files for the multiple precision arithmetic library that the curve code sits on. Without them the install of the compiled cryptography module fails, which is the reason the documentation has a separate page for installation on other systems and for troubleshooting.

The data side is SQLAlchemy, with the database drivers for PostgreSQL and for MySQL, and the project states in the documentation that the wallet implementation uses SQLite3 or SQLAlchemy, so a plain file works for a single user and a server database works for a service.

The rest of the list is packaging and reporting. Sphinx and its theme build the documentation, a coverage service is wired in, and there is a console encoding fix for Windows. The build system is setuptools with a recent floor, and the coverage configuration in the project file turns on branch coverage with relative file paths and debug output, which is the setting you want when the coverage report is collected from more than one machine.

The repository layout is a normal library layout with the package directory, the tests, the examples, the documentation, and a docker directory holding Dockerfiles for building images, which the install notes point at as the route to take if you are containerising.

The roadmap, the licence, and the warning at the end

The last two sections of the project documentation are the ones that tell you what to expect.

The roadmap lists six items. Full support for timelocks. Support for Taproot and Schnorr signatures. Support for advanced scripts. Support for the Trezor wallet and other hardware wallets. The ability to scan the full blockchain. And an integrated simple SPV client.

Read in order, that is a list of things that make a wallet library complete for a modern setup. The hardware wallet line is the one with the widest consequences, because until it is done, a key that must never touch a general purpose machine has to be handled by the caller rather than by the library. The SPV client line is the one that would make the library work without a server of your own, and the full chain scan is what a long term custodial or analysis use case would need.

The disclaimer is short and it is not boilerplate. The library is still in development, and the project asks you to use it at your own risk and to test it sufficiently before using it in a production environment.

The licence is AGPL-3.0, which for a library that may end up in a service is a decision with consequences, because the copyleft obligations reach the service rather than stopping at the import.

The project is maintained actively, with pushes into October 2026 and a changelog at the root, and the support channel is GitHub Discussions rather than the issue tracker, with the readme pointing questions, problems, and ideas there. The versions are handled through the package index and the source, with no tagged releases in the repository.

For a developer deciding whether to adopt it, the summary is simple. If you need to manage keys, watch addresses, and build transactions in Python, and your chain is one of the ones supported or can be described in configuration, the library covers the ground. If you need Taproot, hardware signing, or a production guarantee, read the roadmap and the disclaimer first.

Editorial conclusion

BitcoinLib fits a Python developer who needs to hold keys, watch addresses, and build transactions without reimplementing the standards, and who wants the wallet and the transaction layer in the same library. It does not fit a production system that has to sign on a device the web cannot reach, because the roadmap lists hardware wallet support as still to come, and it does not fit a developer who needs Taproot. Verify first which key derivation standard you need, because the implemented proposals stop at the nested segwit formats and the bech32m address format, check that the service provider or node you intend to use is one the library documents, and read the disclaimer, because the project itself says the library is still in development and asks you to test it before it touches real funds.

Frequently asked questions

Official sources

1. 1200wd/bitcoinlib on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README