Support external Ethereum keyfile for swarm identity

[chrishobcroft]

Summary

Add a --swarm-keyfile flag that allows specifying an existing Web3 Secret Storage V3 keyfile as the swarm/Ethereum identity, instead of always generating or loading from {data-dir}/keys/swarm.key.

Motivation

Operators running bee alongside other Ethereum node software (e.g. go-livepeer, geth, or other EVM clients) on the same host currently maintain separate private keys for each system. This means:

• Multiple keys to back up, secure, and fund
• Multiple Ethereum addresses to manage across chains (e.g. Gnosis Chain for bee, Arbitrum for go-livepeer)
• No unified on-chain identity across services

Bee's keystore implementation already uses the Web3 Secret Storage V3 format and can decrypt keyfiles with both standard SHA3-256 and LegacyKeccak256 MACs. The format is fully interoperable with keyfiles produced by go-ethereum and projects that use it — the only barrier is that bee has no way to point to an external keyfile.

A concrete use case: an operator runs both bee and go-livepeer on the same machine. go-livepeer stores its keyfile at ~/.lpData/arbitrum-one/keystore/UTC--2024-...--<address>. Today there is no way for bee to use that same key as its swarm identity without manually copying the file and matching passwords. With --swarm-keyfile, the operator could point bee directly at the existing keyfile.

Implementation

Add a new CLI flag and config option:

--swarm-keyfile    path to an existing Web3 Secret Storage V3 keyfile to use as the swarm identity

In configureSigner() (cmd/bee/cmd/start.go), when --swarm-keyfile is set:

1. Read and decrypt the specified keyfile using the existing password mechanism (--password / --password-file / interactive prompt)
2. Use the decrypted secp256k1 private key as the swarm signer identity
3. Skip generation of {data-dir}/keys/swarm.key — the external file is the source of truth
4. Continue generating libp2p_v2.key and pss.key independently as usual

The decryption logic already exists in pkg/keystore/file/key.go (decryptKey / decryptData). The change is primarily in the startup wiring — reading from an arbitrary path rather than the fixed swarm.key location.

Considerations:

• The flag should be mutually exclusive with any future swarm key generation — if the file doesn't exist or can't be decrypted, bee should fail fast with a clear error rather than silently generating a new key
• The keyfile's private key must be on the secp256k1 curve (same validation that already exists for swarm.key)
• Environment variable: BEE_SWARM_KEYFILE
• Config file key: swarm-keyfile

I am willing to implement this feature.

Drawbacks

• Adds a new flag to an already large flag set (67 options). However, it is narrowly scoped and follows existing patterns.
• If the external keyfile's password differs from the password used for libp2p/pss keys, the operator must use the external keyfile's password for --password, which would then also be used when generating the other keys. This could be surprising if the operator expects different passwords. A future enhancement could add --swarm-keyfile-password but that may be premature.
• Operators must ensure the external keyfile is not simultaneously mutated by another process (e.g. re-encrypted with a different password). This is an operational concern, not a code concern.