Essential Guide to Becoming a Steem Witness

in #steemhelp4 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

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.

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

"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 :)

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

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.

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'm curious is this still valid?

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

dont think so this is working...

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?

Coin Marketplace

STEEM 0.21
TRX 0.02
BTC 11227.69
ETH 391.11
SBD 1.04