Essential Guide to Becoming a Steem Witness

in steemhelp •  2 years ago


This guide gives much of the inside info and technical nitty-gritty that you will need to make a respectable attempt at being a witness for Steem.

Within the witness node config.ini file

  • Comment or delete all of the miners.
  • Comment or delete the mining-threads setting.
  • Have one witness (your witness, of course).
  • Assign the signing key for the witness to the private-key setting.

The signing key is the private key for the signing public key that is reported for the get_witness command. Example:

get_witness mywitness

An example of select parts of the witness node config.ini file is:

# name of witness controlled by this node (e.g. initwitness)
witness = "mywitness"

# name of miner and its private key (e.g. ["account","WIF PRIVATE KEY"] )

# Number of threads to use for proof of work mining
# mining-threads = COMMENTED OUT

# WIF PRIVATE KEY to be used by one or more witnesses or miners

Notice that there are no quotes around the private key.

For the witness server in general

  • Close all incoming ports except SSH (port 22) and only open SSH for the IPs you know you'll use to control the witness server.
  • Be extra sure your blockchain is functioning by starting with the --replay-blockchain flag.
  • Redirect your stderr (and stdout) on start-up so your witness doesn't go down when you disconnect from SSH. See the example start command below for how this is done.

It is best to close ports using your hosting provider's firewall. Otherwise you should configure iptables or similar.

The start command for the witness node should look like this:

./steemd --replay-blockchain --rpc-endpoint 2>debug.log 1>>info.log &

Replay will take a while and is optional. Do it upon first start if, for example, you sync using a copy of a witness directory from elsewhere. If you need to boot in a hurry, say if your primary witness node goes down, leave out --replay-blockchain.

Set up a separate seed node

The seed node is a completely different server from your witness node. It is a requirement for those who want to credibly offer themselves as witnesses.

If the seed node is going to be on a dynamic IP address, use a dynamic DNS service like ZoneEdit, and register a domain name to point at it.

  • Open port 2001 in your firewall. You can actually use any port, but 2001 is a de facto standard established by Dan Larimer. Unless you have a fairly good reason to use another port, just use 2001.
  • With port 2001 open in your firewall, start the seed node with the flag --p2p-endpoint=
  • Ensure your seednode daemon stays live like you did with the witness node by redirecting output. See the start command above.
  • Check your seed node connectivity with the shell command telnet SEED_IP 2001 from a second computer. A successful connection will spit out a line starting with "Trying SEED_IP...", then "Connected to ..." then "Escape character ..." and then some garbage. After a few seconds it will disconnect automatically due to a non-response time out.

Advertising your intent to be a witness

  • Put up a post at steemit's "witness-category" explaining your credentials as a witness operator and how perfectly awesome your hosting service is for your witness node. Provide the IP address (if static) or domain mame for your seed node. Also provide the port (e.g. 2001). Do not provide the IP address or domain name of your witness node. This latter information should be kept secret, for security.
  • Cross-post your witness post to the Steem thread at bitcointalk
  • Let everyone at the Steem Slack know your intentions, especially in the "#witness" channel.
  • Be helpful to the community as much as possible. Try not to use profanity. Genuinely enjoy the outdoors, children, and small animals. Respect your elders. Be attentive to your civic duties. Go to bed early. Get up early. Drink plenty of water. Lay off the carbs and avoid trans fats. Exercise.

Testing your witness node

You can test your witness node during the mining period (which may be over by the time you see this).

In addition to a witness server and a seed node, you need a mining machine.

Testing your witness node is for experts only. However, if you lack the confidence in your expertise to try this, then you may want to reconsider being a witness.


Yeah, that's shouting and potentially obnoxious, but it's for your own good. If a witness tries to mint blocks on two different machines, it runs the risk of being caught for producing double work on a block, which will be interpreted as a malicious attempt to fork the chain. When this happens, the witness will likely be reported by an observer, and the totality of the witness's VESTS will be transferred to the reporter. The witness will cease to be a witness and it will be a dark day for the witness's owner.

You have been warned.

