# pycoin for Bitcoin Keys, Transactions, and Alt-Coin Utilities

> pycoin is a Python library for Bitcoin and selected alt-coin key, address, transaction, BIP32, and ECDSA operations. Its network-scoped API is documented mainly for Bitcoin, while alt-coin support varies by network.

**richardkiss/pycoin** — Python-based Bitcoin and alt-coin utility library.

- Repository: https://github.com/richardkiss/pycoin
- Stars: 1,441 · Forks: 489
- Language: Python
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/richardkiss-pycoin

## Why pycoin exists and where its scope begins

pycoin addresses a specific problem in Python Bitcoin development: the need to manipulate cryptographic keys, addresses, transactions, and related data without treating every operation as an unrelated low-level task. It is intended for engineers building utilities or applications around Bitcoin and some bitcoin-like alt-coins. The project does not present itself as a complete wallet, node implementation, or bitcoin protocol client. Its emphasis is utility code, with network-specific behavior handled through a network object.

The central design decision is to scope operations to a network. Bitcoin mainnet addresses begin with `1`, while Bitcoin testnet addresses begin with `m` or `n`, and other networks can define different parameters. pycoin exposes network access either through a coin-specific module or through a network-code registry:

```python
from pycoin.symbols.btc import network
```

The alternative form selects a network by its code:

```python
from pycoin.networks.registry import network_for_netcode
network = network_for_netcode("BTC")
```

Bitcoin has the most complete documented feature set. The README lists keys, transactions, signed transaction validation, unsigned transaction signing, and partial multisig signing. It also says that other coins are supported to varying degrees, so the existence of a network object should not be read as evidence that every Bitcoin operation is available for every alt-coin.

## How network-scoped keys and addresses are represented

The key API is reached through `network.keys`, while parsing operations are reached through `network.parse`. A private key can be created from a secret exponent and then queried for several encodings and forms. The API exposes WIF, SEC, and address representations, with compression selectable when an address is requested:

```python
from pycoin.symbols.btc import network

key = network.keys.private(secret_exponent=1)
print(key.wif())
print(key.sec())
print(key.address())
print(key.address(is_compressed=False))
```

The README deliberately uses `secret_exponent=1` only as a demonstration value and explicitly warns that it is easy to guess. In a real application, a key must come from an appropriate source with suitable security controls. The library's API does not turn an example secret exponent into a safe wallet key.

A generated key can be parsed again from its WIF representation. This illustrates the distinction between a key object and its serialized forms: `network.parse.private(key.wif())` reconstructs an object that can report its address. The network object also supplies the parameters needed for address formatting, which prevents the caller from scattering network-specific prefix assumptions throughout the application.

## BIP32 derivation and the public-key disclosure boundary

pycoin includes BIP32 key creation and parsing. A seed can produce a hierarchical extended key, from which the library derives WIF, SEC, and address information:

```python
key = network.keys.bip32_seed(b"foo")
print(key.hwif(as_private=1))
print(key.hwif())
print(key.wif())
print(key.sec())
print(key.address())
```

The README also shows parsing an extended private key from its textual `xprv` representation. BIP32 support is useful for applications that organize keys as a hierarchy, but it does not remove the need to control seed generation and storage. The example seed `b"foo"` is explicitly described as terrible for real use because it is easy to guess.

A serious limitation is documented in the BIP32 warning. Public wallet keys can reveal information about their derivation path. If an attacker has a private descendant key and the corresponding public parent key, the public key can allow working back up the tree to determine the private key corresponding to that parent, unless private derivation occurred somewhere along the path. Consequently, publishing a public wallet key is not always equivalent to publishing a harmless public address. Applications using extended keys should decide which derivation information is acceptable to disclose and should review `BIP32.txt` before treating a public extended key as a routine identifier.

This warning is specific to hierarchical key handling and does not apply in the same form to every ordinary address.

## Transaction tooling, source data, and service dependencies

The repository provides a `tx` command described as a transaction utility, while the Python API includes transaction signing and validation functionality for Bitcoin. Signing or verifying a transaction generally requires source transactions, so pycoin can use configured web services to fetch underlying information. The README describes `PYCOIN_CACHE_DIR`, `PYCOIN_BTC_PROVIDERS`, and `PYCOIN_XTN_PROVIDERS`. Results are cached in the configured cache directory, and listed sites are polled in order.

```bash
PYCOIN_CACHE_DIR=~/.pycoin_cache
PYCOIN_BTC_PROVIDERS="blockchain.info blockexplorer.com chain.so"
export PYCOIN_CACHE_DIR PYCOIN_BTC_PROVIDERS
PYCOIN_XTN_PROVIDERS="blockchain.info"
export PYCOIN_XTN_PROVIDERS
```

The documented variables affect data retrieval, not key creation. `pycoin.services` includes `spendables_for_address` and `get_tx_db`, which use the environment settings to select web sites. The old `PYCOIN_SERVICE_PROVIDERS` syntax is deprecated. This creates an operational dependency: transaction workflows that need source data can depend on configured providers, network access, cache state, and provider responses.

