I have a script that generates a segwit v1 taproot compliant address and private key. The script currently generates a regtest address but with minor tweaks it spits out a mainnet address. I think the only difference between a regtest and mainnet address is that for regtest you remove the "bc" from the beginning of the string and replace it with "bcrt." Private keys for regtest and mainnet appear to be the same. This is my script:

def gen_segwit_v1():
    privkey, pubkey = generate_bip340_key_pair()
    program = pubkey.get_bytes()
    version = 0x01
    address = program_to_witness(version, program)
    return privkey, pubkey, address

It creates a bitcoin segwit v1 wallet for usage in taproot transactions. The problem is that my script relies on generate_bip340_key_pair() and program_to_witness() which I copied from https://github.com/bitcoinops/taproot-workshop/blob/master/test_framework/address.py.

This is what program_to_witness() looks like:

def program_to_witness(version, program, main=False):
    if (type(program) is str):
        program = hex_str_to_bytes(program)
    assert 0 <= version <= 16
    assert 2 <= len(program) <= 40
    assert version > 0 or len(program) in [20, 32]
    return segwit_addr.encode_segwit_address("bc" if main else "bcrt", version, program)

I want to generate a testnet Private Key and a testnet segwit v1 address. I think the private keys for testnet and mainnet are different. I don't know the technical derivation formula for bitcoin private keys, but for some reason, all of the testnet private keys I've generated start with a "c" and all of the mainnet keys I've generated start with a "K" or "L" . I'm guessing the formula is different for testnet and mainnet private keys.

So in conclusion, is there a simple way to generate a testnet private key and get the testnet taproot compliant segwit v1 address?


2 Answers 2


Private keys are just big numbers. Although there's a nit on x-only keys (you must use keys whose pubkeys have an even y coordinate), it doesn't appear to be a problem here, since you can generate regtest and mainnet addresses. In theory, there's no differentiation between those networks when it comes to private key.

I noticed that program_to_witness only creates addresses that start with bcrt or bc. Testnet's prefix is tb, perhaps this is your issue?

  • I see what you're saying. Yes, I can just remove bcrt or bc from the beginning of the address and replace it with a tb, but is that really a valid testnet address? I mentioned that all of the testnet private keys I've generated start with a "c" and all of the mainnet keys I've generated start with a "K" or "L," so I think the actual private key has to be different. Apr 25, 2023 at 2:58
  • 2
    You can generate testnet, regtest, or mainnet segwit addresses from the same private key. They’ll be all different from each other. It’s not just prefixes.
    – att
    Apr 26, 2023 at 7:28

Private keys follow the same rules for all networks.

Three issues come to mind that you might need to consider:

  • The human-readable part of the bech32 address is also covered by the checksum. Therefore, it’s not possible to simply replace the human-readable part of an address. To use the same key for a different network, one would need to pick the network before deducing the address. I think the data part would be the same, but the address would have a different checksum.—It’s generally not recommended to use the same keys on multiple networks for privacy and security reasons.
  • The human-readable part for testnet addresses is tb, not bcrt as @DavidsonSouza mentioned.
  • While native segwit v0 outputs (P2WPKH, P2WSH) use the “bech32” (BIP173) encoding for their addresses, native segwit v1 outputs (P2TR) use “bech32m” (BIP350). This only changes how the checksum is calculated (and probably is covered if your function is specific to BIP340).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.