Topic: Lightning Network Observer - page 30. (Read 13809 times)

I think it would be interesting enough. But I don't see any movement in that direction yet...

when?.. if! LN devs ever fix the liquidity problem of routing..
.. many exchanges have played with LN and found the problems and backed off.

even el-salv 'chivo' backed off from LN and moved to a custodial exchange platform as the back-end instead of an LN hub system, they had many problems with users trying to get routes and channels along routes that could move funds without bottlenecking or close-rebalance-open to try to just pay someone

It's very good to see the altruism. Those people are ignoring the opportunity costs by locking precious capital away to help increase the capacity of the network.

When will all of the largest Bitcoin exchanges in the world accept/allow Lightning deposits/withdrawals? I believe there's only two of them, Bitfinex and Kraken? There should currently be more of them, considering that the Lightning Network started development during 2016. But shitcoins are listed before Lightning implementation.

This looks really good.  I understand the next point release will get that database reduction to be retroactive as well... awesome.

Actually in the wake of my catastrophe recently, I am seriously thinking about letting my old LND node die (though I still have 2 zombie channels I need to get closed first with quite a few sats in the balance) even though it was the older one with a really good reputation, huge traffic, BOS ranking etc.

I think I might just stick with the CL node from here... I really like how they are building better, I think.

Lightning Labs announced their latest version of Lightning implementation:



You can read the full announcement here:
Announcing lnd 0.15 beta: To Taproot and Beyond!


Micheal levine commented:



Levine added two interesting insight on the new foundation layer they area adding toward future functionalities:


Very interesting times approaching.

not in one go...
but thats the thing. when i said run scenarios on pen or spreadsheet. you can try many idea's out without risking funds.
also before i even gave idea's of paper scenarios to run. i actually did give more realistic numbers like coinbases customerbase and bitfinex channels. heck i even linked the bitfinex nodes stats.

but i guess you dont want to run tests of limitations and problems that can occur and just want to stay in the day dream of best case.

take bitcoin.. it functions. but people actually bothered to do tests on the propagation times of the network, the average confirmation times, orphan rate, software update adoption rate. to find out what its actually capable of beyond the utopian hope.

so where are lightnings real stats.. EG the payment success rate percentage based on amounts moved.. yep the more you move in one go the less chance of a successful payment/route can be established.