The `block` command can dump a block in a human-readable format, and the `pycoin.block` module contains `Block`, which parses and streams the binary block format. These are separate from the `tx` workflow. The repository therefore covers both transaction-oriented manipulation and block parsing, but the documentation does not claim that pycoin is a full blockchain node or protocol service.

## Installation paths, native acceleration, and the first use

The repository does not provide a conventional README installation tutorial or a confirmed `pip install pycoin` command. Its `pyproject.toml` identifies the package as `pycoin`, uses `setuptools.build_meta`, declares Python `>=3.10`, and defines console entry points named `block`, `ku`, `tx`, `msg`, `keychain`, `b58`, and `coinc`. A first real use can therefore begin with the documented Python API, but installation should be verified against the project packaging files rather than inferred from an undocumented command.

A minimal key example is:

```python
from pycoin.symbols.btc import network

key = network.keys.private(secret_exponent=1)
print(key.wif())
print(key.sec())
print(key.address())
```

The README says pycoin has been tested with Python 2.7 and 3.7 through 3.13, while `pyproject.toml` requires Python 3.10 or later. That difference is worth checking before adoption. The current package metadata also classifies the project as `Development Status :: 3 - Alpha`, so users should distinguish the available API from a guarantee of production readiness.

ECDSA operations are in `pycoin.ecdsa`. The native module looks for OpenSSL and libsecp256k1 and can use them when present. `PYCOIN_LIBCRYPTO_PATH` and `PYCOIN_LIBSECP256K1_PATH` provide path hints. Selection can be controlled with `PYCOIN_NATIVE`:

```bash
PYCOIN_NATIVE=openssl
export PYCOIN_NATIVE
```

The documented values are `openssl`, `secp256k1`, and `none`. The README does not state performance measurements for these paths.

## Maintenance, licensing, and the right alternative boundary

The repository is not archived, and its last push was on 2026-06-18. The repository has no GitHub releases, so there is no release history to use as an upgrade signal. The `CHANGES` and `COMMAND-LINE-TOOLS.md` files are present, but their contents are not available here. pycoin is licensed under MIT. That makes the licensing straightforward to review at the repository level, although an application still needs to check how the library is distributed and whether its dependencies impose separate terms.

The closest documented alternative is pycoinnet, which the README identifies as a library that speaks the bitcoin protocol. The distinction is architectural. pycoin provides Bitcoin-related utilities such as keys, addresses, transactions, validation, signing, and blocks. pycoinnet is directed at protocol communication. A project that needs to create or manipulate Bitcoin data may fit pycoin, while a project whose main requirement is speaking the Bitcoin network may need pycoinnet or a different network-layer tool. The documentation does not claim that either library replaces a wallet service, node policy engine, or production key-management system.

Other practical limits follow from the API design. Network support varies, transaction signing can require source transactions, and web-service configuration can affect workflows that fetch data. The package metadata requires Python 3.10 or later even though the README lists older tested versions. These are concrete boundaries for adoption, not reasons to assume the library is unusable.

## Conclusion

Adopt pycoin for Python programs that need direct access to Bitcoin-style key and transaction primitives, especially when explicit network configuration is acceptable. Do not assume every alt-coin or transaction feature is equally supported, and verify the target network's capabilities, signing requirements, and service dependencies before depending on it. The repository's last push was on 2026-06-18, and its MIT license permits use under that license's terms.

## FAQ

### How do I install pycoin?

The README does not provide a conventional installation command. The repository includes `pyproject.toml`, which names the package `pycoin` and defines setuptools entry points, so installation should be based on the project's packaging metadata.

### How do I create and parse a Bitcoin private key with pycoin?

Use `network.keys.private(secret_exponent=...)` to create a key, then use `network.parse.private(key.wif())` to parse its WIF form. The README's `secret_exponent=1` is only an example and is not suitable for real use.

### Does pycoin support alt-coins in the same way as Bitcoin?

No uniform support is documented. The README says Bitcoin has the highest level of support, including keys, transactions, signed transaction validation, and signing, while other coins are supported to varying degrees through network objects.

### What environment variables configure pycoin transaction services?

The README documents `PYCOIN_CACHE_DIR`, `PYCOIN_BTC_PROVIDERS`, and `PYCOIN_XTN_PROVIDERS`. It also says that `PYCOIN_SERVICE_PROVIDERS` is deprecated and that listed providers are polled in order.

## Sources

- [Issues](https://github.com/richardkiss/pycoin/issues)
- [License: MIT](https://github.com/richardkiss/pycoin/blob/main/LICENSE)
- [README](https://github.com/richardkiss/pycoin/blob/main/README.md)
- [richardkiss/pycoin on GitHub](https://github.com/richardkiss/pycoin)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/richardkiss-pycoin
