qa-steps.md

1. Run the following commands on a Debian:stretch image
2. apt-get update
3. apt-get install -y apt-transport-https ca-certificates
4. echo "deb [trusted=yes] http://packages.o1test.net unstable main" | tee /etc/apt/sources.list.d/coda.list
5. apt-get update
6. apt-get install -y curl coda-testnet-postake-medium-curves=0.0.16-beta7+-qa-branch-block-production-fixes-723cd47 --allow-downgrades
7. wget -O ~/daemon.json https://gist.githubusercontent.com/es92/7b473944528968b067725b6ef319abc4/raw/870ca575c60b6983e759e6f47b6ae1fe10371814/daemon-10-17-2020.json
8. coda daemon -peer /dns4/seed-two.pickles-public.o1test.net/tcp/10001/p2p/12D3KooWFcGGeUmbmCNq51NBdGvCWjiyefdNZbDXADMK5CDwNRm5/ -peer /dns4/35.237.193.100/tcp/10001/p2p/12D3KooWAFFq2yEQFFzhU5dt64AWqawRuomG9hL8rSmm5vxhAsgr -config-file ~/daemon.json -generate-genesis-proof true -log-json -log-level Trace | coda-logproc | tee ~/coda-log.txt
9. Send us logs shortly after connecting (~1hr) and after the node has been running a while (~24hr) if you can. Send your discord username, coda-log.txt, coda client status > status.log, and details on the platform you’re using via email to logs@o1labs.org. If the log file is too big, either compress it before attaching to your email or upload it to Google Drive and share the file with logs@o1labs.org (include your discord name, coda client status > status.log, and details on the platform you’re using in the Share Message note)
10. Post any issues to github. Please include your coda-log.txt, details on your platfrom, and a printout of coda client status to the issue. If an issue exists already, please add your above information to the issue

Issue priority labels:

• Critical: Anything that stops a node from connecting to the network. For example, if a node crashes, is unable to sync, or is unable to connect to peers.
• High: Anything that doesn’t stop a node from syncing, but causes bad functionality of other features. For example, anything to do with connectivity that doesn’t break connectivity, or some transaction types not working as expected.
• Medium: Unintended behavior that does not break nodes or features. For example bad logging or error handling.
• Low: Convenience improvements

Hardware Requirements:

Sending and receiving mina does not require any special hardware, but running a block producer on the Mina network currently requires:

• at least a 8-core processor
• at least 8GB of RAM

Note that if you plan on running a snark worker node, you may need more RAM -- 16GB is recommended. GPUs aren't currently required, but may be required for node operators when the protoctol is upgraded.

Network: At least 1 Mbps connection

VM Instances: O(1) Labs has tested running nodes on several cloud providers, and recommends the following instances for basic node operator needs. Keep in mind that custom requirements as well as different cost constraints may require a different instance type.

To learn more about our hardware requirements, visit https://minaprotocol.com/docs/getting-started

Notes:

• You will notice that your node is stuck at synced at block height 1 until the network produces a new block. This is a known issue and will be addressed in the future releases
• The log files will contain errors such as "Coda_net2: failed to parse log line from helper stderr " and variants of "Libp2p_helper.Go.addrutil: adding resolved addr:/ip4/0.0.0.0/tcp/8302". These are expected and will be addressed in the future releases
• You might see the following errors in your log file. These are known errors and can be ignored:

1. Genesis_ledger_helper can't find keys error messages: These can be ignored unless your build actually crashes immediately afterwards. Why is this happening? We want to see the errors.
2. All of the libp2p errors: We need to go back and be more careful about hiding some of these messages as they look a lot scarier than they are. But for now, you can ignore them.
3. You might see some errors in reading coda version