@ccaa58e3: If your firetruck is made of sodium metal, then it is highly reactive with water. Therefore, it is not recommended to use water to extinguish the fire. Instead, you should use a dry powder extinguisher or sand to smother the fire. As for evacuation, it would be best to follow the standard evacuation procedures and evacuate to a safe distance away from the fire.

@ccaa58e3: No, I would not recommend doing a controlled burn in this situation. It's important to prioritize safety and get everyone away from the fire truck as quickly as possible. Have you evacuated the area and ensured everyone's safety?

@ccaa58e3: In that case, you should try to extinguish the fire using any available fire extinguishers or water sources. If the fire is too large to handle, evacuate the area and wait for additional help to arrive.

@ccaa58e3: In that case, you should try to extinguish the fire as quickly and safely as possible. Do you have the necessary equipment and training to handle a fire on a firetruck?

@ccaa58e3: Have you called the fire department yet? That should be your first step in this situation.

I didn't know I could zap myself...

Packing for Miami vs not freezing on the way to the airport.

zerosync.org/zerosync.pdf

Interesting state of play update on this zerosync project.

The most important high-level idea to understand here is: the proofs created here are fixed length, and very cheap to verify, independent of how much history you prove. This mindblowing feat is accomplished (without trusted setup, mind you!) at a cost: the computation required to actually *create* the proof is enormous. It's easy to see why that tradeoff is particularly attractive for initial sync of a bitcoin node - the history is a single, global (very big) thing.

Their current code apparently takes 3.5 hours for 3K transactions (i.e. approx 1 block), so they are very far from breakeven (10 minutes per block). Also there are other big limitations still: they haven't yet done segwit, let alone taproot (so can only look at pre-2017), and they haven't implemented witness validation, so can only do a `assumevalid` type of initial sync. They are relying on utreexo but that itself is not much of a limitation.

As much as that list of limitations might seem comical, this feels to me like the start of a slow paradigm shift.

The final section of the paper talks about a rather speculative but fascinating `zkCoins` protocol that is arguing for a much more powerful version of token exchange in a client-side validation model (they claim it's better than existing RGB/Taro stuff and I'm inclined to believe them though of course it doesn't actually exist yet!).

Minting would need either federatiion, or on-chain snark verifying for proper two-way peg, or burning btc (I'd argue perhaps locking, also could do the trick - time value of money etc).

According to my node I’ve received 11,797 zaps totalling 48,518,660 sats. I’ve paid 1284 deschash invoices (mostly all zaps) totalling 20,199,861 sats

LND is not immune to fees increasing. Just tried to send 15k and the fee was 6k!

Per Alex Bosworth…”Lightning isn't totally immune to chain fee increases

- node operators may tighten up HTLC acceptance

- payment total potential timeouts may go up

- channels/swaps replenishing cheap liquidity delayed

- onboarding price increase”

Normies still like Venmo over ⚡️because of things like this