Topic: bitcoind, c-lightning and RTL on centos 7 (walktrough) (Read 587 times)
@n0nce: that looks correct to me
Just a quick sidenode in case you want to try opensuse: they have 2 versions (leap and tumbleweed). I'd recommand Leap, since it's more stable with regular releases... Tumbleweed is also using rolling releases, i personally don't like to use it for systems that should be stable.
Thanks, I'm installing Leap right now Not really OS related, but to be safe: I put my .bitcoin directory on the second hard drive of the machine.
I would then configure the service like this. It should recognise everything, correct?
Let's assume the HDD is mounted on /home/harddrive.
ExecStart=/usr/local/bin/bitcoind -daemon -conf=/home/harddrive/.bitcoin/bitcoin.conf
And I'd change bitcoin.conf like this:
datadir=/home/harddrive/.bitcoin
--snip--
Cool, good to know! Maybe I will choose openSuse just because I haven't used it at all so far
I could write down all the steps as well and post it here; as you say it'll be mostly copy-paste anyway, just small differences.
In my experience, the only differences when following writeups for other distros were always package manager and how services are created to run and restart Bitcoin / Lightning / RTL.
Cool, good to know! Maybe I will choose openSuse just because I haven't used it at all so far
I could write down all the steps as well and post it here; as you say it'll be mostly copy-paste anyway, just small differences.
In my experience, the only differences when following writeups for other distros were always package manager and how services are created to run and restart Bitcoin / Lightning / RTL.
Just a quick sidenode in case you want to try opensuse: they have 2 versions (leap and tumbleweed). I'd recommand Leap, since it's more stable with regular releases... Tumbleweed is also using rolling releases, i personally don't like to use it for systems that should be stable.
Currently, i'm usually going for either debian or openSuse. My daytime job centers around SLES, so i have a very reasonable amount of experience... If you pick either distro and run into problems: don't hesitate to post them. I cannot guarantee i'll be able to fix everything, but i'll certainly try to answer any question (unless somebody else beats me to the punch ).
Cool, good to know! Maybe I will choose openSuse just because I haven't used it at all so far ).I could write down all the steps as well and post it here; as you say it'll be mostly copy-paste anyway, just small differences.
In my experience, the only differences when following writeups for other distros were always package manager and how services are created to run and restart Bitcoin / Lightning / RTL.
Currently, i'm usually going for either debian or openSuse. My daytime job centers around SLES, so i have a very reasonable amount of experience... If you pick either distro and run into problems: don't hesitate to post them. I cannot guarantee i'll be able to fix everything, but i'll certainly try to answer any question (unless somebody else beats me to the punch ).
The next time i have some spare resources to do a complete setup, i might consider doing a complete writeup using one of those two distro's.
The diff between a walktrough for centos and debian (or opensuse) should be minimal... Basically, just the way the prereqs are installed would differ since you wouldn't use yum, but apt (debian) or zypper (suse) or rpm (suse) instead. Maybe some extra prereqs, but all in all, the way you use git, add users, compile, setup systemd services,... isn't all that different between those 3 distro's (albeit, you probably won't be able to blindly copy/paste commands if you switch distro's).
If anybody wants a walktrough for debian or opensuse and has a VPS he/she isn't using for a while that can be scratched: if you have the resources, i can writeup a walktrough... I can't personally spare the resources right now (my dedicated boxes are basically overloaded as it is), but if you have them, i'm allways willing to help out
).The next time i have some spare resources to do a complete setup, i might consider doing a complete writeup using one of those two distro's.
The diff between a walktrough for centos and debian (or opensuse) should be minimal... Basically, just the way the prereqs are installed would differ since you wouldn't use yum, but apt (debian) or zypper (suse) or rpm (suse) instead. Maybe some extra prereqs, but all in all, the way you use git, add users, compile, setup systemd services,... isn't all that different between those 3 distro's (albeit, you probably won't be able to blindly copy/paste commands if you switch distro's).
If anybody wants a walktrough for debian or opensuse and has a VPS he/she isn't using for a while that can be scratched: if you have the resources, i can writeup a walktrough... I can't personally spare the resources right now (my dedicated boxes are basically overloaded as it is), but if you have them, i'm allways willing to help out
Just wondering: Why CentOS 7? I just checked Wikipedia and it says it will be discontinued end of year? Actually, there's CentOS 8 as latest version, so even 7 would be an old version now (while still maintained).
That's not mocacinno's fault, when he wrote that walkthrough Centos 7 was still a thing with an EOL far in the future but Redhat (IBM) totally fucked this one up.
They saw Centos eating into their RHEL sales a lot and decided to move EOL for 7 and 8 forward quickly (8 EOLs end of this year). It will be replaced by Centos Stream which is unsuitable as a free replacement for RHEL in the enterprise landscape like Centos was as it seems to be a rolling version.
However the Centos community forked AlmaLinux which aims to replace Centos as free point release of the RHEL sources and so far it does a great job. Projects that build on Centos now mostly use AlmaLinux.
I would say most if not all of this walkthrough should work with AlmaLinux perfectly fine.
Maybe plain Debian with systemd. 
Just wondering: Why CentOS 7? I just checked Wikipedia and it says it will be discontinued end of year? Actually, there's CentOS 8 as latest version, so even 7 would be an old version now (while still maintained).
That's not mocacinno's fault, when he wrote that walkthrough Centos 7 was still a thing with an EOL far in the future but Redhat (IBM) totally fucked this one up.
They saw Centos eating into their RHEL sales a lot and decided to move EOL for 7 and 8 forward quickly (8 EOLs end of this year). It will be replaced by Centos Stream which is unsuitable as a free replacement for RHEL in the enterprise landscape like Centos was as it seems to be a rolling version.
However the Centos community forked AlmaLinux which aims to replace Centos as free point release of the RHEL sources and so far it does a great job. Projects that build on Centos now mostly use AlmaLinux.
I would say most if not all of this walkthrough should work with AlmaLinux perfectly fine.
@n0nce: thanks, that was it... Fixed it now
Thank you for the guide! Looks way better now I think my next setup will be based on something with systemd as well, so I will use this guide - already saw some things that seem like very good practices which I'm missing in my current setup.
Right now, I use AntiX (Debian) and while I find SysV init scripts cooler, it seems many more people use systemd and it has more abilities.
Just wondering: Why CentOS 7? I just checked Wikipedia and it says it will be discontinued end of year? Actually, there's CentOS 8 as latest version, so even 7 would be an old version now (while still maintained).
@n0nce: thanks, that was it... Fixed it now
Hey @mocacinno, I was trying some stuff with your pictures; very weird that the image proxy has issues with them. However, I noticed we can index your webserver & see the contents, not sure if intended or not, but I personally prefer to disable this in most cases:
https://mocacinno.com/hotlinkimages/
EDIT: The issue is that your URLs lack https!
Example:
Broken:
Fixed:
My guess: Your webserver had no TLS certificate in 2020 but does now
Yup, looks to me like your certificate is new since 9/8/2021!
https://mocacinno.com/hotlinkimages/
EDIT: The issue is that your URLs lack https!
Example:
Code:
[img width=200]http://www.mocacinno.com/hotlinkimages/RTL/1.png[/img]
Code:
[img width=200]https://www.mocacinno.com/hotlinkimages/RTL/1.png[/img]
Broken:
Code:
[img]http://www.mocacinno.com/hotlinkimages/RTL/1.png[/img]
[img]http://www.mocacinno.com/hotlinkimages/RTL/2.png[/img]
[img]http://www.mocacinno.com/hotlinkimages/RTL/3.png[/img]
[img]http://www.mocacinno.com/hotlinkimages/RTL/4.png[/img]
[img]http://www.mocacinno.com/hotlinkimages/RTL/5.png[/img]
Fixed:
Code:
[img]https://www.mocacinno.com/hotlinkimages/RTL/1.png[/img]
[img]https://www.mocacinno.com/hotlinkimages/RTL/2.png[/img]
[img]https://www.mocacinno.com/hotlinkimages/RTL/3.png[/img]
[img]https://www.mocacinno.com/hotlinkimages/RTL/4.png[/img]
[img]https://www.mocacinno.com/hotlinkimages/RTL/5.png[/img]
My guess: Your webserver had no TLS certificate in 2020 but does now
Yup, looks to me like your certificate is new since 9/8/2021!
Just a minor issue, all the images in your guide are broken (maybe you removed them from your hosting server or changed their names/paths?)
Thanks for notifying me... It's quite odd tbh... The images themselves are still online, but for some strange reason bitcointalk's image proxy shows an error..
For example, the very first image is
Code:
https://mocacinno.com/hotlinkimages/bitcoind/1.png
@psycodad: thanks for the feedback, it's great to hear the walktrough still works
, i wrote it over 1,5 years ago, so it's always a big guess as to how long an extensive walktrough will continue to function.I wanted to chip in into the discussion a couple of times over the last couple of days, but everytime i saw somebody else stepped in and gave a good answer to the questions that had been asked, so thanks for keeping the discussion alive guys
The whole nginx install and config is to be able to use a HTTPS certificate? I have not installed a node on a VPS, always in local networks that's why I ask, I just use the local IP.
Yes, that and you get the advantage of being able to restrict access further by ip-addresses (and more webserver config kung-fu if you like).
It's certainly not advisable but RTL can be exposed to the network in many easier ways (like a port redirector).
The whole nginx install and config is to be able to use a HTTPS certificate? I have not installed a node on a VPS, always in local networks that's why I ask, I just use the local IP.
Just a minor issue, all the images in your guide are broken (maybe you removed them from your hosting server or changed their names/paths?)
Also, you might find The Lightning Network FAQ useful. Most of the LN related discussion is held there.
Thank you for your reply, you are ofcourse right, I replied to your post in your thread:
https://bitcointalksearch.org/topic/the-lightning-network-faq-5158920.msg58004580#msg58004580
If anybody has any reading pointers on how fees work in lightning, what good settings are etc.
There are no good settings. If you open a channel between two large nodes then you will probably not route any payments unless you set your fees to zero. You have to experiment with your fee settings. I opened a large channel to Bitfinex and a small one to Nicehash. Even though my fees in that channel (Bitfinex) were high (1 sat base fee; 95 ppm), I routed quite a few payments. The largest one was ~950k satoshi and I earned ~91.5 sat in routing fees just for that single transaction. After some time I had to lower my fees since no one wanted to send their payment through that channel.
Are you familiar with the way the fees are calculated or do you need an explanation?
Also, I would be interested what the settings of "urgent", "normal", "slow" etc. mean when setting up a new channel, I guess urgent translates to high fees, but I am not sure yet.
Honestly, I would not use RTL to open and close channels. I overpaid a few times because of it. Also, you can open multiple channels in a single transaction via a command line! This way you can save a ton on money on the transaction fees.
Are people setting their fees on a per-channel basis or globally?
Most people set their fees on a per-channel basis. If you are running a small node then you will very likely change them often. There is a plugin which automatically adjusts the fees for each channel but I am not sure how well it works.
By the way, are you interested in opening a dual-funded channel at some point? It is still an experimental feature but I have successfully opened this type of channel with two other bitcointalk members. Here's my node for reference. Also, you might find The Lightning Network FAQ useful. Most of the LN related discussion is held there.
Thank you mocacinno for this excellent walk-through!
I used it to setup my own lightning node on Devuan (hating systemd and the Poettering fuckwit so much I went that extra mile) and it's supported by my VPS host.
What was impressing with the latest bitcoin core v22.0 is that synching from scratch took less than 24hrs on a pretty low-end VPS with spinning rust. Last time I synched a bitcoin node in 2014 (on much more low-end HW) it took me 2 weeks.
Overall a very exciting experience thanks to your HowTo, I greatly appreciate the time you have taken and I am very pleased with the results so far!
Now I have to go to find out how I set the fees (working with the defaults so far) and what reasonable fees are. I don't want to go full free (because what's free is not worth anything) but to set very moderate/low fees. If anybody has any reading pointers on how fees work in lightning, what good settings are etc., I would be happy to hear about that.
Also, I would be interested what the settings of "urgent", "normal", "slow" etc. mean when setting up a new channel, I guess urgent translates to high fees, but I am not sure yet.
Are people setting their fees on a per-channel basis or globally?
Again, thank you very much for the great HowTo, it gave me a great and easy start into the topic!
I used it to setup my own lightning node on Devuan (hating systemd and the Poettering fuckwit so much I went that extra mile) and it's supported by my VPS host.
What was impressing with the latest bitcoin core v22.0 is that synching from scratch took less than 24hrs on a pretty low-end VPS with spinning rust. Last time I synched a bitcoin node in 2014 (on much more low-end HW) it took me 2 weeks.
Overall a very exciting experience thanks to your HowTo, I greatly appreciate the time you have taken and I am very pleased with the results so far!
Now I have to go to find out how I set the fees (working with the defaults so far) and what reasonable fees are. I don't want to go full free (because what's free is not worth anything) but to set very moderate/low fees. If anybody has any reading pointers on how fees work in lightning, what good settings are etc., I would be happy to hear about that.
Also, I would be interested what the settings of "urgent", "normal", "slow" etc. mean when setting up a new channel, I guess urgent translates to high fees, but I am not sure yet.
Are people setting their fees on a per-channel basis or globally?
Again, thank you very much for the great HowTo, it gave me a great and easy start into the topic!
how is RTL secured? is there a password prompt when you access the site? if not - everyone who knows your domain (and port) can access your node or did i miss something?
Yes, there is a password prompt. You can also set up two-factor authentication in the settings.
how is RTL secured? is there a password prompt when you access the site? if not - everyone who knows your domain (and port) can access your node or did i miss something?
@mocacinno RAM usage is lower than i expected, i'll consider running similar setup if i have good reason to do so.
it's a supply and demand equation, but with privacy incentives distorting the supply-side. It seems more likely to me that the market will always tend toward liquidity over-supply (which is obviously better than under-supply), and so fees will frequently or always be at or lower than any "specialized" node could tolerate
In theory, I could be wrong. Because I don't believe that the people running LN nodes will continue doing so altruistically forever, not especially when it requires staking a valued commodity, and some level of specialization.
At least for merchant and exchange, they could always increase their goods/service fees or burden the fee to user.
IMO other specialized nodes will always have negative profit since,
1. LN client would use route with lowest fee or create new channel (if fees for existing routes is too high)
2. Merchant and exchange will keep routing fees low to take the advantage the fact many users (who only make few transaction) would connect to them directl
But, that reinforces the belief that the nodes in the Lightning Network will evolve to become more specialized, and routing fees becoming higher than they are now. It also takes a valuable commodity, Bitcoins, staked in channels.
why?it's a supply and demand equation, but with privacy incentives distorting the supply-side. It seems more likely to me that the market will always tend toward liquidity over-supply (which is obviously better than under-supply), and so fees will frequently or always be at or lower than any "specialized" node could tolerate
At least for merchant and exchange, they could always increase their goods/service fees or burden the fee to user.
IMO other specialized nodes will always have negative profit since,
1. LN client would use route with lowest fee or create new channel (if fees for existing routes is too high)
2. Merchant and exchange will keep routing fees low to take the advantage the fact many users (who only make few transaction) would connect to them directl
Then, another theory, regular users/hobbyists won't maintain running a Lightning node for nothing forever, and running one would converge towards large merchants, which the costs are subsidized by their businesses, IF they adopt it.
I like the other theory.
Jump to: