When a new build is released, part of the process builds a special XOR'd JAR (the contents are obfuscated to get around certain virus scanners that incorrectly assume all JARs are malicious). That gets uploaded to GitHub. Then the commit hash and hash of the JAR itself are referenced by the ARBITRARY transaction that goes on chain. When the transaction reaches the approval threshold, the core downloads the XOR'd JAR from GitHub, verifies the checksum, converts it back to a regular JAR, and then runs it.

With QDN, we can skip the GitHub part and just include the XOR'd JAR directly with the ARBITRARY transaction. But that won't be for a couple more versions as we have to transition it over.

Do I have to run the core and UI at all times? In other words, if the core is running, but the UI is not, am I still minting?

You must always have the core running to stay fully synced and “minting”. The UI does not have to be running. This also means your computer cannot sleep as that would stop the core from running.

It can take up to a few days to fully synchronize full chain. As of version 2.0 this problem has been solved by automatically downloading a bootstrap on first launch. You will then start syncing from 98 or 99%.

At the moment the default is a random number between 3 and 14 days. So you have to run the core for at least 3 days (ideally 14) before it will trim. This is set like this, referred to as staggering, to avoid everyone trimming and causing peer connection issues at the same time. After an auto update, everyone's cores start at similar times, so they would then trim at similar times later if we did have this particular setting for trimming.

To trim the db on demand, LEAVE THE CORE RUNNING otherwise there will be no API server to receive the command. It's safe to run - the core will just stop functioning during the maintenance. Which normally takes 3-10 mins depending on the hardware. Possibly longer for others.

You can go here: http://localhost:12391/api-documentation/#/Admin/performRepositoryMaintenance

Or use this command:

curl -X DELETE "http://localhost:12391/admin/repository" -H  "accept: */*" -H  "X-API-KEY: apiKeyGoesHere"

A few things worth mentioning…

1. Since v2.0 we optimized the db storage size so that it increases much more slowly than it used to.

2. We have recently found a way to reduce the size of the legacy blocks considerably, so this can be done in the future and we can rebuild the archives. This will also reduce the size of the bootstraps.

If you would prefer to sync from genesis, add the following setting:

"bootstrap": false

Refer to the How To Reduce Bandwidth page.

You can try changing your router settings with port forwarding, or virtual server. These different methods have worked for several people. Otherwise, reach out on Discord for further diagnostics and solutions.

It is never a good idea to add your node in DMZ. That will stop all the DPI and SPI and if you have the API enabled and white listed, you are putting your computer at risk! DMZ bypasses the SPI mechanism of the built in filters and all the internet traffic can reach your node directly. SPI (stateful packet inspection) firewall protects you by examining incoming packets against existing connections. Also add UPnP text. If a router has it then it must be enabled. UPnP or NAT-pmp opens dynamic port ranges to act as an assist for SPI. Enabling NAT/UPnP solves problem for the most but unfortunately due to the torrent p2p laws most ISPs now filter ports by default at the client side so port forward is also needed. For example:

219.88.183.49:12392 (qortal-1.2.3-2df0453), height 42318, sig: PXNoJM7W, ts 2020-07-31 17:17:24

192.168.100.83:44380 (qortal-1.2.3-2df0453), height 42318, sig: PXNoJM7W, ts 2020-07-31 17:17:24

Look at the second IP address with a dynamic port. This is UPnP working. Instead of 12392 , it has opened a 44380 port for TCP handshake / connect / ACK.

You are likely having one of these issues:

1. your system clock is somehow misconfigured, particularly common with Windows systems. Check clock in bottom-right 'system tray' compared with http://time.is/ - if they differ then you need to fix this. Other nodes will refuse to talk to your node if your time is too different.
2. you have some sort of firewall issue. No need to turn off firewall, just allow TCP 12392 (and 12391 if you use API remotely).

Use hostname or IP address. Port is not needed unless it's non-default. When you install, it does come with node1 to node10.qortal.org pre-added.

These work as well:

1. node2.qortal.org
2. 51.83.114.66
3. node2.qortal.org:12392
4. [21c8:4ed::4:5]:12392

http://localhost:12391/api-documentation/

1. minBlockchainPeers defines minimum needed to mint / genblock
2. maxPeers defines limit cap that will not be exceeded
3. minOutboundPeers defines minimum peers your node is allowed to connect to

Refer to the How To Edit Qortal Core Settings page.

If you are a QORA user, you will first need to obtain your ADDRESS SEED (be sure you do not obtain your ACCOUNT SEED as that is a different thing.) Once you have obtained your ADDRESS SEED, you can use the 'QORA seed' login method in Qortal UI to login to the QORA account on Qortal (and obtain your Qortal account address, etc.)

Once you have logged into the QORA account, you can create and assign the minting key just like you would with any other Qortal account. Create the key with a 0% reward share to your own public key, wait for it to confirm, then assign it in node management - add minting acccount.

The API call below is the method for adding the minting key to a headless machine.

curl -X POST "http://localhost:12391/admin/mintingaccounts" -H "accept: text/plain" -H "Content-Type: text/plain" -d "MINTING_KEY_HERE"

-Djava.net.preferIPv4Stack=false \ (software is capable). It all comes down to OS capability. GenX is capable. Windows is also IPv6 enabled by default.

iptables -A OUTPUT -p tcp –syn –dport 12392 -m connlimit –connlimit-above 10 -j REJECT 

1. Download JDK standalone installer
2. Use Localhost core IP with a remote UI access to enter reward share key
3. Download core zip for Github (not the full installer).

Under qortal folder you can check the log file status tail -f log.txt.1

This is due to your node doing AT state trimming which takes a time worth one or two blocks.

Refer to the How To Edit Qortal Core Settings page.

It will not mint as self connect does not count. Your node itself is null !=1. Even if you do, you only fork yourself in an isolated LAN and will never sync. This works by connect:

tx - rx - verify - store - forward - verify - store — infinity

A safe bet would be to set at minimum of 10. Not too low and not too high. You could go as low as 3.

Refer to the How To Reduce Bandwidth page.

You could set your maxPeers to 100. This should be fine with other default settings. This should be more than sufficient for helping the network. Remember that every new peer you have will use more network data. It’s up to each individual what they are planning to use their node for, how much bandwidth and network data they want to use, etc. For supporting the NETWORK most, port forwarding, and 100 maxPeers. For supporting your own network data the most, and conserving it: maxPeers 7, and minBlockchainPeers 3.

Your core must be running all the time. Do not close window with orphaning before it is orphaned to desired block height.

You can try to orphan to some height (ditch your block height to inputted height): http://localhost:12391/api-documentation/#/Admin/orphan

2. Enter desired block height for ditching to (for example: 300000)

3. Then click Execute and keep that page open, it will be like loading all time until your block height is 300000.

Your blocks will start to go down up to that number (300000). When desired height is reached, it will start to sync and then going up.

Height for orphaning to depends, you can try ditching less and then more and more until your node will be on right chain. ( If current height is 302000 try ditch to 300000, if that will not help, try ditch to 298000 and so on… in steps from 1000-2000) No one knows at what block did your core switched to wrong (forked) chain, so it is individual height. If your roll back slows down or looks stuck just quit core and redo all the steps and get rolling back faster!