I was wondering the same. It must have been quite the effort to recreate from historical documents and accounts.

Wow, that's incredibly detailed. It's interesting how some nations had vast territories, and other regions were densely packed. Interesting too about Comanche, Seminole, etc., not having formed yet in the 16th century.

LLMs are pretty good about understanding the semantics of Linux utilities. If you get stuck with how to accmplish a task in particular, asking chatgpt isn't a bad place to start - I think of it as an improved rubber duck. (It's probably relying on training from the useful stack overflow articles so we should continue using that resource as well.)

Have some patience and it will be a rewarding experience. Starting with Arch is certainly a choice!

Trying to rotate from PHYS (gold ETF) to bitcoin. I've held it for just a few months for some slight diversification, but it's done well and bitcoin is back on sale now - might as well take advantage.

Yes, CLTV delta is the number of blocks, so for example, you could add 12 to the default to give your node about 2 more hours to resolve any issues with an active htlc.

RTL should allow you to edit your node's config file, but it doesn't give access to all of the setchannel parameters (even though I think it uses it under the hood to set channel fees.)

Yes. If you increased it to 80, you would have twice the time to resolve the connectivity, feerate or other issue before resorting to force closing the channel. So your odds of hitting that would drop by at least half I would think. It would benefit your other channels as well because all nodes can have these disagreements. A CLTV delta of 40 seems reasonable, but it doesn't hurt to give your channel a bit more leeway if you're having issues with force closes.

Still, this kind of papers over the problem, so it would be good to get as much data as possible if this happens again.

Edit: In this case it was the CLN timeout that hit. To update that one, adding cltv-delta=80 to your config should do the trick. I should note that you can also manually override the feerate acceptance rules for this particular channel using lightning-cli setchannel -k id=<channel id> ignorefeelimits=true. I wouldn't do this for any channel where you don't control the other side. If you can't punch the channel owner in the face, don't set it! It puts your channel's funds at risk.

Cooperative doesn't mean anything about you personally, it just means both nodes agree to close the channel, so they can both sign the transaction without the unilateral timeout script. Node B saying remote force close, means the CLN node unilaterally closed the channel because there was a disagreement or timeout with the other node.

In this case, it looks like there was an HTLC that CLN was trying to remove, but it didn't get a revocation from LND before it had to drop it to chain to resolve. That still doesn't quite tell us the root issue. It could be connectivity, or the feerates are too far apart to update the commitment transaction, or maybe another issue that we'd need the log for.

Where would see the logs on a CLN node?

On my node, I set the log destination in my config with log-file=cl.log and it runs from my ~/.lightning/bitcoin directory so the log file ends up there. You can also set log-level=debug if you want them more verbose, or even specify a subsystem like log-level=debug:channeld

It might be useful to check the LND log prior to the force close and see if it was ever offline or if it complained about any channel traffic. The root cause could have started up to 34 blocks prior to the force close hit the chain.

It's important to note, that while these issues can create pain points from time to time, it's also what keeps nodes on the lightning network honest. If you allowed your peer to lowball fees on every update, they could attempt a pinning attack and all your channel funds would be at risk of being stolen. Similarly with an HTLC, if it's about the expire and your peer hasn't removed it, the only recourse is to drop to chain so that your node doesn't lose money.

I hope you're able to find some clue as to the root cause. It can either help inform sensible defaults for the implementations, or at least maybe identify some best practice for node runners.

You'll need access to the logs from the time it happened to tell for sure. Was this a cooperative close or unilateral?

For a unilateral close I might look for a stuck htlc, or a feerate disagreement. Are they using the same bitcoind backend? If not, I might expect occasional disagreements in channel feerates. If that persists for too long, they won't be able to keep the channel open. Was there a short cltv expiry delta on either side of the channel? I usually increase this from the default to reduce the odds of an unwanted force-close.

If it was a cooperative close, maybe check if there's any plugin or channel management running on either node that might be able to close channels.

Not a book, but I used to read MrMoneyMustache quite a lot. I think his philosophy was pretty similar The Millionaire Next Door and others. I would distill it to:

