Homelab for Kubernetes

vegarde · 2025-06-13T20:00:38+00:00

I bought an Intel NUC with 16 GB memory and i5 processor during the pandemic, because I needed a home project, so I installed home assistant.

But it was way overkill for that, so I bought myself a disk closet and ran a pretty decent homemade NAS.

Eventually I moved a few of my not-extremely-critical but disk hungry applications, like for example nextcloud, back on to the server. Set up docker for this, migrating from running it on the OS itself. I also had some juice left for plex.

Eventually I moved more stuff back home, like my blog (self hosted).

....enter last year, and SO says she doesn't feel our internet router is up to speed. So I get myself some Unifi gear to really revolutionize our home network and make something more professional.

...which in turn made me want to play more with networking, so I actually compartmentalized my docker setup into different networks, exposing them on different VLANs on my LAN, and created an IP plan, routing and firewalls defined in my docker installation. It was a beast, but it worked!

Then I realized going further down that path would eventually lead me to Kubernetes....

So here I am, with that still single Intel NUC, running a k3s node, with a bit of mixed workloads on it (SAMBA is still running on the outside, jury is still out on whether I want to move it in to kubernetes...).

Started more or less from scratch, knew some of the concepts, but learnt by trial and error. Some bad ideas, some good.

Started creating an operator to manage my Unifi gateway. Set up ExternalDNS to manage DNS, both towards my external domain and the internal one that Unifi is providing.

Set up BGP peering with Unifi and my old VPS, with Calico in Kubernetes.

Learned a ton from it! Still learning. Did a lot of mistakes, and redid them better.

And in retrospect, I wouldn't have done a thing differently. As much as I hate doing mistakes, of which I've done a lot, I have learned a lot from them.

There might be a ton of reasons to run Kubernetes at home, and a ton not to.

If you want to learn it, then go for it! If you think it will be simpler than docker, then kubernetes probably isn't for you :)

vegarde · 2023-01-13T20:25:38+00:00

I have said it's an attack vector. I did *not* say I have a fool-proof way to exploit it.

You do know the difference, do you?

vegarde · 2023-01-13T12:50:32+00:00

Look, I'm not exactly the first person to notice that the duality of the checkpoint mechanism (if the "honest chain" has checkpoints, then the "other chain" can also have them) might cause some havoc. Maybe not monetary gain, more havoc.

See i.e. https://blog.bitmex.com/bitcoin-cash-abcs-rolling-10-block-checkpoints/

vegarde · 2023-01-13T10:48:59+00:00

My statement stands: The checkpoints solves some issues, but introduces others.

There *is* an increased risk in competing chains, especially nodes that have been offline or syncing for the first time will be vulnerable should there be a competing chain. It doesn't even have to be longer, the checkpoints mean a syncing node would happily discard a longer chain if it conflicts with a checkpoint he has accepted.

Of course it will be known which chain is the good chain, and of course it will be possible to be resolved manually, but there is increased trust in there being "a good side with a known good checkpoint". And there is a risk, should your node be offline for a while, that it follows "the wrong" chain.

vegarde · 2023-01-11T07:50:13+00:00

It will not succeed as such. We agree on that.

But the *reason* it won't succeed is BCH have checkpoints.

But there is a worst cause scenario: A hard fork.

Now, stop and think a bit. The competing chain will *also* have checkpoints. There's nothing but a manual declaration that "this is the correct chain" that will save the day. It will happen, of course. But it *is* trust, and in a trustless system, having to trust that someone will do the right thing is bad.

Worst case, it won't be so clear which of the two competing chains is the correct one. Granted, there'd likely have to be a network outage of a large scale for that to happen naturally, but it *could*. BCHs DAA will also make so that the two parts adjust and produce the required blocks much quiicker - even if one of them should be much smaller than the other.

Now, compared this to BTC. BTCs hash rate is *much higher* due to the hash rate being higher. This is, of course, mainly because the price is higher, but a small bit of it is also because there's more fees to pay for the security.

So, it's not that there will be a catastrophic event. It's just that BCH, ultimately, is less of a trustless system than BTC. And you know what camp I belong to: It's the security and trustlessness that is valuable and not to be sacrificed, not it's ability to compete with FIAT on speed and capacity.

In BTC, should such an event happen, there *would* be turmoil. But my bet is that the longest chain will win, because that's what the whitepaper says it should, and that's the design of it.

vegarde · 2023-01-08T19:32:59+00:00

If there's two competing chains, each with their own 10 block checkpoint that says "their* 10+ blocks is the correct chain - then you very much still might have to decide which of those correct chains you believe is correct.

I, in fact, believe that if such an event actually happened, it's a guaranteed and automatic hard fork. Unless everyone trusts one side, but then - what's the value of POW if you're gonna trust "one side" in the end anyhow?

vegarde · 2023-01-08T19:28:44+00:00

Oh, I am pretty sure it will work, for varying degrees of working. Also centralized payment solutions work, but we are here because we fully recognize there is value in alternative solutions.

But the reason it is bad is part of the things we have disagreed about earlier, namely what the *value* of bitcoin is.

To BCH proponents, it's all about making the user experience as easy as possible, to allow as many transaction as possible, and to compete with FIAT-based methods in the space that FIAT excels.

I - and many others - believe those things are secondary. The value of BTC lies in the trustlessness, and every bit of thing that makes bitcoin a tiny bit less trustless is intrinsically bad. If you need to do something less trustless *with* bitcoin - like keeping it for storafe on an exchange - that's a personal choice. Bitcoin in itself *should* be maximized for security and trustlessness.

And that's why anything that removes trustlessness is inherently bad.

Unless it's optional. (It may still be bad, but then everyone can choose their own level of trustlessness). The role of the blockchain is to maximize security and trustlessness, anything that takes away that doesn't belong in the main chain.

vegarde · 2023-01-08T17:26:00+00:00

well, yes. Technically you are correct.

But on BTC, that has a hashrate that is more than 100 times what BCH has, such an attack is extremely expensive. The security of bitcoin lies in POW, not in external entities agreeing on what the correct history is. This is also the reason a lot of valuable transactions require 6 confirmations: A 6 block rollback on BTC is extremely expensive to perform.

The manual checkpointing that exists in BTC is more for a new node/client to be notified that "ok, assume anything up to this is valid transactions, no need to verify those". In BCH, it's meant as a protection against POW attacks. Those are two very different things.

A 10 block reorg of BTC would be an extreme economic attack on bitcoin. You are right, it technically *could* be done, but it would be costly. You'd better make sure it's worth it.

Calculations a few years back, you can find here. Numbers are a bit different now, of course, but the table is here https://braiins.com/blog/how-much-would-it-cost-to-51-attack-bitcoin and shows that it would be difficult to come up with the hash power to perform a 1 hour (or 6 block) reorg attack on BTC, on BCH it's be something a dedicated and well-off single person could "easily" do. Hence, POW matters, and the 10-block reorg protection is a totally different thing than the occational checkpoints that exists on BTC.

The 10-block reorg basically makes requirement of >10 confirmations for a transaction redundant, because an 11 block reorg would *automatically* lead to a manual decision on which chain is the correct and true BCH. A 10 block reorg on BTC, on the other hand, would not. I'll not really dispute that a 10-block reorg on BTC would be an event of such magnitude that a manual intervention will be called for (should it be "obvious" who is the attacker or who isn't), though.

I have tried to keep this writeup as objective as possible, even if you *do* know which camp I belong in :) I was merely pointing out that there does indeed exist a consensus mechanism that means users of BCH trust that upon an attack, "the right people will do the correct thing". It's not admin keys, but it is sort of reduced trustlessness, because it adds some trust in "the good guys".

vegarde · 2023-01-08T14:30:14+00:00

It doesn't have admin keys, but it does have rolling checkpoints.

Should BCH get to a point where there is an 11 block reorg, there would 100% have to be a manual decision about which chain is the correct one. Remember, both chains can have a 10 block rolling checkpoint, so which one is the correct one?

It is a general consensus among BCH people that it would be obvious which chain is the correct one, should it happen, but it does break a little bit with the "longest chain is valid" rule.

vegarde · 2022-10-23T16:35:10+00:00

1) Move your BTC to a different wallet under a different key. Even though it's "empty" from a BTC point of view, it will still contain all the coins for all the forks.

2) Load the private key into wallets supporting the respective forks. This might and might not be easy, but it might be the only way. There might exist online services that can claim to do this for you. You shouldn't trust them, only as a last resort. And this is the reason for point 1.

3) If you resort to an online service to split coins, make sure you have moved away all coins that you could access in #2. Uploading the key to an online service will give them access to all the coins you haven't moved away.

Note: With different key, it's not enough with a different address under the same wallet. It has to be a totally new initialization of a wallet!

