Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Support external Ethereum keyfile for swarm identity

Open
  • Is something wrong?
#5,351 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
go
Domain
backend, cli, security

Research direction

Start with configureSigner() in cmd/bee/cmd/start.go and trace how the existing swarm key is loaded, passwords are obtained, and other keys are generated. Read pkg/keystore/file/key.go for the existing decryption and validation paths. Done means the new flag and config option use an external keyfile as the swarm identity, fail clearly when it is invalid, and leave independent key generation unchanged; no tests are named in the issue.

Written by the indexing model from the issue text.

Description

feature seen
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.
Dominant language
Go
Stars
1.5k
Forks
390
Avg merge
2d 11h
Merged PRs (30d)
23

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ethersphere/bee

All issues in ethersphere/bee

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.