12

There will be three modes: I2P only: all traffic goes through I2P Clearnet only: all traffic goes through clearnet I2P/clearnet bridged: blocks go through clearnet, transactions go through I2P Since everyone will not be able to use I2P, it will be necessary that some nodes run in mixed mode to avoid the network partitioning. Since the blocks aren't secret, ...


10

8 is the number of peers that you are connected to. 0 is the number of peers that are connected to you. if you want to allow others to connect to you, you need to open port 18080 on your firewall/router.


7

Yes. I think exchanges and such will probably want to remain on clear net. This will require some nodes to operate as "bridge" nodes that will route information between clear and i2p networks.


7

A node will connect to up to 8 peers by default (P2P_DEFAULT_CONNECTIONS_COUNT in src/cryptonote_config.h). I think there is no set limit of incoming connections, though if a lot of peers try to connect, you might end up hitting your open files quota. The more peers you are connected to, the more traffic you will have to propagate blocks and transactions. ...


6

There is a problem with the seed nodes at the moment. This is fixed in the coming release, hopefully in the next day or two: https://github.com/monero-project/monero/pull/1879 In the meantime, you can supply a node to start from: ./monerod --add-peer 107.152.130.98:18080 --add-peer 212.83.175.67:18080 --add-peer 5.9.100.248:18080 (this is simply adding the ...


5

You can set the number of your daemon outgoing peers (ie, peers it connects to) with the command line parameter --out-peers. The default is 8. For having incoming peers, you need to open up your firewall for your daemon's p2p port. This port is typically 18080 but can be customized with the --p2p-bind-port. I think you cannot limit the number of incoming ...


4

This question [After Kovri arrives will some full nodes need to remain on clearnet? ] deals with peer discovery through Kovri. How about peer discovery right now if I wanna run a full node in I2P? Will the current client know to connect to only I2P nodes? Kovri does not yet integrate with Monero. In the future when integrated, there will be three modes: IP ...


3

As a partial answer, here is a list of reverse DNS lookups followed by their respective WHOIS owners: 107.152.130.98 > monero.cc > Riccardo Spagni 212.83.175.67 > poneytelecom.eu > Unknown 5.9.100.248 > your-server.de > Martin Hetzner 163.172.182.165 > scaleway.com > Unknown 161.67.132.39 > Unknown 198.74.231.92 > Unknown 195.154.123.123 > poneytelecom.eu > ...


3

You can set the number of your daemon outgoing peers (ie, peers it connects to) with the command line parameter --out-peers. The default is 8. For having incoming peers, you need to open up your firewall for your daemon's p2p port (typically 18080). I think you cannot limit the number of incoming connections. For limiting the traffic for all of these ...


3

I was suffering from something similar yesterday. When I turned my OS X firewall off, I got the incoming connections back. When I turned it back on, I got 0 incoming connections again. To fix it, I ended up forcing port 18080 open using this guide. Scroll down to the 10th comment if you need help using Vim (I did). I turned the firewall back on and I got ...


3

The goal as outlined by Mr. Fluffy is to use I2P to broadcast transactions and provide Monero services. By default, Monero nodes would still connect as they do now for communicating new blocks and transactions. Wallets would not broadcast transactions through the local node, and instead would broadcast through I2P in an attempt to hide the IP that initiated ...


2

Theoretically if no node accepted incoming connections then the network would be limited to transactions originating from any of the aforementioned nodes. The network would survive as miners would still process those transactions. The biggest effect would come in the loss of third party services that require a remote node to operate (for example some light ...


2

Leaving aside exclusive peers, when a node starts for the very first time, it connects to the seed peer(s) to get an initial peer list. It then attempts to maintain at least 2 anchor peers (if it successfully handshakes with an attempted peer and doesn't already have enough anchor peers, it can be added to the anchor list). If an anchor node goes away, it ...


2

Monero does not require that "mixing" happens at the same time that other spenders want to "mix" their coins. Rather, the sender constructs the complete transaction prior to broadcasting it to the network. The sender's wallet chooses one or more of its own outputs to spend, and then it picks other actual outputs from the blockchain to mix with its own ...


2

I figured out what my issue was. I checked my ufw rules, and there was no rule for allowing port 18080. After allowing that port and reopening monerod (not sure if that was necessary), I'm quickly up to 7+44. (@TFI_Charmers, thanks for the push to double check the firewall.) I don't know why ufw allowed it previously, with no rule, but it must have. ...


1

This file contains the list of peers the node knows about, along with the time they were last seen. Deleting it clears that memory, and the node will have to rely on seed nodes to get a new list of peers. Keeping this file means that you don't have to rely on the seed nodes to be able to connect to the Monero network, as you already know of a large number ...


1

There is a problem with the seed nodes at the moment. This is fixed in the coming release, hopefully in the next day or two: https://github.com/monero-project/monero/pull/1879 In the meantime, you can supply a node to start from: ./monerod --add-peer 107.152.130.98:18080 --add-peer 212.83.175.67:18080 --add-peer 5.9.100.248:18080 (this is simply adding the ...


Only top voted, non community-wiki answers of a minimum length are eligible