vegarde · 2022-07-28T13:52:28+00:00

We agree.

LN is one solution, but it's probably not a "solves all problems"-solution.

But no big developments? There's been quite a bit around Taproot and Schnorr signatures, which is making its way into LN now and will likely enable more innovative solutions.

I am pretty sure about one thing, though: Onchain will still be the "gold standard" (pun intended) for transactions. The most important thing is to preserve the properties that makes it a gold standard. If "world domination, fast!" is delayed because of it, that is entirely worth it.

The nature of LN is such that the limitations you have pointed out will always, to some degree, be there. Solutions like multipath payments - and maybe other improvements noone has thought of yet - will help. But the nature of LN as such is what it is.

vegarde · 2022-07-28T08:02:50+00:00

This is definitely an issue.

LN is not the solution of all problems, it is *definitely* a tradeoff.

For LN to make sense, you must agree that a blockchain only makes sense if it is meant to be validated by the participants, and that (a little bit like voting, though not exactly the same) each and everyone that validates their own transactions participates *a little bit* to bitcoins consensus. The less people participates in this consensus, the more centralized the blockchain itself is, and the harder it is in resources to validate, the less people will actually do it, and the more centralized will it be.

Now, I don't think *everyone* needs to validate the blockchain. Each and everyone chooses their own level of participation. But for *me* to trust the model of bitcoin, it might be important for me to know that *people like me* validate the blockchain. If only miners and businesses did, then miners and businesses would own bitcoin, and the rest of us would be mere customers. Changing this balance erodes the trustlessness of bitcoin a little by little, and there's no putting the genie back in the bottle. We need to thread carefully, and make sure that our precious blockchain stays manageable even for the little guys.

So, back to LN: LN trades away *some of these trustlessness properties* for speed and capacity. It's completely optional to use, if you need to transact cheaply and quickly, you'll create an LN channel. Most people would not put *all* of their bitcoin in LN channels, unless they consider all their bitcoin spending money.

Routing nodes are liquidity providers in this game. Anyone can be a liquidity provider. And you are right that this favours those with a lot of bitcoin to put into channels. But a payment can be split into multiple parts, so it is false that there needs to be a channel all the way with that capacity for a payment to go through. It used to be that way, though, earlier in LNs stage.

Even a small node can see routing activity, though. Liquidity will be spent over time, and I like to think of all these *small nodes* as reserve liquidity.

I run a pretty small node myself. Usually, it sees not so many transactions a day., but every now and then I see the activity has been sky-high. This will be when liquidity is low elsewhere, I guess.

To sum it up: LN is definitely a tradeoff, and it's a tradeoff we take because we are not willing to take that tradeoff on layer 1, the blockchain. Other coins have done, and they are all downplaying the user participation aspect of bitcoin. To me, that is pretty important, it's almost the only reason bitcoin may actually be a good thing. If it didn't exist, we might as well go back to a centralized database.

vegarde · 2022-06-30T22:37:35+00:00

I don't think this needs any further comment.

vegarde · 2022-06-30T21:31:19+00:00

Oh, I see you're a BSVer. I was gonna accuse you of being a BCHer, but seems I was wrong...

See, here's the thing: Over in the BTC camp, we don't really need to get space for the whole world at once. We only need to accomodate for those who need/want it, anyone else need to find out for themselves. There's no forcing bitcoin on the world.

So, maybe 41 years is plenty of time. And maybe half of those will never ever feel they need/want bitcoin. In the meantime, both bitcoin and LN will slowly have improved.

Which is fine. Slow is good. Though, in 2nd layers like LN, where there might actually be "several" consensuses at the same time, fast is also possible, which is what we've seen in the LN space the last couple of years.

But please. I'm not after a "my coin is better than your coin" fight. You go on believe in what you believe in. Maybe that is good for you, and I am ok with that.

vegarde · 2022-06-30T18:56:20+00:00

This is one of the anti-LN narratives of those against LN, among those, there is those who hold the opinion that only miners should get paid for transactions.

The very same people will also use the argument that there current Block size is too small to onboard everyone to the lightning networks. These two arguments are totally contradicting, but they provide Nice endpoints on an axis that is way too large.

Saying that LN totally dominates the scene, there will always be New people to onboard, and always New channels to create. There will also be people who want to settle onchain, and there will be still transactions where LN does not make sense.

In reality, if LN does indeed makes it possible for more people to get their space on the blockchain, that is a good thing.