and again the more hops you have the more liquidity is needed along the route just to service the payment hopping through them.
EG
A [$10:$0] B [$10:$0] C [$10:$0] D [$10:$0] E [$10:$0] F
becomes (when A moves just $10
A [$0:$10] B [$0:$10] C [$0:$10] D [$0:$10] E [$0:$10] F
only $10 moved. but required $40 liquidity from B-E to move that $10 from A to F


i understand many want to be the utopian dream sale-pitch guys that want to sell the dream.. but you are also ignoring the flaws and limitations and potential problems.

so rather then making excuses to avoid running scenarios and finding the worse case stuff and the bugs/flaws issues.. how about just give the scenarios a shot and have some lightbulb moments outside the dream

the purpose of me not giving the answer/precise numbers in scenarios is some cry they dont like to be spoonfed some cry that they cant cope with large numbers in their heads. and some just avoid even thinking about it. so by using small numbers people can possibly use their brains and run scenarios, without risking real funds because yep. pen and spreadsheet costs you nothing

here you can see very nicely how the lightning network has grown by 140% in the last 365 days - currently there are almost 4000 (3940) Bitcoin in lightning

You gave me meaningless numbers.  That was easy to say, actually.

How do i know?

I have moved 10s of thousands of dollars back and forth to Bitfinex.

My numbers are real... not theoretical.

caps lock.. again with the silly utopian dream

you mention people dont need direct connections to bitfinex..
try reading my coinbase example.. i have actually shown a scenario of your counter argument before you countered

people several hops away still need to have a balance provider connected to the exchange down the route.. and if there are millions of people many hops away you have to actually count the amount of value locked in to be able to facilitate all that .. do the maths. use a spreadsheet. work it out. surprise yourself
dont stay in the utopian dream people promised you of infinite payments guaranteed, flawlessly and free.. as those promises will break. so do the maths and realise how limited LN is and how easy it can bottleneck even with just 5% value of ONE exchange

i know you are the utopian dreamer that doesnt want to hear anything bad. you want to over promote it and blame any fault on users and not the network and dig your head in the sand when it comes to the bad stuff.. .. but many people want to be risk aware so that they can actually make an educated decision

but if you want to play ignorant to the liquidity problem of routes and hops of any distance.. then actually run some scenarios and dont just stick head in the sand screaming with a muffled voice "it works"

i know you mention multiple times in one paragraph you dont need a direct channel with bitfinex..
but care to run some scenarios like i mentioned and you will see i actually mentioned scenarios where you are not a direct channel to an exchange but several hops away from them. and i said go play them scenarios out too and see how far you get before problems arise

i know certain people dont like spoonfed numbers and instead play ignorant or deny the answer if the calculations were done for them.. pretending the calculations must be wrong or the numbers must be fake.. anything to ignore the problem and deny the problem.. . so i challenged you to go find out the numbers yourself so that its not spoon fed to be ignored but a lightbulb moment for yourself to actually have come to the answers yourself and realise the ultimate answer for yourself. then you cant just say i gave you meaningless numbers

Either technical hurdles, a perceived lack of demand, or an ideological difference.

For example Coinbase has more than enough resources to add this.  But Coinbase has never really been aligned with the values that lightning serves.

Other similar organizations (such as Kraken, Bitfinex) have done it.  And even the FOSS POS system BTCPayhas added it.

Lightning payments are optimized for smaller amounts right now.  So it makes sense if you sell t-shirts or gift cards.  Or if your exchange deals in <$500 deposits/withdrawals.  If I were to want to deposit $20k on Kraken I would not do it over lightning.  But if I wanted to deposit $100 to buy some Monero?  Then of course.  Why pay for, and wait for confirmations on the base layer for a hundred bucks.  I had two channels with BitFinex.  they were HEAVILY used.  I took part in routing an enourmous amount of value back and forth with those.  But they were also only 2 million sats each so my routes were generally under $500 worth.

So I honestly think it is a combination of some technical/demand hurdles (the base chain is still relatively cheap, in part thanks to lightning) as well as the ideological difference that clearly is why CB does not do it.

EDIT - For some reason I unhid frankies response out of curiosity. He does not really get lightning. I am sure Bitfinex has locked up some bitcoin in their nodes... BUT the ydo not have to have AT ALL.  They could have stood up their nodes and not locked a single satoshi in any channels, and instead just taken incoming connections.  Then they would have 400BTC of liquidity possible on the INCOMING side.  Once people made 400BTC worth of deposits that would be, then 400BTC potential for withdrawals.  In reality the network probably does not only operate in one direction... so they would be incentivized to open channels for withdrawals from time to time.  But these channels could be reused over and over in both directions.

But they would not HAVE TO.  They could open a third node and ONLY take incoming channels (which they WOULD get) and eventually that node, too, would be providing liquidity in both directions.

Another silly mistake frank makes is assuming that to use Bitfinexes lightning nodes you would need to open a channel to them.  Absolutely incorrect.  you CAN, and there are advantages to if you are a heavy trader of smallish amounts.  But you do not need a lightning node at ALL to make lightning deposits on their system.  And if you are a node operator like many here who have well connected nodes, you would NOT need a channel with BFXx nodes to get money to them.  AAND it is unlikely even in THAT scenario that you would have to go 6 or 7 hops lol.  I think the median hop # would be something like 3.x as the bitfinex nodes are some of the most well connected on the whole network.  And this is the network ITSELF doing this as a free market.

Frankie is simply hand-waving with all kinds of worst case scenarios and clouds of meaningless numbers...  Lightning works.  It works well.  I bought my daughter something on amazon worth $1000 with a few payments via Fold...  got some fairly serious sats back for that.  And guess what?  I do not have a channel with Fold... or did not then, I may have opened one later.

the liquidity

think about it. they cant just give people funds on a whim, without pre-planning/notice.. they have to pre-arrange locking up value BEFORE people even get or spend via LN.

this means bitpay would have to lock up alot of reserves just to give outbound balance to others and receive inbound balance from others.

if they estimate they will receive 5000btc a day from 500,000 customers. they will need either
a few large hubs with channels to bitpay that total 5000btc*30(150,000btc)
or 500,000 channels direct connected to bitpay for each merchant(500,000x3.3btc channels)

just to supply bitpay with liquidity to biypay for a month

bitpay would also need to have reserves in another channel with an exchange to supply 150,000btc with their (otc exchange) partners so that the partner can convert that coin to fiat for bitpay to offer the fiat withdrawals to merchants that want to cash out

heres how it would look if the merchants linked to a large hub that then linked to bitpay
              small
             amounts
              each
merchants \                 large        large
merchants \\              amounts   amounts
merchants --- large hub  -- bitpay  -- otc fiatswap partner
merchants //             regular session closing to get coin out
merchants /

..
take bitfinex..
just to be able to offer bitfinex customers a way to withdraw bitfinex balance to LN, bitfinex has had to lock up 10% of the entire LN network "capacity" just to be able to be ready to have LN balance if people wanted (in the future) to get routed some msats from bitfinex
(sidenote bitfinex luckily doesnt have millions of customers all wanting LN withdrawals. luckily for them only 0.00x% of there customers(under 1000 channels) want to give LN a shot. so bitfinex only has to lock up ~400btc)
time of posting - https://i.imgur.com/oagW6Z2.png
https://1ml.com/node/033d8656219478701227199cbd6f670335c8d408a92ae88b962c49d4dc0e83e025

but imagine a service that processes more. . more needs to be locked up to facilitate that processing before the processing can even happen

research liquidity bottlenecks.. and allocating reserves.. and think of the issues where lots of customers are all directing flow towards central points or central points are directing flows outbound to lots of decentralised points..
the liquidity required nearer the central point becomes the points of failure
yea also research central points of failure

el salvador learned this quickly in the last few months of 2021 and changed from the LN hub/liquidity model. and instead used a CEX exchange to be custodians of userbalance of btc to do internal database balance swaps inside alphapoint. rather than have the liquidity issues of LN where hubs run out alot.

..
everyone reading this could and should run some scenarios of not just best case scenario.. but worse case scenario too (dont just live the utopian dream)

you dont even need to use LN to run worse case scenarios. you can play out scenarios with a pen or a spreadsheet.

..
heres some scenarios..
coinbase has ~100million users. imagine just 5% wanted to convert their fiat deposits into btc and then withdraw via LN msat.. lets say each customer was only depositing $5000 a month(converts to ~0.25btc) each

before playing scenarios of how coinbase arranges channels/routes.. coinbase has to lock up and set aside 1.25million BTC in reserve. thats 1.25m btc it cant have on the exchange market order books as it has to be separated and locked up a month before..

next coinbase would have to manage either 5million channels of directly connected users LN channels. or have a large hub partner that it has a 1.25m btc lock with. where that hub then has the customers linked to.
meaning that hub also needs extra reserves of its own on its end to supply the customers.
so thats 2.5m btc locked up just to facilitate payments of upto 1.25m btc converted balance of msats

imagine all customers were not 1 hopor 2 hops but 3 hops..
even more btc would need to be locked up just to facilitate each hops liquidity to pass it on. now thats 3.75m btc locked up just to facilitye all customers withdrawals 3 hops away where total payments cn only be 1.25m liquidity before bottleneck

..
so go have fun use a pen or a spreadsheet and play out some scenarios. realise how much liquidity needs to be locked up to facilitate payments.

---

(unrelated to the question asked in quote above.. but worth people actually thinking about in the case of the wider utility of LN and issues)

heres some other scenarios to think about

 even if there are only 5% of just coinbase customers of just 1.25m btc on coinbase balance leaving coinbase to customers via LN..
guess how many hops the customers cant be further than before all 19mill btc needs to be locked up to facilitate hop routing to just those customers 1.25m btc locks of msat..
(i wont give final answer. but i will give some hinty examples of things to think about)

remember this physical world problem(the 21m supply cap(19m available circulation) of btc)

ill make it easy for you for a easy hint using small numbers
if 3 customers of just 0.1 each wanted to pay someone 7 hops away
0.1\
0.1- H1(0.3)- H2(0.3)- H3(0.3)- H4(0.3)- H5(0.3)- H6(0.3)- H7
0.1/
requires (to facilitate just 3x 0.1).. a complete lock up of 2.1btc (7x lockup to facilitate a 1x payment)

note the problem .. more btc needs to be locked up to facilitate less coin actually moving..
note the problem when 4million customers of 1btc want to pay someone just 7 hops away

(4m)- H1(4m)- H2(4m)- H3(4m)- H4(4m)- H5(4m)- H6(4m)- H7
28m btc needs to be locked up to facilitate 4m of payments.. um.. yea see the problem

..
now work out how many hops people cant be distanced away from destination/source of a payment, before the 1.25m coins of the coinbase example of just 5% of customers end up causing liquidity issues and bottlenecks and not enough coin in the entire blockchain to facilitate payments of just 1.25m coins

What's stopping traditional payment processors like Poof https://www.poof.io/, Bitpay https://bitpay.com/, or Coinbase Commerce https://www.coinbase.com from adopting Lightning Network?

LN has no consensus, when it sends onion payments telling other nodes to pay other nodes X msat.. that those Msat must always be equal to /1000 to represent sats at the other end where the wallets of the 2 destined partners channel must convert the msat amount of an onion into a sat amount of a commitment..
yep a deceptive wallet could autopilot a commitment to convert to only / 100 but blindly accepted the routed payment thinking it was getting 10x more..

just be risk aware of what can happen in a network of user nodes/litewallets (especially lite wallets are more at risk) that has no consensus and where most users dont review code or look at raw payment/tx data. they just blindly accept what they see on the GUI and realise after the fact that they have been deceived

be honest now..
can any LN user TRULY and honestly tell me that everytime they see that they have received Xmsat on the gui. that they have been able to truly easily or at all possible been able to find the real raw subsequent commitment update and checked that it translated into the exact sat amount they suppose to get.. or are they blindly trusting the wallet and just think the wallet is unbreakable and full proof

In the post right above yours cAPSLOCK describes how he successfully recovered 2/2 badly backed up / cared for Lightning nodes and restored all the funds after days of those nodes being disconnected from the network. Doesn't look too dicy for me. The benefits? Daily transactions of any size, with good privacy, without having to bother with coin control. Small fees, instant transfers. It's a pretty cool system.

---

Well, what's the point of using wrapped Bitcoin on Ethereum if ETH fees are higher than Bitcoin? Maybe faster block time. But the general issue of pegged / wrapped is that this peg can always disappear. The 'wrap' is just a promise, an IOU. You don't actually own and use Bitcoin if you use those. If I have 1wBTC and want to pay someone in Bitcoin, I can't. Because I just have an IOU which has the value of 1BTC; not a real Bitcoin.

What is the argument for Lightning when people can use decentralized networks with integrated, pegged or wrapped Bitcoin on chains like like ICP and Ethereum?

Yep.  The SSD failed.  First drive of this type I had go tits up on me.  Ah well.  I am actually going to replace it with a teeny little raid setup to solve that problem...  But I wonder if that will mean my house is destined to burn down?

https://www.newegg.com/startech-s352bu313r-enclosure/p/N82E16817707429


I ran a node on testnet too... I ended up (recklessly) graduating to main net with the node I created... OK this is embarrasing but I will tell you the story.  It is one of the most convoluted things I have ever done.  And I generally try to keep things simple.

I built the node as a a docker container.  First thing I had ever done with docker.  And I ran it on this NAS device I originally bought to backup my family's files and be a sort of TV server.  I have NO IDEA why I thought this was a good idea.  Maybe I was drunk.  But I ran it for a LONG time before finally retiring it.  I still have those seed words.  Because I am unable to delete.  I suppose I am a bit of a hoarder.

This was one of the reasons I had problems with this recovery.  The backup files I have with all the seeds have EVERY SEED I have used along the way...  And nothing is well marked.  Well after THIS ordeal I have recreated the file and included ONLY the two keys I need.

Live and learn...


Oh and one other thing...  This is for FRANKIE.  Sadly I will not see any responces as he is ignored. Lol.

All my errors, and poor backup hygiene?  And yet this well made software made it possible for me to recover everything.  A non trivial amount of money really. ALL OF IT back under my control.   Both major implementations have advantages.  CL has a better backup system (if it works) but LND is more foolproof.

I think they would do well to both use the same basic approach...  LND should add a live database backup (as well as a plugin system IMHO and while we are at it why not consider making the plugins cross compatible?) , and CL should add the ability to store Static Channel Backups.  Two different strategies that will make both nodes pretty damn bulletproof.

That's a good point; yes. I don't think you can name tag channels, but you can name tag nodes and I'd advice against that. Otherwise I could find your node by your username and see who you have channels with and now much balance is in there. It would still be extremely hard to find out when, to whom and how much you transact in those channels, but the information that is easy to gather may already be too much for many people's privacy standards.

The issue wasn't switching it off, but not having / not being certain about your backups. Compare it to someone running Bitcoin Core and not having backed up their private keys. Do you blame Bitcoin Core for that? Let's go a step further: Bitcoin Core has no easy to write down seed phrase backups; would you blame it on Bitcoin Core if someone lost their funds due to a hardware failure of their Core node?

That's correct; but keep in mind this was about a hardware failure.
Also keep in mind, nobody ever claimed Lightning to be 'as good' in everything as Bitcoin Core. You do have some tradeoffs (e.g. in caution / backups / ..), for the benefits you get (speed, costs). It kind of makes sense; you gain some, lose some. You can't have everything..

Not a flaw; a design necessary to achieve the goals an off-chain system wants to achieve. And this point can be relativized; if you know you're going to turn your node off for extended periods of time often, you can set a longer lock time and reduce this risk by 99.9999%.

It's good that people know the 'cons', nothing against that - in fact, I continued the conversation with cAPSLOCK about his node restoring troubles for a whole page or more; giving this issue visibility. Just stick to the facts and don't overblow the 'downsides' on Lightning while ignoring the same 'downsides' (e.g. needing a backup) in Bitcoin Core.

I never propagated that; it's just what I heard you say in the past (that blocks should be larger). What else do you propose? You just vaguely mention 'many ways', but don't say which ones they are. If they exist and are viable, why don't you write a thread about all of these great ways, with their upsides and downsides where we can discuss them and maybe write a PoC for Bitcoin Core or whatever other software? Just saying 'they exist' doesn't help anyone because these ideas won't come to fruition if you don't elaborate on them.

Oh that sounds very misogynous. Maybe you haven't, but I've known a lot of great women; older and younger ones, great minds, no 'drone followers' at all. I've definitely known tons of men being like that, though. Just type in 'Elon Musk' on Twitter search and look at thousands if not millions of middle-aged men following that guy like a god, eating up every word he says as if it's absolute truth. If that's not a drone-follower, I don't know what is.

---

---

---

I'll definitely refer people to you if they have such issues in the future..

This sounds awesome! I do have a node with @Rath (@'ing him apparently notifies him, as his profile states), and it regularly goes offline for a bit; I guess his internet connection isn't great. I just checked and right now it's actually online.

Interesting; so using the hsm_secret file gave a wrong pubkey, but using the seed words resulted in the right one? Difference in amount of channels connecting or not connecting after pubkey change might be implementation-specific (either some running outdated versions or running LND vs CLN).

I've never heard of hsm_secret encrypting the channel backups; in my memory it's just the secret / entropy (basically for anything on-chain).

My bet would be on outdated nodes and / or LND vs CLN difference. But yes, it should probably set off red lights if someone switches their public key, I guess..

Did the SSD spontaneously die? Usually I'd advise for whole system / drive backups, but in case of Lightning, using the backup plugin (or what's now built-in) makes more sense, since it initiates a backup every time there's a channel-state update, which is what matters most. If your latest backup doesn't include one channel's latest update, you can get into trouble.

Thanks for all the updates! Gave great insights; I only had such issues and failures / no backup, etc. in Lightning's 'reckless' phase and on Testnet which is multiple years back now, so memory gets a bit blurry. It's refreshing to see how the current state of Lightning is when it comes to failures and backup restore process.

maybe if you lot stop blaming yourself for the faults and pretending lightning is your jesus and saviour you might escape your philosophy of adoring a broken network

if LN is not working for you.. maybe wake up to the fact that its not working for you.. rather then blaming yourselves.
LN is code. it has no feelings you cant hurt it by calling out its flaws.

stop pretending its some utopian magic entity that will save you

[rhetorical question]
why do you all fear calling out its faults and flaws?.. im guessing its nepotism
(staying friendly with a little clique group of people, hoping to get a job out of it by sucking up to the boss)

thats my lightning network observation..

my other lightning network observation which no one talks about or wants to warn people of
when people first get into LN or want to fund LN
first they need to move funds into their LN node. (before making a channel).
and then when finding a partner to make the channels, it is requiring another blockchain move between a node created key and a channel created key(multisig)
thats 2tx's just to set up.. atleast(could be more if your seting up many channels on different days)
then when closing session of a channel. the node is not asking for a key from a bitcoin core/proper bitcoin wallet address. but the key created by a LN nodes. by which the node would prefer you to then send funds back into a new channel.

to actually pay some random person outside of LN. usually requires actually making a second move out..
because trying to put a non LN node/channel derived key as an output inside a channel, many LN node software dont like, because you cant make the revoke or reveal the revokes of such if using a native bitcoin address.

yep most LN software prefer only multisigs/addresses derived from a seed made from the keys of the channel/node to be used as outputs because thats the parts of the channel rules when the partner checks that the balance and who deserves what is done. because they want to ensure that the next 'state' will be able to reveal a revoke of the current signed state should the sessions continue

.. in short. getting in and out of LN usually costs 2 transaction atleast to get in and 2 transactions atleast to get out

but hey. thats the thing. they want you to jump in without all the info.. and once you are in. then realise the cost to get out. and then instead of getting out. find a way to stay in with as least cost as you can. until you have spent all your funds within LN and just leave with nothing left

Discussions with that Franky1 guy never head anywhere. later you will ignore him, because he has nothing to add to this and many other topics. He must be a very lonely guy.

OK.  That's about enough of that.  I am fine with discussing what is negative about lightning.  Really.  But this asshole just rants and rants... but that last bit?  I think he might be a little off in the old think-bone.

I do not have all that many ignores on this site.  But I just added one new one.  I take some pride of being tolerant of all kinds of folks.  But that level of nonsense?  Don't have time for it.

Now... On to my topic of node recovery, which I appreciate you all listening to, and honestly I hope that MAYBE it would be useful to someone else.  I CERTAINLY would be a decent resource at this point for helping someone go through this ordeal with either LND or CL!  If someone is reading this and needs help, ping me.

CL node:
The CL node is back up, and running.  As if nothing happend, I think.  It is only missing 3 channels . Well two really since the third is my LND node. Lol.  That channel will not be coming back up.  The other two are "benthecarman" and "Rath [keysend]".  The latter is a forum member and posts in this thread.  Is your node just down?  The first one?  I dunno.  Anyone else have an active channel with him?

OK here is the freaky part of the whole thing.  I ran through all the restoration process, including decrypting/restoring the backup database.  When the node came back up about half the channels were connecting, but the other half were not.  Something seemed wrong.  When I went to look at the info for the node IT HAD THE WRONG PUBKEY!  Umm...  huh?  so I recreated the hsm_secret from the seed words (I had used one in a "rescue backup" originally).  After bouncing lightningd not only did I have the RIGHT pubkey, but most of the other channels connected right away.

This seems very lucky to me.  And I do not entirely understand what happened there.  I think it's safe to assume the pubkey in my backup file was the wrong one.  Totally possible. I was worried about this when I was restoring.  I think I went through the setup for the node a couple times, and I bet that as the first time. 

But how did the channel backup get restored?  I guess that the assumption that the hsm_secret has something to do with decrypting that is not the case?

And HOW ON EARTH did some of my channels come back up?!??!?  That part seems crazy.  And I feel lucky not to have set off alarms on my channel partners node.  The whole investigation was prompted by the fact that half my partner nodes were REFUSING connection. 

LND node

This node is in the process of rescanning the blockchain. 

Seems it is a slow process.  I see transactions up to 3/20 so as far as the LND node is concerned COVID has barely started.   No channels are connected, and that is as expected.  I am assuming that after the blockchain is scanned all the way through the channel closing procedure will continue.  I am hopeful I will get all my bitcoin back.  This is a place where the low power SBC is a disadvantage... I think it has plenty of ability to keep up with the blockchain in real time. But rescanning this is going VERY slowly.

To be honest... both of these systems are more foolproof than I had thought.  I am definitely the fool here.  I mean it was nice from frankie to try to shift the blame over the lightning, but nah.  There are two things at fault here. A shitty SDD failure, and my lack of good preparation.  I am not being self effacing. I am a wizard of hackery, and I have done things that most folks would be screwed trying to do...  like figuring out the CL pubkey was wrong and fixing it manually.  BUT my lack of being serious about preparing the right backup strategies for the node was an abomination.  And kudos to each implementation AND Raspiblitz.

I will be making a donation to the Raspiblitz project.  For sure.

Anyway, thanks, all for the audience.  I will quiet down about this now.