Using Bitcoin Core v0.15.1

I have just set `onlynet=onion` in my `bitcoin.conf` file and have the following in my logs after node restart:

    2018-02-03 12:40:52 receive version message: /Satoshi:0.15.1/: version 70015, blocks=507429, us={IPv4}:{port), peer=0
    2018-02-03 12:41:15 receive version message: /Satoshi:0.14.2/: version 70015, blocks=507429, us={IPv4}:{port), peer=2
    2018-02-03 12:41:22 receive version message: /Satoshi:0.14.2/: version 70015, blocks=507429, us={IPv4}:{port), peer=3
    2018-02-03 12:41:28 receive version message: /Satoshi:0.15.0/: version 70015, blocks=507429, us={IPv4}:{port), peer=4
    2018-02-03 12:41:57 receive version message: /Satoshi:0.15.99/: version 70015, blocks=526679, us={IPv4}:{port), peer=5
    ...
    2018-02-03 12:44:11 receive version message: /Satoshi:0.15.1/: version 70015, blocks=507429, us=[::]:0, peer=6

The peer 6 was an onion.

My `bitcoin.conf` file is as follows:

    uacomment={redacted}
    prune=10239
    banscore=10
    bantime=31536000
    maxmempool=900
    mempoolexpiry=2160
    proxy=127.0.0.1:9050
    listen=1
    bind=127.0.0.1
    onlynet=onion

All the `Used for reaching peers via` tick boxes are still ticked but disabled when I look in Options>Newtork.

Bitcoin Core should not initiate IPv4 (or IPv6) connections when `onlynet=onion`.  These connections should not be seed nodes due to low addresses:

    2018-02-03 12:40:30 Loaded 66198 addresses from peers.dat  254ms

I get some IPv4 version messages each time I restart the node.

Note: added both `dns=0` and `dnsseed=0` at the same time and this *seems* to resolve the issue with limited testing. These entries should not be necessary to limit IPv4 outgoing connect.

If people need to setup Tor for testing, the setup I have used is here on [Bitcoin.SE](https://bitcoin.stackexchange.com/a/70070/75001)
if (status == node::ChainstateLoadStatus::SUCCESS) {
                fLoaded = true;
                LogPrintf(" block index %15dms\n", GetTimeMillis() - load_block_index_start_time);
            }
        }
        if (status == node::ChainstateLoadStatus::FAILURE_INCOMPATIBLE_DB) {
            return InitError(error);
        }
        if (!fLoaded && !ShutdownRequested()) {
             fir
            if (!options.reindex) {
                bool fRet = uiInterface.ThreadSafeQuestion(
                    error + Untranslated(".\n\n") + _("Do you want to rebuild the block database now?"),
                    error.original + ".\nPlease restart with -reindex or -reindex-chainstate to recover.",
                    "", CClientUIInterface::MSG_ERROR | CClientUIInterface::BTN_ABORT);
                if (fRet) {
                    fReindex = true;
                    AbortShutdown();
                } else {
                    LogPrintf("Aborted block database rebuild. Exiting.\n");
                    return false;
                }
            } else {
                return InitError(error);
            }
        }
    }
     As LoadBlockIndex can take several minutes, it's possible the user
     requested to kill the GUI during the last operation. If so, exit.
     As the program has not fully started yet, Shutdown() is possibly overkill.