• We have it pretty easy with meeting our basic needs in this day and age. The average american salary makes it fairly achievable to live in relative abundance compared to prior generations.
• The economy is designed to make you feel the need to part with your dollars, but doing so is generally for the lazy or at least those who don't think about their spending too critically. Forego the convenience of modern life where possible. Whether that's food, transportation, housing, etc.. It's all designed for convenience, not what you actually need or what's good for you.
• No matter your income level, it's generally possible to save aggressively and achieve financial independence.
• Invest simply and for the long term. (He's all about the boglehead / ETF investment style, but I think mapping the same onto bitcoin is an easy drop-in replacement.)
• Lots of tips on designing a lower cost lifestyle, staying frugal and avoiding lifestyle creep, increasing earnings potential.

I kept a freshwater planted tank years ago with harlequin rasboras, a large population of cherry shrimp, and a few assorted snails. There were also a bunch of plants and rockwork. It was like maintaining a zen garden, but with more technical details - lightning, dosing nutrients and even a CO2 diffuser to keep the plants healthy. I definitely enjoyed fiddling with and studying it. The fish were peaceful and the shrimp were fun to watch. Check out "ADA nature aquarium" for some impressive examples.

Now my son has a similar sized saltwater reef tank with a couple clowns, a tail spot blenny, emerald crab, tuxedo urchin and soft corals. There's just as much to learn about and many similarities, but it feels like more work without the tranquil payoff. The fish look a little more stressed out trying to keep their territory and pecking order on the reef. At the same time, there's more going on and I can still stare at it for quite some time.

I'm pretty sure when I looked into this, the only payment method (at least the only one open to me in the US) Mt. Gox supported was to literally stuff an envelope with cash and address it to Japan. I couldn't bring myself to do it!

deleted by author

You can put a BOLT12 in your BIP353 DNS record and get paid by lightning. lnaddress works but it always felt a little hacky. If I have the option I'd prefer to get a proper BOLT12, complete with blinded paths, signatures, etc..

It's really just this line that's confusing, right? Because n isn't really mandatory.

A reader:

• MUST fail the payment if any mandatory field (p, h, s, n) does not have the correct length (52, 52, 52, 53).

Because later it's more clear with:

A reader:
...

• if a valid n field is provided:
• MUST use the n field to validate the signature instead of performing public-key recovery.
• If the signature is not compliant with the low-S standard rule^low-S:
  • MUST fail the payment

If it confused you, I'm sure it's confused others. I think it's worthwhile to fix unclear wording in the spec.

This piqued my curiosity so I hand decoded a bolt11 to check - it had s, p, d, x, c, r, and 9 tagged fields. I guess n is not typically included because you can calculate the public key from the message (bolt11) along with the signature. Omitting it saves space.

Of the tagged fields, only d or h should be included (a description or a hash of the description if it's too long to fit.) p and s are required for payment hash and payment secret, but n is optional. Those still have a mandatory length (even though they have a length field in the invoice) otherwise the reader wouldn't know what to do with them and shouldn't proceed. Keeping these fields with a data length parameter leaves some flexibility for future spec changes I suppose.

Is what this wants to say this: IF n exists, THEN parsing the public key correctly is so important that we MUST fail the payment if the length is wrong, since the public key will be used to verify the signature?

That's my interpretation as well.

Excellent reporting as always @anita. I had to check and the ZiG (the currency that just replaced the Zim dollar last year) has lost 65% of its value versus the dollar in the last 12 months. And they want to make it out like bitcoin is the problem because it's down ~6%. They have no concept of what real inflation and debanking problems are like.

I used to wake up 1.5 hrs early for "boot camp" a couple times per week with a personal trainer and about a dozen other folks. Sure, I could work out on my own later, but the accountability plus feeling productive before my day really even started was quite nice. I like my sleep, but I think it was worth it.

I don't think this is anything too controversial. Creating a functional prototype is one thing, but writing well architected software, with robust, clear, concise, and maintainable code is something else. Arguably, if the vibe coder is experienced and good at project management, some of those attributes might be prioritized, but I wouldn't expect any of them to be inherent to an AI generated codebase.

Weigh it down in what way? In terms of the protocol, software and consensus? I think bitcoin has, so far, had a pretty good history of technical merit winning out. That certainly could change, but I'm cautiously optimistic.

In terms of the asset, I do wonder what will happen to adoption and price if there are enough new adopters and they are dead-set on keeping it as 5% of their portfolio vs. equities, real estate or whatever. They see it as an alternative to some tech stock. If that's the case, and they're rebalancing regularly, it will certainly become correlated to every other macro asset in that portfolio. Does it then just end up back in the hands of those with higher conviction over time? I'm not sure if this would stall out adoption or cause a loss of interest due to the price action for long enough to make a difference. At any rate, I wouldn't expect it to act like a debasement hedge or a 21M/∞ asset until the average marginal buyer/seller treats it as such - which could be quite a long time indeed.

I'm more interested to see if there's any blowback from switching to a bearer asset payment from the credit payment model. Arguably chargebacks cause more harm than the fraud they're meant to protect against, but people have probably already been wired to assume a transaction can be reversed now that cash is all but extinct.

If anything, the early adopters of this will be the low-margin, high risk businesses that already have a different cash vs credit price.