I’d recommend not to turn your minting device to a full node. A full node needs to fully reachable (on network level). If you are at home at an internet access with NAT, you need to to forward ports to the full node. I’d feel not good with the minting device being reachable that way.
Although the node is protected by a rpcuser and an rpcpassword, on a network level it can be reached.
If you want to mint and have a full node, I’d recommend at least 2 devices for that
Technically it should be no problem to have a Peercoin node and a Nu node running at the same time.
TEST ARM binaries have been compiled by @CoinGame:
You need at least 10,000 NuShares to mint. It takes sevens days for them to mature, which allows them to mint. The block reward for minting is 40 NuShares. You can also vote on custodians, park rates, and motions when you mint a block. There’s more detailed info here on our NuShares introduction guide.
I don’t quite understand why full nodes are so important (I have read it before). All nodes have their IPs stored at its peers who pass the IP to other peer nodes. Even a non-full node is known be many nodes, no?
Thank you very much for your initiative, @desrever!
Let me start with I’d either run a full node OR mint with a device - NEVER mint on a full node.
But that might be related to security related paranoia
I tried to follow your list, but some points have been mixed into others. I beg your pardon for that.
The link @mhps provided looks good. It’s been some time since I last compiled nud on a RaPi.
But the dependencies and the miniUPNP workaround look familiar.
No special permissions are required for running nud. You might want to create a dedicated user with especially limited rights (applies especially for full nodes).
Regarding full nodes:
Afaik Nu nodes listen on port 7890 - at least this port seems to be the standard port according to the output of “nud getpeerinfo”.
Full node at home:
If your internet router supports UPNP and you compile nud with UPNP support (edit src/makefile.unix from “USE_UPNP:=0” to “USE_UPNP:=1” before compiling) you don’t need to forward ports manually. UPNP does that.
Port forwarding is necessary if you have an internet access with NAT (which is true in almost all cases; IPv6 will change that).
If you need to forward the port on which remote Nu clients try to contact your full node manually (because of missing UPNP support), forward port 7890 on the internet router to the IP address of your full node, port 7890 (example: forward 0.0.0.0/0, port 7890 to 192.168.0.10, port 7890 - replace 192.168.0.10 with the IP address of your node).
If you want to run your full node on a different port for whatever reason, forward to that port (in this case 1234) and create a nu.con file like this
Full node on a server in the internet:
If you run a full node on a virtual server in the internet without NAT, there’s no need for forwarding ports Running servers in the internet should be done by people who know what they do. Explaining the details is beyond the scope of this post
Regarding minting nodes:
make sure to recommend putting a complex rpcuser password into the nu.conf file (why not using complex rpcuser names as well -> paranoia) when running nud as server.
Running nud as server (“nud --daemon”) is more convenient than running nud as application imho.
Without the wallet passphrase in the hands of an attacker you don’t need to fear for the coins, but anything that doesn’t require a password can be done, if somebody has network access to the minting node and knows the nu RPC (e.g. unrecognized executions of “nud walletlock” or “nud stop” could prove unconvenient if staying unnoticed for too long…).
Without port forwarding and protected by NAT there shouldn’t be much danger by running a minting node at home.
Using complex rpcuser and rpcpassword settings doesn’t hurt, though.
A nu.conf for a minting node could look like this:
I recommend running Nu on a RaspberryPi2.
Compared to the RaspberryPi1 it has
more RAM (1GB instead of max. 512 MB)
the CPU is waaaay faster
it consumes less electricity (which is not very important in terms of electricity bill…) and because of that the SOC stays cooler
the price is more or less the same and you can use micro SD cards which don’t protrude from the board
For a full node I could offer uploading my latest build of nud somewhere.
For minting nodes I can only recommend building the executable from the sources or downloading the executable form a trusted location. Building nud on the RaPi2 doesn’t take much time and you now what you get
Compiling from the source is quite straight forward if you follow the link @mhps provided
It’s nice to run “strip nud” after compiling is complete: it shrinks nud to a fraction of its size.
Well i’m a bit late to respond to the ping, and it seems like everything has been answered. I don’t know if I saw it mentioned somewhere but I always had to set up a swap space to compile it from source.
Those are the commands I was running to set it up. It may not be as much of a problem on the RaPi2, but on the first one I needed it. It took a LONG time to compile. I think upwards of two hours sometimes.
I think you should distinguish a full node that invites all the world to connect and a minting wallet node that security is important. The former has no fund and is barely more an empty R-pi on the net. There is not a lot motivation to break into it and default security setting is almost enough (get a good password though). The latter has funds and should have better security but overkill steps discourages adoption.
what I do specifically -
Either use user pi for simplicity or create a user of random name.
Only needed for full node.
[quote]enable ssh keys and disable password login
Keep passwd login for situation when you want to get into the pi without network connection. Do use a strong password.
starting nud -daemon is good enough for me.
I got everything working on my laptop and ftp the data directory (with the database subdirectory) to the pi. The wallet on the pi can be used with the same balance, passwd, and doesn’t need to download the full block chain. Remember to chmod 600 all data files.
peerbox links .bash_history to /dev/null so there is no history
I have made a few scripts since I tend to forget -
start (start the daemon) ./nud -daemon
pass (Type in the password to start minting. There is no prompt! the password shows! type password, press return, press control-D) ./nud walletpassphrase `cat` 999999999 true
Sure. After thinking it through this tutorial will illustrate how to run a minting node for securing the network via voting and staking. Will do a full node version when there is demand for it.
[static ip]Only needed for full node.
So you suggest to hide ssh from outside the network as a security measure?
What do you mean?
That’s actually a good point… What are the pros and cons of having a raspi minting on the same wallet you use somewhere else via GUI (on a laptop, like you said) ?[quote=“mhps, post:11, topic:490”]
I have made a few scripts since I tend to forget -
this is also why you’d want nud to run as a service
I thought you meant that the Pi should have a static IP to the outside world. I set up the router so that it always assign the same LAN IP to the Pi according to the MAC address. So the pi doesn’t need to change from DHCP, and internally it is easy to remember where to ssh to.
I recommend set up the router to block any connection of in bound ssh.
When you said “disable password login” did you mean it wouldn’t be possible to login from a plugged-in keyboard and monitor? If yes you could lock yourself out if you don’t have the other computer whose key is stored in the Pi.
I don’t mean they should mint at the same time. Usually the pi mints. The lap top is either off or running the client in locked mode to monitor new block rate remotely as a pi/nu-network health indicator.
peerbox has ppcoind in service mode. I find it very difficult to remember where all the files are located after a while. There are 3-4 places… /var/lib/ppcoind for the blkchain, /etc/conf.d for the service start conf file, ~/.ppcoin/ppcoin.conf for a user config… of course they are all different for a different kind of linux… nud stop is not enough to stop the service, you have to do a systemctl stop ppcoind … How confusing!