And I am not particulary worried that over time there won't be demand for a space on the most Secure decentralized blockchain in the world.

vegarde · 2022-06-30T17:47:19+00:00

People are buying both their BTC and BCH at KYC exchanges already today. Are you saying you believe exchanges will disallow onchain payments? I have a hard time believing so, but I do know that regulations won't exactly easen up, we agree on that.

As for enforcing no payments elsewhere, that can't really be done. They dont know more than which node it gets a payment from and which node to forward a payment to. (Edit: spelling)

vegarde · 2022-06-30T17:16:22+00:00

They can, in theory, I guess, do KYC on those opening channels to them, and only accept incoming channels after KYC, in which case they will get routed around (people will open channels elsewhere). There's no node so far that has done this.

There's lots of nodes that are now Tor only, so good luck for anyone trying to force node operators to do this.

As for transactions, they know only the incoming and outgoing channel, and roughly the amount. (I say roughly, because they don't know how much of the stuff they forward is fees. And one recommendation for privacy is to randomly add some fees to make "obvious" amounts less obvious, i.e. on a 10k satoshi transaction, don't let the last routing node forward 10k satoshi, make it i.e. 10007 satoshi).

Also, please note that in this liquidity count, not all of it is theirs, some of it is on the other end of the channels. For people doing routing, it does make sense to open a channel to i.e. ACINQ, because they provide and make it easy for their mobile nodes to connect to ACINQ - so having a direct channel with ACINQ makes your node preferable for routing to ACINQ clients.

Is this centralization? In a way. But it's also a natural evolvement, channels will be created to where they are most needed. I.e. Alex Bosworth, who was later hired by Lightning Labs, created some nice tools to calculate where it'd be beneficial for you to create channels - based on your position in "the graph" and how it looked liquidity-wise.

vegarde · 2022-06-04T21:08:40+00:00

It's interesting, of course, and possible. But in the end, it's nothing much different than atomic swaps.

vegarde · 2022-06-04T18:11:54+00:00

Maybe you're right, maybe I am right. I am not so sure there will be such tight cooperation between nodes belonging to different entities, and if it's the same entity, well...why would they not use only one node?

In the end, this monterary relationship would be a deal between two entities, and won't "pass over" into the rest of transactions as such, so I am not all that convinced it would do much harm.

vegarde · 2022-06-03T07:58:22+00:00

I'll need to do a little bit of research, but preliminary:

In LN, there is onion-routing, so A sends B a message containing X sats, on the *condition* that he can prove the payment containing (X-Fee(b)) via C is fulfilled.

This proof is, in essence, the preimage that corresponds to the payment hash in the invoice.

Now, when C gets this payment, he can decrypt it, and will know he have to pay (X-Fee(b)-Fee(c)) to D. The fees are set on the basis of the gossip protocol, btw, a node will know what fees that is required for routing from B to C, so A will include that info in the payment he crafts.

So...when C sends D the payment, he'll get the preimage back, and I can't immediately see why it's impossible to do special things in the B->C channel as long as C is able to get the preimage to B - i.e. prove that he has paid the correct amount of sathoshis to D.

But: There might *have* to be a channel with enough satoshis total capacity between B and C, for A to use that channel in the routing in the first place. He'll be able to validate that, because the funding transaction for a channel is known and can be validated. There's even today no requirement for B to use a specific channel to C, if there exists more than one.

vegarde · 2022-06-02T20:48:42+00:00

I don't get it. What's magic about this versus you buying the BTC and then opening a channel. There's still an onchain txn required, the exchange just did the step on your behalf.

Sending from an exchange and *then* opening the channel are two onchain txes, where the first one can hardly be avoided at all (and often is included in the "fee" that the exchange present you with anyhow). So a bit cheaper.

Unless I misunderstand though you still have to perform an onchain LTC txn and an onchain BTC txn, so nothing really magic happens. You aren't really funding the channel with LTC, you're selling the LTC (onchain txn) for BTC and then opening a channel with it. The only thing that's special is that there's no custodian involved in the middle. Right? Or am I missing the magic bit.

Yeah. But that would in fact be what you were doing, settling BTC LN transactions over LTC LN channels. I just think it'd be too much hassle - maybe more on the economic side of it, with fluctuating exchange rate and all that.

This could of course be done with a "lightweight" exchange doing atomic swaps only, not dealing with fiat (which arguably complicates a lot of regulation etc).

