Note: this area is still under construction, more updates coming soon!
- Using bitcoind and bitcoin-cli
- General Mining Questions
- What do these messages from stacks-node mean?
- I have an error not covered above, what do I do?
- Where do I see my STX rewards?
- What does “Won sortition” mean?
- How long do I have to mine for before winning?
- What happens if I restart my miner?
- Where is the default working dir?
- Can I / should I / how do I delete the working dir data?
- Is there a minimum internet connection speed required for mining?
A keychain represents a private cryptographic key used to generate your public BTC and STX addresses used with the Stacks 2.0 network.
Generate keychain command from the Stacks documentation :
npx @stacks/cli make_keychain -t > keychain.json
Generate keychain using stacks-gen from Pascal:
npx -q stacks-gen sk --testnet > keychain.json
Note: the commands above will save the keychain information to a file named
keychain.json. You can view this file in a text editor or via the command line using
cat keychain.json. or
It depends on what network you want to target.
An example of a working configuration file is available here .
xenon config mainnet config (both from stx-miner-setup??)
No, this should be the hex of the private key, which is a long string provided as part of your keychain.
The BTC and STX addresses are derived from the private key, which is provided to stacks-node via the
seed value in the configuration file.
See Bitcoin Core website.
There is a great resource for Learning Bitcoin from the Command-Line from BlockchainCommons that outlines different configuration options and usage examples for bitcoind / bitcoin-cli.
The easiest way to check that the miner is running correctly is by making sure the chain info comes into sync, and following that, the BTC balance starts to decrease. This means the miner is actively participating in the network.
If running on the CLI, by querying the /v2/info endpoints of your miner against the main one.
Testnet: http://krypton.blockstack.org:20443/v2/info Mainnet: http://localhost:20443/v2/info Local:
No, this is not necessary for miner operation as it is designed to work behind a NAT connection.
If running via the CLI, add the
burn_fee_cap setting to the configuration under the
The default spent by a miner is 20,000 sats per block it attempted to mine, and mainnet blocks move at the same rate as BTC blocks.
As miners are working to agree on the same view of the chain, occasionally a longer fork can overtake the current one. This can orphan a block created by your miner, and is part of why the STX rewards for mining a block do not show up for 100 blocks.
There are some common messages from stacks-node that can be safely ignored. If you see any of the messages below, it is not an error that needs to be reported.
[ThreadId(X)] convo:id=XX,outbound=true,peer=UNKNOWN+UNKNOWN://XX.XX.XX.XX:20444: failed to recv on P2P conversation: PermanentlyDrained [ThreadId(X)] No open socket for XXX [ThreadId(X)] Invalid block commit: no corresponding leader key at XXXX:X [ThreadId(X)] REJECTED(XXXX) block-commit (hash) for (hash)
Post in the the Stacks Discord chat under #mining with more information about your configuration, the step you got stuck on, and any screenshots, if applicable. The community is really helpful!
Miners spend Bitcoin (BTC) to earn Stacks (STX), however the rewards are not immediate. It takes 100 blocks for the STX rewards to appear based on the reward cycle.
It means that your miner was selected to create the next block in the Stacks blockchain, and will receive a STX reward after a 100 block maturity time.
The node has to catch up with the network first, which takes longer as the chain height increases. check that your node /v2/info endpoint returns the same as the seed node.
From there, it is random, and depends on the number of miners participating. One winner is selected each election to create the next block in the Stacks chain.
By default, a folder containing the Stacks blockchain data is created in a temporary folder. Stopping and starting the miner will cause it to start over and have to resync with the network.
The default is
/tmp and the folder name starts with
C:\tmp on Windows.
You can add working_dir = “PATH_TO_STORAGE” under [node] in your config file, but it is safer to empty the directory before starting the node, as there are some known issues restarting with existing data.
Also, this gist from whoabuddy creates a rotating backup of the working_dir on a set interval using rsync and cron. Requires some modification
If you are not using the working_dir setting in your config, every time you run the miner a new folder will be created in the temporary folder for the chain state and the sync progress will reset to 0. This should not use up a lot of resources however older folders can be safely deleted.
Note: Linux clears the
/tmp folder on reboot.
Faster is better, stable is best, but success has been reported with 10mbps/2mbps on a rural wireless connection.