This page provides a thorough explanation of the staker BTC public key (staker PK) in the Babylon bitcoin staking system for anyone who wants to develop the staking operations by themselves, such as wallets and custodies.

We start by first clarifying some common misconceptions. We will then specify the staker PK format, and then specify the types of signatures it needs to sign, and how the signatures are verified.

1. Common Misconceptions

1.1 “The fund must come from the staker PK itself”

No.

A bitcoin staking transaction consumes some existing UTXO(s) to create a new staking UTXO. This staking UTXO is constructed using BTC taproot script, and only a certain BTC PK defined in this script can unbond and withdraw bitcoins from this staking UTXO. Thus, this BTC PK is called the staker PK. However, the consumed input UTXO(s) can come from anyone and can be of any type. They don’t have to come from the staker PK.

1.2 “The staker PK has to be taproot or native SegWit“

No. The staker PK is a BTC public key. It is not a BTC address and is agnostic to them. Indeed, from a BTC public key, one can derive all the types of BTC addresses.

The said staker PK constraint only exists in Babylon bitcoin staking web application. The core Babylon bitcoin staking system, as well as the on-chain BTC script, only handle public keys and are agnostic to address types.

1.3 “The staker PK can only be controlled by one party“

Not exactly. Currently, the staker PK is a single public key. By default, it corresponds to one secret key, which gives full control of the stake to the party that owns the secret key. However, this PK can also be generated using:

• M-M multisig (through MuSig2 technique), which allows M parties to co-control the PK.

• MPC (multi-party computation), which allows M parties to co-control the PK.

• FROST M-N multisig (M<N), which allows any M out of N parties to co-control the PK.

On the other hand, a major backwards-compatible system upgrade is planned to support the more generic M-N multisig (M < N). The format of “staker PK“ will become a list of N public keys, and the staking script will cover all the N-choose-M possible combinations.

2. The Format of the Staker PK

The staker PK must be in BIP340 format (https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki ) i.e 32bytes. Babylon parses this key using BTCD libraries - https://github.com/btcsuite/btcd/blob/v0.24.2/btcec/schnorr/pubkey.go#L23

The public key is not connected to any BTC address. It can even be generated from scratch without any connection to BTC.

This key must be the same as the key included in all spending paths of the staking and unbonding output.

3. Signature Signing and Verification

3.1 Schorr Signature for BTC Transactions

The staker PK needs to sign multiple BTC transactions, such as

• slashing transaction - the signature is provided in delegator_slashing_sig field

• unbonding slashing transaction - the signature is provided in delegator_unbonding_slashing_sig field

• unbonding transaction - the signature will only be visible on the BTC chain after unbonding transaction is send by the staker

• withdraw transaction (out of the scope of Babylon system and codebase)

All such transactions spend a taproot script. Thus, the signature format of these signatures is Schnorr format described in BIP340, i.e. 64bytes signature.

Signatures are parsed using BTCD libraries.

Signatures are verified using BTCD libraries.

3.2 Various Other Signatures for System Messages

The staker PK also needs to sign messages that are not BTC transactions. An important example of such messages is proof-of-possession (PoP), which requires the staker PK to sign a Babylon address as the message. The PoP struct can be found in Proof Of Possession proto definition. An example usage of PoP is the pop field of the Staker’s staking express-of-interest transaction.

Due to that different wallets implement message signing differently, the Babylon system currently support 3 types of signatures.

3.2.1 BIP340

In this option, the staker PK must sign the SHA256 hash of the message. Signatures must be created using the Schnorr signature algorithm described in BIP340.

3.2.2 ECDSA

In this option, the staker PK must sign the string of hex encoded bytes of the message. The signature must be made using a method compatible with https://developer.bitcoin.org/reference/rpc/signmessage.html bitcoin endpoint. This endpoint signs the data using ECDSA signature.

3.2.3 BIP322

The BIP322 signing works on BTC addresses (not keys). Therefore, to use it to sign messages that are not BTC transactions, Babylon supports it only for the addresses that maps 1 - 1 to the keys i.e

• P2WPKH address

• BIP86 taproot address - https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki

This means that to create such a signature, the owner of the staker PK must:

• either control such address in the BTC wallet, or

• have access to the private/public key pair directly to create such temporary addresses and create signatures.

The signature must be made over the SHA256 hash of the message.

Verification of the all the 3 signatures types above is implemented on Babylon node in pop.go file - https://github.com/babylonlabs-io/babylon/blob/v0.15.0/x/btcstaking/types/pop.go#L144 using mostly btcd node libraries.

4. Conclusion

The staker PK is a very important key in Babylon bitcoin staking system. It is a BTC public key that is agnostic to BTC address types. To participate in Babylon Bitcoin staking system, the owner of this staker PK should at least be able to sign Schnorr signature over BTC taproot UTXOs and generic messages.