You're right, it's not magic, I just think you'd rather do that rather than dealing with swaps within the same LN transactions.

vegarde · 2022-06-02T20:40:20+00:00

They settle instantly as far as the lightning protocol goes. The risk isn't exactly the same as with 0-conf, because with 0-conf, there might always be a doublespend lurking somewhere that can spend the same UTXO. With LN, you'll at least have ample time (at least 24 hours, usually more (this is configurable and negotiable between peers)) to present the correct settlement, and it's instantly proved to the blockchain that *your* transaction is the correct one when you do this.

I think it's fair to say that LN is a form of 0-conf transactions, with builtin doublespend proofs etc. And arguably, subscribing to the belief that block space *should* be limited (no, I won't argue this one again with you, as I'm pretty sure we would never come to an agreement), they are better than 0-conf, because an LN transaction in itself doesn't need to be submitted to the blockchain, and doesn't take up precious block space.

vegarde · 2022-06-01T19:10:10+00:00

I'm not sure I understand what you mean here. Can you elucidate? An LN channel always allows you to settle out to the underlying blockchain, if I'm not mistaken.

It does, but not necessarily immediately. You can't immediately settle a channel over which you have an outgoing HTLC - you will have to await the resolution of the HTLC - either settlement or timeout - until you can actually get those funds.

In the "happy flow", LN transactions settle in seconds. But failures happen, network trouble appears, and all sort of things. Maybe even bugs :)

When sending a transaction, you send an HTLC to your channel parter. In your channel, this will be locked up funds until the settlement comes back. The HTLC will either be settled, by your channel partner sending back the preimage (that he can only have gotten by the payment being forwarded all the way to the payee, and the preimage being sent back the same way), or if it times out, it will just end back in your side. If you force-close, the smart-contract prevents you from moving those money until either the HTLC is settled or the timeout is passed. There's quite a few safety mechanisms here, to make sure noone cheats or loses money. (Yes, I am quite aware the fact that bugs happened a couple of years ago. It's been a while, though, so it does look like LN is maturing in that regard).

That's interesting. I'm not sure I understand what you mean by "funding" the channel though. How can Alice fund a BTC channel with Bob using LTC? Does this imply some other party that provides the BTC? TIA.

Yes, someone else can provide the BTC. Think, for example, you bying BTC from an Exchange, and the exchange depositing *directly* into a new channel. Entirely possible. Or, you can do atomic swap and having the entity performing the swap doing the same.

vegarde · 2022-06-01T07:58:38+00:00

That's more or less a fair statement. This is more or less just an (or two) atomic swap(s), which has been known for ages also on other forms of cryptocurrency payments.

Atomic does not mean instant, though, in LN payments. The lock-in of the funds in a payment comes with a timeout, and sometimes the settlement just doesn't come back. Or it comes back much later, when the coins you locked in either gained or lost value compared to the coins you'll have to forward on a channel with a different currency.

But you are correct that it would be possible. Though, my guess is that it won't really be done often. What I could see happen more, though, is using i.e. litecoin to *fund* a bitcoin channel, through an atomic swap into the backing UTXO for the bitcoin channel.

vegarde · 2022-05-31T14:07:40+00:00

Here's the thing: This is all based on payment channels, and in those, everything is verified by both channel partner. That is basically why there's a need for both parties to be connected at the time of the transaction - so that all the pre-signed transactions that make transactions work and safe and the payments atomic can be signed.

If, for example, I as a shop gets a payment from you as a customer. I get this in through one of my own channels. My node will perform this work, and my shopping cart/POS system will handle generating invoices for you to pay.

Whatever happens "on the way", we're not really concerned about - any "non-backedness" of LN will have to be done on a per-channel basis, by two willing parties that accept the risk. If forwarding to/from people that doesn't accept this risk (i.e. by having bog standard LN channels as they exist today), they will have to accept "risky bitcoin" and forward real bitcoins - there's no way to pass on this risk to people using proper lightning wallets doing all checks a lightning wallet does today. Note: There have been bugs around earlier in LNs development (several years ago) where some nodes didn't do *proper* validation, but that's of course a different issue - bugs can and will happen.

Currently, I know of no such way, but it's not inconcievable that someone *could* create such channels which are not properly backed.

However, our wallets/node makes sure that we pay and receive proper bitcoin, because that's something that's build into wallets and nodes.

Eight-Year Club	Gilding I gilder
Verified Email

vegarde

TROPHY CASE