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)
connOptions.m_i2p_accept_incoming = args.GetBoolArg("-i2pacceptincoming", true);
    if (!node.connman->Start(*node.scheduler, connOptions)) {
        return false;
    }
     ********************************************************* Step 13: finished
     At this point, the RPC is "started", but still in warmup, which means it
     cannot yet be called. Before we make it callable, we need to make sure
     that the RPC's view of the best block is valid and consistent with
     ChainstateManager's active tip.
    
     If we do not do this, RPC's view of the best block will be height=0 and
     hash=0x0. This will lead to erroroneous responses for things like
     waitforblockheight.
    RPCNotifyBlockChange(WITH_LOCK(chainman.GetMutex(), return chainman.ActiveTip()));
    SetRPCWarmupFinished();
    uiInterface.InitMessage(_("Done loading").translated);
    for (const auto& client : node.chain_clients) {
        client->start(*node.scheduler);
    }
    BanMan* banman = node.banman.get();
    node.scheduler->scheduleEvery([banman]{
        banman->DumpBanlist();
    }, DUMP_BANS_INTERVAL);
    if (node.peerman) node.peerman->StartScheduledTasks(*node.scheduler);
#if HAVE_SYSTEM
    StartupNotify(args);
#endif
    return true;
}