startup - How to start /usr/bin/bitcoind on boot? - Ask Ubuntu

Gridcoin "Fern" Release
Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that.
Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap.
We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout.
Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.



Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now.
Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date.
The transition height is also when the team requirement will be relaxed for the network.


Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.


The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use.
There are so many goodies here it is hard to summarize them all.
I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures.
The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!

Summary Changelog



Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.







As a reminder:









Detailed Changelog

[] 2020-09-03, mandatory, "Fern"





submitted by jamescowens to gridcoin [link] [comments]

How to get a public static ip for your local lightning node

My lightning node is a node that is running locally on my server hardware in my house down under, far from the New Jersey Digitalocean datacenter, which is what will come up if you look up the ip of the node. This is done via an OpenVPN tunnel from your local machine to a VPS. I am doing this by renting a VPS from Digitalocean for $20 a month (2 vCPUs, 2GB RAM) running Ubuntu 18.04. You can do this just as easily on a $5 a month VPS with 1 vCPU and 1GB RAM or even a $2.50 a month VPS from Vultr with 512MB RAM. I needed the extra power because I have many web services running there as well.
This setup allows me to have a highly available lightning node, not affected by my home IP address changing. If you are using a mobile connection or have a CGNAT, you wont be able to port forward for your lightning node. This setup allows you to do so. You can also use this to make a portable lightning node, which can get you a full lightning node wherever you have power and internet, without having to mess with network settings. If you don't want others to know your home IP, this is a good option for privacy.
  1. Setup a local lightning node, preferably on a linux machine. I followed the Raspibolt tu`ial (with some tweaks) on a 2 vCPU and 8GB RAM VM running Ubuntu 16.04.
  2. Get a VPS with a static IP address. Digitalocean and Vultr VPSs already are. This VPS wont need much power, so get the cheapest one you can.
  3. Secure the VPS. I used this tutorial. Essentially, setup a non root user, use ssh keys, and setup ufw. Also make sure to allow port 9735 through ufw for lightning. I also additionally made adjustments to the ssh config and installed fail2ban.
  4. Setup an OpenVPN server on the VPS. I used this tutorial.
  5. Install on OpenVPN client on the local linux machine and connect to the server. The tutorial from step 4 shows how to this. Keep this connected for step 6.
  6. SSH into the VPS and figure out the OpenVPN IP address of the client. It should be 10.8.0.x. To figure out the x, setup a simple python web server or something on the local machine on port 8000 or something and open the port on ufw in the local machine. Keep the OpenVPN connection, and use a new ssh session when accessing your local machine. Don't kill the OpenVPN connection, as it may complicate things when finding the ip.
    mkdir testweb
    cd testweb
    echo hello >> index.html
    sudo ufw allow 8000
    python -m SimpleHTTPServer 8000
  7. SSH back into the VPS. Run the curl command below, and try all the numbers between 2-10 for x. When you get hello as your output, then you found the right IP. I found mine at 6. You may have to try higher numbers, but this is unlikely. You can kill your python webserver on your local machine once you find it.
    curl 10.8.0.x:8000
  8. Once you have the IP, you want to make this static, so it doesn't change when you reconnect. This is done on the VPS side, so ssh back into the VPS. This tutorial worked for me. Just make sure to change values like the CommonName and and the IP to match yours (client1 and 10.8.0.x). If it doesn't work search "make openvpn ip static" and look around.
  9. SSH into your local machine, and make the OpenVPN connection persistent. You can kill the OpenVPN connection now. Doing this and this worked for me. If it doesn't work search "openvpn keepalive" or "openvpn auto connect linux" or "make openvpn connection persistent linux".
  10. Restart your local machine, and make sure it connects on boot. Do the python webserver test again, and make sure the same ip is shown on the VPS, and it is still accessible.
  11. SSH back into the VPS. Now, you have to port forward with iptables. you have to add the 2 lines below starting with -A PREROUTING in the same place in your /etc/ufw/before.rules file. Here is what mine looks like. Change the x to your OpenVPN IP. Do sudo ufw disable and sudo ufw enable to restart ufw to update your changes.
    -A PREROUTING -i eth0 -p tcp -m tcp --dport 9735 -j DNAT --to-destination 10.8.0.x:9735
    -A PREROUTING -i eth0 -p udp -m udp --dport 9735 -j DNAT --to-destination 10.8.0.x:9735
  12. SSH into your local machine. Change your lnd.conf to match with this setup, like changing the externalip. Here is what my config looks like, a slight tweak from the Raspibolt one:
    [Application Options]
    alias=GCUBED [LND]
  13. Do a sudo service lnd restart to restart lnd and apply the changes. Remember to do a lncli unlock after any restarts. Your lnd node should now have a public static ip. Look it up a few hours after you do this on 1ml, your ip should be the one of your VPS now.
I am monitoring this for free with uptimerobot. It will notify you if it has gone down. So far mine has been running for 3 days and hasn't gone down.
EDIT: Formatting
EDIT 2: The main reason I didn't use a ddns or a hidden service was mainly for high uptime, and low latency. I am planning on developing a lapp with this node and I didn't want to risk any downtime. Running lightning as a hidden service is a great idea as well, this tutorial shows how to achieve something similar with the clearnet.
EDIT 3: You can achieve a similar result from using TOR
submitted by ggelango to Bitcoin [link] [comments]

(Updated) [Staking] Reddcoin Core client GUI wallet on a Raspberry Pi Model 3B


This thread is an update to my first Reddcoin staking tutorial that was written 7 months ago.
The reason for the update
My Reddcoin Core software crashed and became unusable. My Raspberry Pi 3B would lag and freeze, I couldn't stake anymore.
Instead of just redoing everything the same way, I wanted to see if I could improve on 3 points:
The updates
If you would like to tip me
Writing a tutorial like this takes time and effort; tips are appreciated. My Reddcoin address: RqvdnNX5MTam855Y2Vudv7yVgtXdcYaQAW.





This video shows how long it takes to start Reddcoin Core.   TL;DR:


Backup your wallet to prevent losing the RDDs in your wallet! There are two methods to backup, do both. Make new backups if you create a new receiving address!
Boot with only 1 USB drive plugged in:
Make sure only the USB drive (with the swap partition and data partition) is plugged in when you boot up your Raspberry Pi. This to make sure the swap partition (/dev/sda1) is recognized correctly.   If you boot up with multiple USB drives, Lubuntu might see the USB drive with the swap partition as the second drive (instead of the first drive), and ignore the 2 GB swap partition. If this happens, starting Reddcoin can render the Raspberry Pi unresponsive.
Connection issues If you have issues syncing the blockchain because you have 0 network connections, please follow the instructions in this thread.
Start Reddcoin Core easier
Run a shell script (.sh file), so you can start Reddcoin just by double clicking on an icon on your Desktop.
Minimization options
Adjust minimization options, so you can safely press on the X button (the close/exit button on the upper right corner).
RealVNC VNC Viewer (client) and VNC Connect (server): To remote connect to the Raspberry Pi, I use VNC Viewer ad VNC Connect from RealVNC.
Chromium as browser: The updates break Firefox, the browser crashes when you try to run it. Install another browser, Chromium, to solve this issue.
Updates / Upgrades
If Software Updater shows up and tells you that there is updated software available, do not install the updates using Software Updater. Use LXTerminal to update Lubuntu.  


Credits in previous tutorial:
submitted by Yavuz_Selim to reddCoin [link] [comments]

PiHole 4.2.2 on Synology Docker - setup work for me

PiHole 4.2.2 on Synology Docker - setup work for me
I've setup Pihole on both Synology and Ubuntu with success (lucky me). While on Ubuntu was quite straightforward, on Synology needed some experiment.

I do not activate DHCP function on my Synology; my TPLink wifi router handles it without problem.

My Synology fixed IP is (yours could be different)

On Synology, thanks to this website, which gave me 99% success.

Please find below broad steps in setting Pihole version 4.2.2 (latest as at this article) on Synology DSM 6.xx docker:
  1. search Docker registry for 'Pihole', and choose and download 'Pihole/Pihole' which is the official docker from Pihole.
  2. Launch the Pihole image, and use the Advanced setting option to change port mapping and add some environment variables; also check autostart option
  3. Only changes made to the default Pihole container settings:
  • In Port Settings tab, fixed the port mapping for container port 80, 433 to any local port number (I use 8181 and 8182, respectively). For container port 53 tcp and udp, do use 53 for both (local port number must not be duplicated with the same local port numbers being used by other Synology services)
  • In Environment tab, I did two things:
    • change ServerIP value to my Synology fixed IP ( for my synology)
    • add variable WEBPASSWORD and give your desired admin password (to override default Pihole password automatically)
  • To enter into the Pihole admin website, use this url:

They are all the set up I did on my Synology.

On main Wifi Router
The other setup to do is to change default DNS servers on my main wifi router (TPLink). My ISP assigns DNS1 and DNS2 IP for my router, but the router allows me to manually change them. I changed only the DNS1 value to be my Synology fixed IP address, which is; and left the second DNS remains same. From this setup, all devices in my home will be using Pihole services automatically (filter out Ad, porn websites, bitcoin mining....). You may add more blacklist urls under Setting in Pihole admin page.
If you don't want Pihole to filter ad for all your devices, you don't have to change the DNS on your main router. Instead, on the device you wish to have Pihole controlled, you can change the first DNS IP to be your Synology IP, mine is (yours could be different); and keeps the second DNS as is (mine is my main router IP which is

Once you completed the setup on both Synology and Router, log into Pihole admin page, see the statistics in Dashboard, it should display Total number of queries, queries blocked, etc... If no movement on these numbers, that means the setup was not right, you can check the Pihole container log on Synology (in DetailsLog tab).

Pihole container consumes only 0.1x% of my DS411+II Atom D525 CPU, and 300+/- MB ram (from 2GB total RAM). I also run full Calibre engine and content server docker without problem on it.

The Pihole on my Ubuntu will be my backup.

Ports mapping: change from Auto
Change ServerIP value and add variable WEBPASSWORD only
Enable auto-restart

Resources usage
submitted by europacafe to pihole [link] [comments]

Raspberry Pi Home Dashboard

I had a few requests of my home dashboard, and wanted to share with everyone how I put it together.
What you'll need:
Step 1: Instructions to Set Up the Raspberry Pi Itself:
Step 2: Set up the HTML File to Display
  1. Background.png
  2. Dashboard.html
  3. News.html
  4. Map.html
  5. Stocks.html
  6. ToDo.html
  7. Weather.html
  8. Calendar.html
FINAL Comments. This project probably took me 1h to set up the pi. And 4ish hours stumbling around to get the dashboard set up. My only real outlay was a monitor mount and a new monitor. Best of luck!
EDIT Here is the link for the current version of the dashboard. I removed the traffic for the weekend, but this is the dashboard. I have some formatting I really want to do (headings et al), but this should be a decent start. I have also included the color scheme I used.
submitted by fuzzyaces to raspberry_pi [link] [comments]

How to get started on GPU mining on Pizza Pool ( [Nvidia/linux/ClosedSource]

Sunday morining the 0xBitcoin Discord got a surprise from @0xPiZzA...
hi guys. i am 0x778, again! has it gone a long time and you miss me? 8^D= i wait two more weeks since last time, want to check you to see if you are ready for gpu and 0xBITCOIN. today i am ready to release Closed Source GPU Miner for everyone, works for my new Mining Pool name " PiZzA Pool " ! \o/ new pizzaminer is ALPHA software : means speed good but has bugs. Linux only OS. new pool PiZzA Pool also ALPHA but in testing now, available for your to try. credit system is counting. automatic payment, i am building it now. XD lets GO for best! i am not support Help with this software, please figure it out. i believe you can do it. PiZzA Pool going to donate 2% to 0xBITCOIN project / Infernal Toast who will make Open Source Gpu Miner in competition with pizzaminer and Prevail in Triumph. .o/\o/ when you ready, more info : :heart: Have Fun, Love 0xBITCOIN 8^D= ~~ 0xPiZzA :heart: 
GPU mining!!!
PiZzA pool -
Before we start...
Yet the miner works and I've been paid by the pool (71.17318134 0xBTC):
1. Prepare your mining rig
Download required programs:
Using this software is risky, but you can minimize the risk by planning. Ideally you want a sanitized GPU mining rig.
This means:
  • No private key!!!
  • No saved passwords!!!
  • No files you are not comfortable with losing!!!
Use this as a basic security audit if you have an existing GPU mining rig.
2. Download and Install Ubuntu
You can Google this.
I believe in you, you will figure it out. :-D
But get an .iso and use Rufus to make a bootable USB.
3. Install Nvidia Drivers
Don't download them from the Nvidia website. Use repositories instead. This guide worked for me:
Make sure you are connected to wifi at this stage. The error message will not clue you into the fact that your internet is not working.
4. Run the pizzaminer software
Details are in the README.TXT. But essentially all you need to do is run the program. Make sure in properties it has permissions to exectute. Also run each miner in their own terminal instance.
CUDA_VISIBLE_DEVICES=0 ./pizzaminer 0x0123AbC... CUDA_VISIBLE_DEVICES=1 ./pizzaminer 0x0123AbC... CUDA_VISIBLE_DEVICES=2 ./pizzaminer 0x0123AbC... CUDA_VISIBLE_DEVICES=3 ./pizzaminer 0x0123AbC... 
5. Configure Autostart
Inside the directory where pizza miner is create a file (autostart) that is executable and contains your payment address:
#!/bin/sh xterm -e -hold CUDA_VISIBLE_DEVICES=0 ./pizzaminer 0x0123AbC... & xterm -e -hold CUDA_VISIBLE_DEVICES=1 ./pizzaminer 0x0123AbC... & xterm -e -hold CUDA_VISIBLE_DEVICES=2 ./pizzaminer 0x0123AbC... & xterm -e -hold CUDA_VISIBLE_DEVICES=3 ./pizzaminer 0x0123AbC... & ... 
Then from Start>Startup Applications add the following task:
Name: Autostart pizzaminer Command: autostart (browse for file created above)
7. Optimization
v0.0.3 CPU optimization
Before the CPU was bottle necking the GPU utilization in certain cases. v0.0.3 fixes this and it's stable for me. With multiple cards on a Celeron G39XX you can expect a 50%+ boost in overall hash rate.
Overclocking (EXPERIMENTAL!!!)
This command should allow basic overclocking, monitor free initialization. Honestly haven't had much success in the overclocking department. Let me know if you do!
sudo nvidia-xconfig -enable-all-gpus -cool-bits=28 --allow-empty-initial-configuration 
6. Known Hashrates
GPU MH/s MH/s MH/s
Version v0.0.1 v0.0.2 v0.0.3
GTX 970 (40 MH/s) (55 MH/s) (75 MH/s)
GTX 1050 Ti (40 MH/s) (75 MH/s) (90 MH/s)
GTX 1060 (60-70** MH/s) (100 MH/s) (150 MH/s)
GTX 1070 Ti (90** MH/s) () ()
GTX 1080 Ti (140** MH/s) () (325** MH/s)
Please tell me your hashrates to add to this table!!!
If this guide has been helpful please consider donating:
(@Parsley) 0x79c5BE8f4098208006C7940cF72dAE71738b39b6
submitted by AnarchyKitty to 0xbitcoin [link] [comments]

Lore v2 QT on Raspberry Pi

To follow up to mindphuk's excellent piece on building the headless client on Raspberry Pi (, I thought if anyone was interested I'd show you how to get the full QT version running on the Pi on the Jessie with Pixel desktop. This works and has been soak tested for several days now on a standard Raspberry Pi 3. I have since added some coins and it stakes a handful of times a day.
Running staking Lore clients paves the way for some of the future use cases of BLK utilising the Bitcoin 0.12 (and newer) core tech, including colored coins. So I'm going to leave this one going indefinitely to kickstart the number of Lore clients staking. It's certainly not mandatory but it will be good in the longer term to have a nice distribution of Lore staking clients.
The cross-compile which lets you create binaries for multiple platforms didn't work for the QT version on the Pi, so there is more to do than just running the binary unfortunately, as below. There are folks working on some much cleaner solutions than this for the Pi, with a custom front end, and where you won't have to do any mucking about. That is coming soon. In the meantime, if you enjoy a fiddle with such things, here's how to get this QT client working on your Pi.
These instructions assume you are starting from scratch with a completely blank OS.
Download Jessie with Pixel from:
Note they have since (August 2017) released a version called 'Stretch' which does not work with this guide. I'll see if I can come up with something new for that at some point and link to it here when I have. In the meantime the guide should work with the Jessie image above.
Unzip the file and extract the .img file to burn it onto Fresh SD card to boot from (to be safe, use 16GB or larger), using a tool like win32diskimager or Etcher.
Assuming you have keyboard/mouse and monitor plugged into your pi, boot it up and the Jessie Desktop will show.
Before we do anything else, you should increase the default swap size on the pi, as compiling certain libraries can exhaust the RAM and get stuck otherwise. To do this, launch a Terminal window and type:
sudo nano /etc/dphys-swapfile 
and Change the CONF_SWAPSIZE from 100 to:
Exit nano with control + x to write out the file.
Then, run the following to restart the swapfile manager:
sudo /etc/init.d/dphys-swapfile stop sudo /etc/init.d/dphys-swapfile start 
Now, launch the browser and download the Lore 2.12 binaries for ARM here:!k2InxZhb!iaLhUPreA7LZqZ-Az-0StRBUshSJ82XjldPsvhGBBH4 (Version with fee fix from 6 September 2017)
(If you prefer to compile it yourself instead, it is possible by following the instructions in the original article by Mindphuk just taking into account this is the newer version of the Lore client than when that was written ( and the versions of Boost and the Berkeley DB need to be the same as below.)
Double click the zip and extract the Lore binary files. Yes, at the moment they are all called 'bitcoin', not 'blackcoin' or 'Lore' - this is because the code derives from a recent bitcoin core implementation so this has not yet been updated. You can place these wherever you like.
In the Terminal window, change directory to where you put the binaries, e.g.:
cd Downloads/lore-raspberrypi-armv7-jessie-pixel chmod +x * 
That marks the binaries as executable.
Now, we need the Boost libraries installed for any of the Lore binaries to work. The project was done with Boost 1.62.0. Unfortunately the Jessie repository only goes up to 1.55, so we need to download and build 1.62 manually on the device.
wget tar -xvzf download cd boost_1_62_0 sudo ./ sudo ./b2 install 
(This will take almost 2 hours. Have a nice cup of tea and a sit down.)
When I came to run the binaries, I found they couldn't find Boost. Running this command fixes that:
sudo ldconfig 
Now we are going to install the packages which aren't already included in the default OS installation which the binaries need in order to run:
sudo apt-get install qrencode libprotobuf-dev libevent-pthreads-2.0-5 
Now we need to install the Berkeley Database version 6.2.23. This is the version Lore v2 uses. Bitcoin still uses 4.8 which is 10 years old! This doesn't take too long.
wget tar -xvzf db-6.2.23.tar.gz cd db-6.2.23/build_unix ../dist/configure --prefix=/usr --enable-compat185 --enable-dbm --disable-static --enable-cxx 
I find this next section of the Berkeley instructions worked better just switching to root, which can be fudged by running sudo su before the rest:
sudo su make make docdir=/usshare/doc/db-6.2.23 install chown -v -R root:root /usbin/db_* /usinclude/db{,_185,_cxx}.h /uslib/libdb*.{so,la} /usshare/doc/db-6.2.23 
Now we're going to go up a couple of directories to where the binaries were:
cd ../.. 
Then run the client!
And there you have it. Should hopefully end up looking a bit like this:
Using the Bootstrap can save a while syncing. Download it at:
Place the bootstrap.dat file into the ~/.lore directory.
Run ./bitcoin-qt again, it will say 'Importing Blocks' rather than 'Synchronising with Network'. My pi sync'ed fully in about 5-6 hours.
If you want peace of mind that Lore will always start on bootup into the Jessie w/Pixel desktop (i.e. after a power cycle), then you need to create a .desktop file in the following place.
sudo nano ~/.config/autostart/Lore.desktop 
And in it, enter the following (tailoring the Exec line below to the whereabouts of your bitcoin-qt file):
[Desktop Entry] Name=Blackcoin Lore Comment=Mining without the waste Exec=/home/pi/Downloads/lore-raspberrypi-armv7-jessie-pixel/bitcoin-qt Type=Application Encoding=UTF-8 Terminal=false Categories=None; 
Power usage and payback time
After a good while leaving it going by itself, the CPU load averages got down to almost zero, all of the time. Idling, the Pi uses a bit less than 3 watts. This means it would take two weeks to use one 1Kw/h of electricity.
If you pay e.g. 12.5 cents a unit, that's what you'd expect this to cost to run in a fortnight. That's around $0.25 a month or $3 a year. Green and cheap and helping to secure the BLK network. I paid for the year's worth of electricity in 2 days staking with 25k BLK. Makes mining look silly, huh? ;)
Securing your Pi
With staking, your wallet needs to be unlocked and as such, the keys to your wallet are on the device. In a clean and newly installed environment as described above, and if you don't allow others to use your device and there is no other software or nasties running on it, there is no real cause for concern. However, there are some basic security precautions you can take.
Firstly, if you have enabled SSH and are playing with your pi across your LAN (or worse, the Internet), you should immediately change the password for the default 'pi' user (which is preconfigured to be 'raspberry'). Simply log in as normal, then type:
You'll be prompted to enter the old and the new passwords.
Security by default
Your Pi is likely, by default, to not be exposed to incoming connections from the outside world because your router is likely generating a private address range for your LAN (192.168.x.x or 10.0.x.x or 172.x.x.x) which means all incoming connections are effectively blocked at the router anyway unless you set up a 'port forward' record to allow packets arriving on certain ports to be forwarded to a specific internal IP address.
As for accessing your Pi across the internet, if you have set up a port forward, this likely has security ramifications. Even basic old fashioned protocols have proven in recent times to have uncaught flaws, so it's always advisable to lock down your device as much as possible, and even if you only plan to access the Pi over your LAN, install a firewall to configure this. I used one called ufw, because it's literally an uncomplicated firewall.
sudo apt-get install ufw sudo ufw allow from to any port 22 sudo ufw --force enable 
This allows just port 22 (SSH) to be open on the Pi to any device on my LAN's subnet (192.168.0.x). You can change the above to a single IP address if paranoid, or add several lines, if you want to lock it down to your LAN and a specific external static IP address (e.g. a VPN service you use). To find out what subnet your router uses, just type:
and you'll see on the interface you are using (either hard wired or wifi) the 192.168 or 10. or 172. prefix. Change the above rule so it matches the first two octets correctly (e.g. if you're on a 10.0. address).
You may already use VNC to access your Pi's desktop across your LAN, this uses port 5900. Add a line like above to lock it down to an internal address. It's not a good idea to expose this port to the wider world because those connections are not encrypted and potentially could be subjected to a MITM attack.
You can query the status of the firewall like this:
ufw status 
And of course, try connecting remotely once you change the rules to see what works. You should consult the official documentation for further options:
Back up & Recovery
There are again many ways to tackle this so I'll just speak about my basic precautions in this regard. Don't take it as a be-all-and-end-all!
The wallet.dat file is the key file (literally) containing all the private/public keys and transactions. This can be found in:
You can navigate there using Jessie w/Pixel's own file manager or in a terminal window (cd ~/.lore). You can copy this file or, if you'd rather keep a plain text file of all your public and private keys, use the 'dumpwallet' command in the console. In Lore, go to Help > Debug Window > Console and type 'dumpwallet myfilename' where myfilename is the file you want it to spit out with all your keys in it. This file will end up in the same place you launch bitcoin-qt from.
The instructions earlier on, when running Lore for the first time intentionally left out encrypting your wallet.dat file because in order for the wallet to stake upon startup, it needs to have a decrypted key already. This isn't perfect, but after a power cycle, it would never stake unless you left it decrypted. So the best practice here is as soon as the wallet.dat file has left your device, i.e. you copy it to a USB stick for example, put it in an encrypted folder or drive (or both).
In Windows, one way is to use Bitlocker drive encryption for the entire drive. You should follow the instructions here to encrypt your flash drive before your wallet.dat is on there, and don't forget the password!!
On the Mac, I use a software package called Concealer to encrypt files I store on the Mac itself:   There are almost certainly free packages with similar functionality, I have just used that one for years.
Either way, if you want to just make sure your USB drive is encrypted, you can do so in one-click in Finder before you put the sensitive files on it:
Note that these disk encryption methods may mean having to access the USB stick on a PC or Mac in order to retrieve the files in the event of a disaster. Be aware this may mean exposing them to more security issues if your computer is in any way compromised or someone nefarious has access to your computer. There are more 'manual' ways of backing up and recovering, such as literally writing down private/public key pairs which this guide doesn't go into, but may suit you better if paranoid about your setup.
The wallet.dat file has everything in it you need to recover your wallet, or if you used 'dumpwallet', the file you saved out has all the keys.
Wallet.dat method: Install Lore as normal then replace any auto-generated wallet.dat in ~/.lore directory with your backup. If a lot of time has elapsed and many transactions have occurred since your backup, launch lore with:
./bitcoin-qt -rescan 
And if that doesn't do the job, do a full reindex of the blockchain:
./bitcoin-qt -reindex 
If you used the dumpwallet command, install Lore then place the file containing all the keys that you saved out in the same directory as bitcoin-qt. In Lore, go to Help > Debug Window > Console and type 'importwallet myfilename' where myfilename is that file containing all the keys. The wallet should automatically rescan for transactions at that point and you should be good to go.
There are a million ways to do effective security and disaster recovery, but I hope this shows you a couple of basic precautionary ways. There are discussions about better ways to stake without compromising too much security which are happening all the time and developments in this regard will happen in time.
In the meantime, feel free to comment with your best practices.
submitted by patcrypt to blackcoin [link] [comments]

How to shutdown bitcoinxt-cli? (Ubuntu)

TL;DR: How do I shut down bitcoinxtd permanently and without having it restart?
I'm trying to switch an Ubuntu machine over to Classic from XT, using this and this as guides.
However, when I try to start Classic using sudo bitcoind --daemon I get the following message:
Bitcoin server starting [email protected]:/BitcoinClassicInstall/bitcoin-0.11.2/bin$ Error: An error occurred while setting up the RPC address port 8332 fo r listening: bind: Address already in use Error: Unable to bind to on this computer. Bitcoin Core is probably already running. Error: Failed to listen on any port. Use -listen=0 if you want this.
Okay, fair enough, BitcoinXT is already running. Let's shut it down:
sudo bitcoinxt-cli -conf=/etc/bitcoinxt/bitcoin.conf stop
And it says Bitcoin server stopping
Okay, time to enter sudo bitcoind --daemon again, but I get the same error message as the first time I entered this command.
When I check my running processes, it says that bitcoinxtd is still running, but with different Process IDs from before I stopped it.
This was the guide I used to setup the machine with XT initially.
TL;DR: How do I shut down bitcoinxtd permanently and without having it restart?
EDIT: According to
Note that the server binary is named "bitcoinxtd" in this package, not bitcoind. Since 0.11B we have added systemd init scripts to make sure that the node will be started and auto-restarted if you reboot.
The systemd bitcoinxtd.service registers the XT based daemon for autostart. Also installed is the bitcoinxt-cli executable which allows you to communicate with the running daemon.
Now I gotta figure out how to modify bitcoinxtd.service
submitted by BobsBurgers3Bitcoin to btc [link] [comments]

How to GPU mine NVIDIA on linux - ubuntu 16.04 - step by ... CPU mining on Linux(Ubuntu) operating system using ... Bitcoin Mining on Ubuntu - YouTube Autostart VirtualBox on Ubuntu 12.04 How To Set Up A Bitcoin Wallet

Intro. This guide is specific to getting LND 0.5-beta and Bitcoind running on Ubuntu 16.04 LTS for mainnet. It is ageing rapidly and includes steps not necessary on newer versions of LND @EEAA: about your question: For some people, docker is a replacement for lxc or openvz which have = 1 and vzctl set --onboot yes.Also ESXi and other virtualization solutions have such a feature included. Like Lawrence, I also don't think such an autostart feature should be implemented in a distribution-specific way because a docker user should be able to solve the same problem ... There's an upstart script for Ubuntu in the Bitcoin Core source tree. Using that is the most correct way. However, I just login as the user account I want to run Bitcoin Core daemon, start a terminal (if I'm in the GUI), and run the following command to edit my crontab: crontab -e Then I add the following line: @reboot bitcoind -daemon I'm trying to get /usr/bin/bitcoind to start on boot but without success. I have this script on /etc/init/bitcoind.conf description "bitcoind" start on filesystem stop on runlevel [!2345] oom ne... Ubuntu is the modern, open source operating system on Linux for the enterprise server, desktop, cloud, and IoT.

[index] [8779] [34406] [16763] [20528] [32117] [24075] [18562] [17177] [23849] [18155]

How to GPU mine NVIDIA on linux - ubuntu 16.04 - step by ...

there are also a lot of other places you can download a Bitcoin wallet from such as or from the wiki Bitcoin client graph page I showed you earlier in this video BitCoin mining on Ubuntu using specialized ASIC procesors and Ubuntu software such as: CGMiner, BFGMiner, EasyMiner Today we are going to compile the latest Bitcoin wallet for Windows Windows 10 has an Ubuntu 16.04 Terminal app in the Microsoft Store that we use to compile the Windows wallet You can find ... Bitcoin Mining on Ubuntu 18.10 - Bitcoin Mining Software 2019 - Duration: 24:00. Bitcoin Mining Software 2019 6,453 views. 24:00. Compiling Bitcoin Core Source Code - 2017 debian/ubuntu/linux with ... Binance - Hashflare with 63 days to break even, 1-year contract - Bitclub Network 5% re...