With this setup, when your miner broadcasts PoW, your witness will enter the queue. When it gets into the top 21 of the queue, it will begin to mint blocks as a witness, which your witness node should handle. It may miss some blocks depending on the competition at the top of the queue. However, if it hits its fair share, then the witness node is operating correctly.

Following are example relevant sections of configuration files for the miner and witness nodes.

Miner Node

# config.ini for miner machine
witness = "otherminer"

miner = ["mywitness", "5MYWITNESSOWNERKEY"]
miner = ["otherminer", "5OTHERMINEROWNERKEY"]

Notice how the witness setting for "mywitness" is missing. That's real important!

Witness Node

# config.ini for witness machine
witness = "mywitness"

# 5MYWITNESSSIGNINGKEY does not necessarily need to be 5MYWITNESSOWNERKEY


# mining-threads = COMMENT THIS OUT
Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  trending

Using Ubuntu's Upstart to Make Steem a Service

This post is an addendum to the essentials document and describes how to use Ubuntu's upstart to make Steem a startup service with minimal fail protection (to restart the service if the process dies or server reboots).

Modifying and Installing The Steem Upstart Script

The full script is provided at the bottom of this post. Save it as "steem.conf". The service will be called "steem".

You will want to change several parts of this script to fit your setup:

  • Change the "author" and email.
  • Change the "chdir" line to the path of your Steem working directory (one directory higher than witness_data_dir).
  • Change the "exec" line to point to your steemd daemon.

Once you have edited the script, copy it as sudoer to the /etc/init directory:

sudo cp steem.conf /etc/init/steem.conf

Starting the Steem Service

The easiest way to start the Steem service (and test your config at the same time) is to simply reboot your computer. It is recommended to go ahead and reboot because you will want to test that the steem service starts on reboot anyway. I reboot like this:

sudo reboot

If you don't wish to reboot, you can do the simple command (ensuring first that all other instances of steemd are stopped)

sudo start steem

You can verify that the steem service is running with this command:

ps aux | grep steemd

Which will give something similar to the following output:

ima@ubuntu:~$ ps aux | grep steemd
root       966  0.5  3.5 607992 141480 ?       Ssl  09:07   4:06 /root/steemd --rpc-endpoint

Testing the Service

The first test should have been when you rebooted to start the steem service.

Let's assume that you your ps output included the line:

root       966  0.5  3.5 607992 141480 ?       Ssl  09:07   4:06 /root/steemd --rpc-endpoint

This means that steemd is running as process 966. Let's kill that process and see if the steem service bounces back. The way to kill process 966 is with this command:

sudo kill 966

Here is my output of the full process. Yours should look similar.

ima@ubuntu:~$ ps aux | grep steemd
root       966  0.5  3.5 607992 141736 ?       Ssl  09:07   4:08 /root/steemd --rpc-endpoint
ima       3130  0.0  0.0  11744   924 pts/1    S+   21:22   0:00 grep --color=auto steemd
ima@ubuntu:~$ sudo kill 966
ima@ubuntu:~$ ps aux | grep steemd
root      3132  0.0  0.3 137676 12268 ?        Rsl  21:22   0:00 /root/steemd --rpc-endpoint
ima       3136  0.0  0.0  11740   932 pts/1    S+   21:22   0:00 grep --color=auto steemd

It looks like success. The steemd daemon respawned as process 3132 within seconds of the kill. You may be wondering what the "ima" lines are in the ps output. Those are simply the grep processes I used to filter the full ps output.

Steem Service Upstart Script

# steemservice - steem daemon service for witness
description "Steem"
author "Ima Witness <>"

# Stanzas
# Stanzas control when and how a process is started and stopped
# See a list of stanzas here:

# When to start the service
start on runlevel [2345]

# When to stop the service
stop on runlevel [016]

# Automatically restart process if crashed

# Essentially lets upstart know the process will detach itself to the background
# This option does not seem to be of great importance, so it does not need to be set.
#expect fork

# Specify working directory
chdir /path/to/steem/working/dir

# Specify the process/command to start, e.g.
exec /path/to/steem/daemon/steemd --rpc-endpoint 2>>debug.log 1>error.log

Great guide!

I used steemychicken1's guide to block all ports except 22 on my witness node. This had the unintended effect of blocking the port that upstart listened on.

