You're right being sarcastic:

Nope, they didn't have 620'000 BTCs (more like 50'000 BTC, mentionned elsewhere in the discussions).

They didn't make actual transaction on the blockchain giving out 620'000 to some random bitcoin account.

They just accidentally wrote +620'000 BTC in the database that manages the exchange (which tracks the internal state of who is selling how much to whom).
So suddenly some user was supposed to be in possession of 620'000 BTCs on the exchange according to the web interface, even if the exchange never saw the number of BTCs it holds according to the blockchain ledger go magically up by that number.

That's merely a big number in some database.

Because this thing is not technically on the blockchain.

The transactions happening on the blockchain are between your own self-managed wallet and the exchange's infrastructure.
(A banking metaphor: Think you getting cash from your pocket and inserting it in the ATM input slot)

The transactions on the exchange are just internal number keeping by the exchange's software stack to keep track of who has how much and oews how much to whom.
(A banking metaphor: when you send money between accounts, e.g., when you use e-banking to pay somebody at the same bank, there is nobody moving actual wads of dollar bills and coins between vault, instead the bank just updates some numbers in their database and now they know you have less and somebody else has more)

Now this is where the banking metaphor breaks: actual real-world banks are extremely regulated and have to pass some high standard to still be licensed as bank, and because of that great effort are put making sure that the database is coherent, that the numbers corresponds to what is metaphorically in their vault.
Nobody would just get magically "+40 billion bucks" on their account due to a mistake.

Meanwhile I wouldn't be surprise if some of the code involved here was vibe coded.
What happened is the exchange did by mistake write "+620'000 BTC" in their database even if they never controlled that much in their actual wallet/there was never that much BTCs according to the blockchain ledger.

(emphasis mine).

So some people decided to be clever and run away as fast as possible with the money (have it transfered out of the exchange).
Except that even if the exchange's database says these users "possess" 620'000 BTCs, the exchange only actually has 50'000 BTCs according to the ledger, so this has very likely set off some warning of dubious or impossibly high sum being requested for withdrawal, leading the exchange to freeze everything before their actual 50'000 being fleeced.

Yes, but for how long? That's the problem.
If the current trends of rising prices of core component keep up (i.e.: unless the AI bubble bursts already), EVERY newly built machine is going to be expensive.

But out there in the real world: coolers are probably the most often modded thing on graphic cards, so...

...so yeah: replacing the cooler with something more fitting for a workstation tower or a compact gaming case is probably going to be extremely common.

At worst, just some new 3D-printed shroud with a couple of Noctuas on it would probably work in a pinch,
but you can bet that AliExpress is going to be filled with cheap custom coolers for the 2-3 different most common PCIe GPU boards found in data centers.

(And of course, the shops that are likely to perform GPU transplants onto new PCIe carrier board will obviously slap some adequate cooler on it).

The latest crop of server indeed use LPDDR5X which is indeed incompatible with DDR5 DIMMs and SODIMMs (it's not possible to de-solder the LPDDRs off recycled mainboard and re-solder them on new DDR carriers PCB and plug those into conventional motherboards' DIMM slots).
So yeah, you won't see the market flooded with rebuilt DIMM and SODIMM sticks.

BUT it's a format used (soldered) also by SBC, mobile devices (tablets and smartphones), and some laptops.

So if the hardware is cleared "for pennies on the dollar" from Datacenters, it means that you could see on the market a flood of Raspberry Pi clones, Android devices, gaming consoles, and ultra-thin notebooks that have 32GB or 64GB of (re-) soldered RAM and still cost cheap.

--

The latest crop of GPU in those servers use HBM3. Yes, this is completely different from GDDR7 used on gamer hardware (it's PoP on top of the GPU itself instead of being soldered nearby on the card)... but these GPUs are perfectly functional for gaming, they just have a much *H*igher *B*andwith to the memory.

At minimum it should be possible to keep the PCIe accelerator board as is, as long as you plug them into a motherboard with on-board graphics, and with the corresponding software (Could be as simple as just doing the same Optimus trick that laptop with extra switchable discrete GPU have been doing for ages: the repurposed datacenter GPUs renders the graphics of the game, the mainboard runs the compositor to assemble the final picture that is then output through the mainboard's DisplayPort).
(DISCLAIMER: I actually do use a second hand GPU with HBM in my current build, except that mine still has a functionning DisplayPort so I don't even need to fumble with Linux "prime" drivers).

At worse, boards that use esoteric server connections could be de-soldered and re-soldered onto more conventional PCIe carrier PCBs (there's a whole market in China of rebuilding new PCIe cards with quanditites of RAM adapted for machine learning research out of non-banned regular gaming donnor cards; transplanting GPUs is a well mastered skill).
At worst if the GPUs are very weird (not exposing PCIe pins on the BGA pinout and/or support for PCIe being fused off in the GPU), NVlink-to-PCIe6 bridges chips are very likely to popup (see the current market for dead-cheap PCIe switches) making the GPU transplanted onto a classic PCIe cards still viable.

Valve: "The Steam Machine will be priced comparative to an entry level PC..."

AI Market: Price of entry PCs now jumps up to "both your kidneys and a testicle"

That's a *you* thing.

Music is a very prevalent use of YouTube: " Since Lady Gaga's "Bad Romance" in 2009, every video that has reached the top of the "most-viewed YouTube videos" list has been a music video. ", a use that could probably be expensive to Google (do some labels require some global agreement with Google?) and will typically be a "click on the link to a playlist or a mix, then let it play in the background" exactly as in this news (e.g. they use YouTube as a glorified Spotify competitor). By making the most frequent use of YouTube tied to Premium, Google attempts increasing the subscription, hoping tis allows them to show "line goes up" to investors.

Podcasts are other typical use where "hitting play and leave in the background, listening while doing something else".
Other examples would be video essay where you don't case about the visuals and are more interested in the subject.

There are also parents who use "kids" mode of YouTube (restricted to kids-only channels) as the new gen "TV nanny" to leave the kids parked in front of.
(Though that's a different type of lock: there the video is still playing on the screen, while the phone/tablet "locks in the background" - i.e. the video still plays but switching to any other app else requires login in again. This might not be blocked in the current restrictions).

I suspect Google has run the numbers and concluded that they might just get enough subscribers to display a "line goes up" report to investors.
Again your (and my) personal use of YouTube aren't the most typical. So it's possible that overall it would still be useful to Google.
e.g.: They will very certainly lose users like you, but a small fraction of the much more frequently represented "music listeners" might decide to fork the money for Premium to continue to be able to listen to music playlist in the background.
But maybe they bet wrong and those will instead abandon YouTube for Spotify, Deezer, SoundCloud, Bandcamp or whatever the cool kids use nowadays.

Basically: Its position among the consoles of the same generation.
And the "Lateral Thinking with Withered Technology" approach typical at Nintendo (don't go for bells and whistles and custom chips, go for well-established tech that's easy to mass-produce).

On paper, the GameCube had musc lower specs than the competition (Sony's Playstation 2 and Microsoft's X-Box), as Nintendo didn't want to follow the arm-race for the beefiest specs.

Contrast with the previous two iterations:
- Nintendo 64: has a very cool chipset developed in partnership with SGI, and which hoped to revolutionize 3D graphics and aimed to compete against the 3D available on Sony's PlayStation 1 (and to some extent SEGA's Saturn, though that machine wasn't primarily 3D).
- Super Famicom / SNES: despite a relatively crappy main CPU (a 16bit extensions of the same 6502 family as before, still running on a 8bit bus), it had advanced visual capabilities (e.g.: the tilemap can be roto-zoomed on Mode7, multiple scrolling and effects planes, etc.) and coprocessors for cool raster-effect tricks (e.g. doing 3D using line-by-line changes of Mode 7's roto-zoom), and supported quite a menagerie of extra in-cartridge coprocessors (e.g.: the SuperFX used for 3D polygonal games like starfox), competing very well against contemporary SEGA's MegaDrive/Genesis and NEC's PC Engine (To the point that it caused SEGA to panic and release a series of not-so successful expansions: CD (and its own roto-zoom) then later 32X). The SNES' graphics could even look decent at a fraction of the price compared to what the "actually a consolized arcade board" NeoGeo was doing - allowing a lot of good arcade ports (e.g., Street Fighter 2's port fo SNES is not put to shame when compared to the origin al CPS2 arcade board).

By the time the GameCube was out, gamers were used to Nintendo trying to make hardware that can seriously compete with the rest of the market on raw performances. Then suddenly the GameCube comes out, which is not aiming to beat either of its contemporary competitors, just aims to be cheap to produce and thus sellable for profit (instead of subsidized by game sales like Sony does) and be simpler to program for than their own N64 predecessor or the PS2 competitor.

In practice, devs managed to make a lot of cool games for it.
(Because at the end of the day, the enjoyment you experience comes from how interesting the games are, not what numbers are on some spec sheet).

But on paper, GameCube has, e.g., a fraction of the pixel rate of a PlayStation 2 and less than XBox', smaller amount of RAM compared to those two competitors, etc.
Even the storage space is smaller (mini DVD vs regular full sized DVD).

"Hardcore gamers" running after the shinniest newest visual gizmos where disappointed.

Tap a user to get their profile.
Tap "Encryption"
You have the option to scan a QR code or compare key fingerprints.

"Your security code with {nickname} change. Tap to learn more."

Why MitM when they already have plenty of side channels (cloud-based AI; cloud-based backups; and its closed-source so they could probably just inject a backdoor in the next upgrade and nobody can notice, etc.)

Could one day be perhaps decentralised, but currently aren't really much.

What is currently decentralised in ATproto:
you can help BlueSky offload some of their server cost by hosting your own personnal data server (PDS).

What currently isn't:
to make anything useful of the data stored on all the PDSes, you need "indexing server" (basically a kind-of search engine that indexes everything stored there, to make it possible to know who would need to get which content). This is extremely resource intensive, meaning only a few big corporations can run those, so beside BlueSky, there aren't that many other things running there.

(Note: PDS are still useful for de-centralisation - they are the thing that Bridgy relies upon to bridge BlueSky and the Fediverse. On the Fediverse, Bridgy shows as yet another server similar to any other instance of e.g. Mastodon; on BlueSky Bridgy shows up as PDS to be indexed and used by BlueSky)

Contrast this with the Fediverse which is actually already hundreds of different servers all successfully talking to each other.

That's not the case here. Supposedly (but hard to check as its closed source) WhatsApp uses the Signal protocol for end-2-end encryption which is as good as it gets. BUT the app is still leaking the chat in a zillion different ways.

E.g.: Meta-AI gets CC'd every message because once someone in that group used the "AI summary" functionnality which automatically adds Meta's cloudd as a party to this group.

E.g.: Out of the box, the App backs all its data to the cloud so you can recover your account even if your phone is lost.

Jokes aside:

- WhatsApp supposedly uses the Signal protocol(*), which is as good as is gets with regards to E2EE

BUT!...

- End to end is only as good as the said end-points. In addition to being closed source, the WhatsApp has multiple problems: an AI functionality that needs to send all your chats back to Meta's cloud unencrypted (as it's not relying on locally running models) so the AI can summarize and whatever else shit they are advertising; WhatsApp by default backs its data up onto the cloud, so if you lose your phone you can still recover instead of needing to start a new account from scratch.

So I presume it's a lawsuit where both parties are technically right:
- Meta is technically right in affirming that they use the current best standard for E2EE (they mostly are)
- The plaintiff are right that the clients (Android app, web app, etc.) are completely leaking data in a zillion different ways (what's the point in having the best E2EE if said End is going to blast that precious private information in all possible directions?!)

---

(*): Minus a couple of bits. WhatsApp doesn't use Signal's implementation (sealed sender) to hide the meta data of who is chatting with whom AFAIK they only encrypt the message body; the protocol can work without ever needing phone numbers, Signal client is getting there eventually, WhatsApp isn't touching that either.

My main point is that the e-mail metaphor is not well adapted to describe how modern secure chat service work.
While the points made about e-mail are valid, they are simply not applicable to WhatsApp because it works completely differently.

Actually: no.
One doesn't "login" (in classical the sense of sending credential to a server and it answering) into most modern secure chat systems.

Identity of a sender is determined by secure cryptographic keys held by the client, and server has little to do with this (There are modern chat systems that don't even rely on a service, though that's not the case of WhatsApp).

It's much more subtle (and better secured than that).
In theory, with the core Signal protocol, only the apps at each end hold the encryption keys, the message history, etc. there is no "login" or other account credential that you could type into another device that would grant access to those.
- If you've lost the phone everything is lost forever with it, you're good to start creating a new account.
- You would need to steal the whole device while it is operating and unlocked to be able to access those.

BUT
in practice WhatsApp implements a backup mechanism.
And on Android WhatsApp implements it by saving stuff on your Google Drive. Which has a classic login. So yeah there are credentials that one could hack and steal to gain access to your identity and start posting on your behalf, it's just that those have nothing to do with the messaging protocol.
(Another attack vector, that is not related to TFA's lawsuit but is yet another way to steal/hack private information is the MetaAI chatbot forced upon WhatsApp users. There's no point in having an ubersecure unbreakable encryption end-to-end, it one of those ends then subsequently re-upload everything in the clear to some Facebook cloud server for some dubious summarisation)

Oral- / verbal- contracts, aka handshake agreements are a thing in some places.
If a transaction can be contracted in such way, a secure message could be considered a valid way to form an agreement.

But as you point out, real estate transactions would require notarized attestation, which virtually no messaging system is.

And again what I find weird is not that the real estate transfer wasn't granted.

The real WTF to me are the specific arguments used in the logic: that headers in e-mail are added by the service - yes, and? What the hell does it have to do with WhatsApp?

It might come as a surprise but "oral- or verbal- contracts" (also called "handshake agreements" elsewhere) are a thing.

Also, the issue of the ruling is whether the court could trust the "sender" information and consider it something genuinely sent by the message author.

By some moon-logic, because in e-mails the sender is part of the headers and those can be altered while in transit as part of normal operations, therefore in WhatsApp which absolutely does NOT run on e-mail protocols (and relies instead of a subset of the Signal Protocol) they should also be considered as something added by the service and not something written by the message author and thus does not constitute a valid signature.

Which by the way is the big WTF. Messages are authenticated as part of the Signal protocol. When you see a message sent by XyZ, the protocole guarantees you that it was sent by someone holding that telephone in their hands, and not rewritten by a 3rd party (unlike an e-mail).

If a culture accepts oral contracts/handshake argument for a specific transaction, a message over a strongly e2e encrypted channel like a chat service using Signal protocol should be considered acceptable. For e-mails, that would require the body of the e-mail itself being authenticated with something like S/MIME or PGP.

Yes, e-mail headers could be altered (and routinely are for functional reason) by absolutely any relay along the route.
And even when using things like S/MIME or PGP, they are not authenticated (again because they can be altered as part of a normal e-mail transit)

BUT WhatsApp does not rely on the e-mail protocol.
It uses a variation of the Signal Protocol which works differently and thus the point of this metaphor is moot.