Raspberry Pi is good for testing the minimum resource requirements needed to run Monero. As long as Monero continues to work on ARM devices like the Raspberry Pi then scaling concerns related to hardware requirements will not be a problem for most people.
It also is extremely inexpensive in terms energy consumption, with a Raspberry Pi and other ARM systems ...
It's a two way connection, the IN refers to connections initiated by the peer, and OUT refers to connections initiated by your node, but communication is duplex.
In that status command, the X+Y part is X OUT connections and Y in connections. You're connected to all of these nodes, the only difference is which side initiated the connection.
You can change them, either when starting monerod:
--limit-rate-up arg (=-1) set limit-rate-up [kB/s]
--limit-rate-down arg (=-1) set limit-rate-down [kB/s]
--limit-rate arg (=-1) set limit-rate [kB/s]
Or at runtime:
limit limit <kB/s> - Set download and upload limit
Purpose is to independently transact yourself, and verify the blockchain state yourself. If you don't need to transact or check transactions, you don't need to run a node.
If you don't run a node, you must rely on others to do the checks for you and broadcast your TX to the network when you want to transact.
And no, nodes don't make any profit unless they ...
The purpose of running a Monero node is to use Monero, the cryptocurrency.
The monero node is a p2p program which keeps the blockchain in sync with the network at large. It is your connection to the Monero network. The blockchain is needed to sent and receive monero transactions. Since those are private by default, you gain the ability to transact privately ...
Since Monero has a separate daemon monerod, which synchronises with the network, a command line wallet monero-wallet-cli and a GUI wallet monero-wallet-gui to generate keys, sign transactions etc.
Both wallet versions need a fully synchronised node to scan for new outputs. For best privacy, it's recommended to run an own node (locally or remotely hosted), ...
What are the reasons for doing this
First, a full node hosted on a VPS ensures high uptime. If you run a node on a personal computer, you will likely only run it partially, because you turn your computer off from time to time. Higher uptime is better for the network. However, ideally, such a node would run off a personal computer instead of a VPS. There's ...
I couldn't find a public remote testnet node, so I created one on a VPS.
Here's the address...
If you're testing the official CLI wallet, include these options...
./monero-wallet-cli --testnet --daemon-address 188.8.131.52:38081
If you're testing the official GUI wallet, you need to do the following...
Having a partially synced chain does not mean unreliability. It might be that these nodes are syncing the chain, as you presumably did at some point too. Banning these nodes would mean noone can start using Monero, and would cause the network to die off from attrition.
In order to get incoming connections (currently none, as the 8+0 shows), you need to ...
In addition to the issues of uptime and convenience that dEBRUYNE mentioned, another reason for running a node on a VPS could be that you want to run a service that utilizes a Monero wallet, but you don't have the infrastructure to support a wallet processing a lot of transactions, then you can use a VPS to scale the hardware and bandwidth as needed.
Pretty sure that's how it works. You can also use the command "status" and you'll see at the end of the line a number like "8+1" this shows the number of nodes you are connected to, and after the + shows the number of nodes you are serving.
It's even harming the network, since every full node will be synching the whole blockchain from other nodes and using their bandwidth without giving more back to the network than one full node at this location would do alone.
However for one location, there are several possibilities, which differ a little bit from each other:
Home internet access provides ...
Monero wallet's daemon monerod initially and when all recent peers are offline tries to connect to one of the hard coded seed nodes, currently these are:
If it peers with enough regular network nodes, these nodes are not used any more unless all known peers are offline.
To connect to one of moneroworld nodes, one has to establish an outgoing connection. Default firewall policy is to allow outgoing connections and block incomming connections. So you don't need to tweak the firewall to connect to these remote nodes.
For your own full node, that would be the opposite. This SE explains how to remotely access your own full node....
You can use cron to start and stop monerod at the times you want.
Best is to run monerod with the --detach flag to run as daemon, then run without it but the exit command when you want to stop it:
The second line will exit the first one.
In a crontab specification:
0 1 * * * monerod --detach
0 7 * * * monerod exit
Not sure random debug log questions are on topic for stack exchange, but...
Field 2 is the thread logging this message.
Hop is the (untrusted) number of peers forwarding the object.
COMMAND_TIMED_SYNC is one of the P2P traffic messages.
Thanks to Monero Reddit people, I solved the issue. This is the link to the discussion.
The issue was related to timezones because the timezone of the system was set on wrong timezone, one hour behind the correct one. So, I changed timezone with:
sudo dpkg-reconfigure tzdata
and restarted the Pi.
After a long time, the node completed the blockchain ...
the link to the original code base is maintained
Depends what you mean by "link". There is a link to the original code that is maintained whether you fork publicly on GitHub or whether you clone to a private repository.
However, it would make it harder to do things like issue pull requests if you have a clone instead of a fork. See https://stackoverflow....
The methods to open ports are specific to the router you have. You don't need physical access to the router, just access to the routers web admin interface. So, I suggest you search for your specific router model and instructions, if this is your own router.
If you are on a non-configurable network like a public WiFi, instead you need to ask the Internet ...
Since those peers are hardcoded into the Monero software, could a malicious ISP intercept initial communications by redirecting traffic to those peers?
Sure, to another valid Monero node. Traffic NAT'ing happens all the time.
Would this be detectable?
I don't see anything in the codebase that reaches out to STUN, etc. to determine its outside IP (and ...
In addition to https://moneroworld.com/, there is also an automatically updated list of remote nodes on https://www.xmr.be/ (i.e. nodes on this list should always work).
DISCLAIMER: I am the author of this site, I advertise it here following a suggestion on this Reddit thread. Please note that I am not the maintainer of the nodes listed on this site, I only ...
I'm not qualified to answer this but I'll provide this in answer in the hopes that someone more qualified will step in. There is no reason why you shouldn't connect to a remote node, but any node you connect to (local or remote) should be your own, because you can trust your own nodes. In any case, if the node you are going to connect to is remote, you ...
Newly received coins can be spent after 10 confirmations.
I case two conflicting transactions are sent to the network by two clients managing the same wallet, the first to arrive at the node that will mine the next block will probably be considered as the valid one, and the other transaction will then be rejected.
Being connected to a faster node with ...
The simplest way to explain what a remote node is would be to say that it's any node that is not local.
If you are running a node at your home or place or business, you are running a local node. Calling a node a "local" node, means you access it locally. This means you're not going out on the internet to access it. Rather, the node is available on your ...