BTC Staker multisig support

[canu0205]

Summary

As Babylon will introduce M-of-N multisig for btc staker, btc-staker program needs to support it to send multisig btc delegation to the bitcoin.

Endpoints that need to be added for multisig-specific

• stake
• stake_expand
• spend_stake
• unbond_staking

No needs to support

• create-phase-1-staking-transaction
• create-phase-1-staking-transaction-with-params
• ... other endpoints in cmd/stakercli/transaction/transactions.go
  

  btc-staker/cmd/stakercli/transaction/transactions.go

  Lines 52 to 57 in d042e93

  	createPhase1StakingTransactionCmd,
  	checkPhase1StakingTransactionCmd,
  	checkPhase1StakingTransactionParamsCmd,
  	createPhase1StakingTransactionWithParamsCmd,
  	createPhase1UnbondingTransactionCmd,
  	createPhase1WithdrawalTransactionCmd,

[canu0205]

hey @KonradStaniec @RafilxTenfen , if you have any comments on the modification, left it here! I would really appreciate it since I'm not familiar with this program.

[RafilxTenfen]

hey @KonradStaniec @RafilxTenfen , if you have any comments on the modification, left it here! I would really appreciate it since I'm not familiar with this program.

You are correct, the only ones which will need BTC multisig support are StakeFunds, StakeExpand, UnbondStaking

I have a question around the plan to connect multiple BTC wallets, do you plan on having multiple instances of btc-staker ?

[canu0205]

I have a question around the plan to connect multiple BTC wallets, do you plan on having multiple instances of btc-staker ?

Yeah, @RafilxTenfen that's a good question. Still I'm trying to figure out the way to connect multiple BTC wallets. Do you have any good idea?

[canu0205]

Here are options for handling multiple BTC private keys:

1. Single wallet holding all staker keys

• Pros: Easiest integration with stakerd today. We only configure one wallet in stakerd.conf, unlock once via walletpassphrase, and every imported key is available for signing/multisig flows. No code changes to walletcontroller, and stakercli UX stays close to the current single‑sig flow. Backups/ops are simpler because all keys live in one wallet. This can be done with bitcoin-cli importpriv.
• Cons: Operationally heavier—operators must import every multisig cosigner key into the same wallet, which might not align with their key‑management policies (no physical separation). Key reuse/privacy is on them to manage. If they want different wallets per cosigner, this setup forces them to consolidate.

2. Multiple wallets (one per staker key)

• Pros: Matches the multisig tutorial model (separate descriptor wallets per participant), allows operators to keep cosigner keys isolated, and mirrors setups where different devices hold different keys.
• Cons: stakerd would need a major refactor: walletcontroller currently holds a single RPC connection/passphrase, so supporting N wallets means managing multiple RPC clients, configs, unlock cycles, and signing flows. stakerd.conf would need new syntax for per-wallet creds, and every signing path would have to select the correct wallet before calling Sign…. This significantly increases complexity and testing surface.

@RafilxTenfen Besides the options above, since I’m not very familiar with the btc-staker codebase or Bitcoin wallet management — and because the btc-staker setup isn’t working properly on my local Mac — would you be able to take on the multisig support task instead of me?

[canu0205]

Two options for supporting multisig btc transaction signing and submission:

1) setup a multisig descriptor wallet

Flow

ref for multisig wallet setup

1. Build a descriptor for staker branch, e.g. tr(<internal>,{multi_a(m,[pk1,pk2,...])})
2. Add a checksum: bitcoin-cli getdescriptorinfo '<desc>' | jq -r .descriptor
3. Import once: bitcoin-cli … importdescriptors '[{"desc":"<desc#csum>","timestamp":"now","active":true}]'
4. Update signer code to include all TapBip32Derivation entries, accept multiple TapScriptSig, and/or call finalizepsbt to build the witness.

• Pros
  • Leverages bitcoind to sign; no custom crypto; clean PSBT path.
• Cons
  • Requires descriptor wallet; code changes in btc-staker PSBT builder/signer; still need to manage descriptor import.

2) load private keys into stakerd

Flow

1. Add config for ordered staker WIFs and threshold; parse with btcutil.DecodeWIF on startup.
2. Use your BuildMultiSigStakingInfo to build the tapscript leaf and control block for the staker branch.
3. Compute BIP341 script-path sighash for that leaf; sign with in-memory keys; assemble witness [sig/empty per key order, tapscript, controlblock].
4. Broadcast via RPC sendrawtransaction; bitcoind is only used for UTXO discovery/broadcast.

• Pros
  • No descriptor import; full control; works even if bitcoind taproot script signing is unavailable.
• Cons
  • You own the signing code/testing; keys live in-process; potentially more Go code to maintain.

Suggestion

Since this is a testing purpose, we can make stakerd handle multisig btc staker’s private keys directly. Option 1 looks feasible for me, but need extra consideration for adopting descriptor wallet instead of legacy wallet. For those reasons, i suggest an option 2.

But if you have any other thoughts, questions, or context on supporting legacy wallet instead of descriptor wallet at the time of implementing btc-staker, please let me know. @RafilxTenfen

[RafilxTenfen]

Hey @canu0205, I’d suggest going with your proposal (option 2). Ideally, this would work similarly to how Cosmos handles multisig via the CLI.

The flow I have in mind is:

1. One party creates the transaction, signs it, and outputs it to a file.
2. Another wallet loads that signed transaction, adds its signature, and outputs an updated file.
3. Once the required number of signatures is collected, anyone can broadcast the transaction.

Since the btc-staker is currently intended only for internal testing and usage, there’s no need to over-engineer this with many complex options. Feel free to choose the approach you think makes the most sense.

[canu0205]

hey @RafilxTenfen, I was thinking of adding all private keys into stakerd.conf separating from the one wallet config and when stakerd startup, load those private keys into the program. after that, sign with those keys.

do you think this flow is over-simplified or is it good enough for internal testing?

[RafilxTenfen]

good enough for me 👍