A quick scan using netstat allowed me to see that upstart was listening on port 8769. Using the same commands for the guide linked above, I unblocked port 8769 and everything worked.

Thank you!


FYI, Ubuntu 16.x now uses systemd by default in place of upstart.

Permanent switch back to upstart

Install the upstart-sysv package, which will remove ubuntu-standard and systemd-sysv (but should not remove anything else -- if it does, yell!), and run sudo update-initramfs -u. After that, grub's "Advanced options" menu will have a corresponding "Ubuntu, with Linux ... (systemd)" entry where you can do an one-time boot with systemd.

If you want to switch back to systemd, install the systemd-sysv and ubuntu-standard packages.


why the hash rate so low in upstart mode? 1hps!

782782ms th_a witness.cpp:429 on_applied_block ] hash rate: 1 hps

Nice! This should be very helpful for new witnesses. Just wanted to add another potentially useful tidbit.

"Redirect your stderr (and stdout) on start-up so your witness doesn’t go down when you disconnect from SSH. See the example start command below for how this is done."

You can also accomplish this by running the witness command from within a screen session. The added benefit of using screen is that you can have multiple windows for monitoring the server.

To Install
sudo apt-get install screen

Start the screen session

Open additional screen window
ctrl-c a (hit ctrl-a, release and press c immediately after)

Cycle through to the next window
ctrl-a n (hit ctrl-a, release and press n immediately after)

To Detach(Use before exiting server)
ctrl-a d

As long as you started the steem binary within screen and detach before disconnecting, it should continue running after you disconnect

To reconnect to a screen session after reconnecting to the server you can use the following commands:
screen -r
screen -dr


I prefer tmux. : )


byobu is pretty nice too !


 ctrl-a H (Please be careful, we use capital ‘H’ letter)  - Write output screen session text to log file.

Hope that helps me one day to become :-) Added to Awesome Steem

I strongly encourage you to install fail2ban on your witness servers...

Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs -- too many password failures, seeking for exploits, etc. Generally Fail2Ban is then used to update firewall rules to reject the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email) could also be configured. Out of the box Fail2Ban comes with filters for various services (apache, courier, ssh, etc).

Fail2Ban is able to reduce the rate of incorrect authentications attempts however it cannot eliminate the risk that weak authentication presents. Configure services to use only two factor or public/private authentication mechanisms if you really want to protect services.

Another good idea is to use Public key authentication instead of password authentication.

"Be helpful to the community as much as possible. Try not to use profanity. Genuinely enjoy the outdoors, children, and small animals. Respect your elders. Be attentive to your civic duties. Go to bed early. Get up early. Drink plenty of water. Lay off the carbs and avoid trans fats. Exercise."

+5+5+5 :)

is this still valid?? it cant be this complicated can it???


dont think so this is working...

May I suggest an edit where you remove "Overview" so that the summary on the trending page looks better?

Don't we have to set "enable-stale-production" ?


I think that is only necessary when trying to start a new chain or revive an old one. For the pow chosen witnesses associated now, it is not necessary.

So do i need separate steem account for witness and separate on miner?
Now i have one witness node without any miner configured in. Just witness inside the config and private key.
I have also 2 mining machine with configured miner as the same user as witness in witness node. I have no witness in miners config.ini
Is it correct or do i need separate witness account to configure miner?

Witness node:
witness = "duncan-idaho"
private-key = PRIVKEY

Miner node:
miner = ["duncan-idaho","PRIV"]
mining-threads = 6

Is it correct?

Really, really nice tutorial! Congratulations

Can user select signing key? I noticed @wang's signing key is STM1111111111111111111111111111111114T1Anm

Really useful guide ! 👍
Thanks for sharing !!

Best post on witness

I hope this post is helping me to distrubute happiness with poors

In the post OP mentioned:


Can someone explain this to me in a little more detail. Does this mean I should have different accounts for the witness and miner at all times, or is it okay to have a witness and miner sharing the same account on one instance? Just a little confused by this. I'm currently running miners on multiple instances, but I am using a different account for each instance. Each instance does have the same witness name and miner name though. Is this incorrectly set up? Thanks in advance for clarification!


dont mine the witness