turbo-geth VS bips

To be clear, it was a CPU fault that doesn't occur at all when running e.g. stress-ng, but only (as far as I know) when running our particular production workload.

And only after several hours of running our production workload.

But then, once it's known to be provokeable for a given machine, it's extremely reliable to trigger it again — in that it seems to take the same number of executed instructions that utilize the faulty part of the die, since power on. (I.e. if I run a workload that's 50% AES-NI and 50% something else, then it takes exactly twice as long to fault as if the workload was 100% AES-NI.)

And it isn't provoked any more quickly, by having just provoked it with the last hard-fault — i.e. there's no temporal locality to it. Which would make both "environmental conditions" and "CPU is overheating / overvolting" much less likely as contributing factors.

> There have been enough of them in private hands for long enough that if there were widespread issues they would be well-known.

Our setup is likely a bit unusual. These machines that experienced the faults, have every available PCIe lane (other than the few given to the NIC) dedicated to NVMe; where we've got the NVMe sticks stuck together in software RAIDO (meaning that every disk read fans in as many almost-precisely-parallel PCIe packets contending for bus time to DMA their way back into the kernel BIO buffers.) On top of this, we then have every core saturated with parallel CPU-bottlenecked activity, with a heavy focus on these AES-NI instructions; and a high level of rapid allocation/dellocation of multi-GB per-client working arenas, contending against a very large and very hot disk page cache.

I'll put it like this: some of these machines are "real-time OLAP" DB (Postgres) servers. And under load, our PG transactions sit in WAIT_LWLOCK waiting to start up, because they're actually contending over acquiring reader access to the global in-memory pg_locks table in order to write their per-table READ_SHARED locks there (in turn because they're dealing with wide joins across N tables in M schemas where each table has hundreds of partitions and the query is an aggregate so no constraint-exclusion can be used.) Imagine the TLB havoc going on, as those forked-off query workers fight for time.

It's to the point that if we don't either terminate our long-lived client connections (even when not idle), or restart our PG servers at least once a month, we actually see per-backend resource leaks that eventually cause PG to get OOMed!

The machines that aren't DB servers, meanwhile — but are still set up the same on an OS level — are blockchain nodes, running https://github.com/ledgerwatch/erigon, which likes to do its syncing work in big batches: download N blocks, then execute N blocks, then index N blocks. The part that reliably causes the faults is "hashing N blocks", for sufficiently large values of N that you only ever really hit during a backfill sync, not live sync.

In neither case would I expect many others to have hit on just the right combination of load to end up with the same problems.

(Which is why I don't really believe that whatever problem AMD might have seen, is related to this one. This seems more like a single-batch production error than anything, where OVH happened to acquire multiple CPUs from that single batch.)

> It's possible that AMD didn't order enough capacity from TSMC to meet demand, and couldn't get more during the COVID supply chain issues.

Yes, but that doesn't explain why they weren't able to ramp up production at any point in the last four years. Even now, there are still likely some smaller hosts that would like to buy EPYC 7xxxs at more-affordable prices, if AMD would make them.

You need an additional factor to explain this lack of ramp-up post-COVID; and to explain why the cloud providers aren't still buying any 7xxxs (which they would normally do, to satisfy legacy clients who want to replicate their exact setup across more AZs/regions.) Server CPUs don't normally have 2-year purchase commitments. It's normally more like 6.

Sure, maybe Zen4c was super-marketable to the clouds' customers, so they negotiated with AMD to drop all their existing spend commitments on 7xxx parts purchases in favor of committing to 9xxx parts purchases. (But why would AMD agree to that, without anything the clouds could hold over their head? It would mean shutting down many of the 7xxx production lines early, translating to the CapEx for those production lines not getting paid off!)

consensus client/execution client -> ERIGON v2.45.2 and NIMBUS v23.5.1

This file (https://github.com/ledgerwatch/erigon/blob/devel/cmd/prometheus/dashboards/erigon.json) is outdated. Many panels are not working. Would appreciate if someone can share the json with all the useful panels.

48 hours - currently on stage 7 - https://github.com/ledgerwatch/erigon/blob/devel/eth/stagedsync/README.md

https://github.com/ledgerwatch/erigon 696 contributors

Erigon 2.41.0 does come with Shanghai for mainnet though so as long as people are running 2.41.0 or 2.42.0 they will be all set.

— Erigon ***(~10.8% of all clients)***A fork of Geth client (also in the GO programming language) that is focused on maximizing the efficiency of storage for archive nodes.

Github issue tracking it, likely to be fixed on Erigon side

Modern bitcoin addresses use a base-32 character set that leaves out some of the most ambiguous pairs and also permutes the address ordering so that the most visually similar remaining characters produce single bit errors which are better handled by the addresses error detecting (and potentially correcting) code.

https://github.com/bitcoin/bips/blob/master/bip-0173.mediawi...

Context: Bitcoin miners have just adopted a 50% pay cut for themselves. This pay cut was baked into Bitcoin protocol at the launch of the network (mostly, see "BIP 42" [1]). The OP link gives information about the block in which this pay cut was made.

I get that HN comments tend to dismiss Bitcoin. But the fact that for the fourth time this pay cut has happened without a hitch speaks volumes to what makes Bitcoin interesting: It's a rare combination of economic incentives and technology that keeps chugging. Nobody can stop it. And it's extremely resistant to change. It requires no governmental approval. All attempts at subversion or interference have failed. There aren't many things that come close to that kind of record.

[1] https://github.com/bitcoin/bips/blob/master/bip-0042.mediawi...

Bitcoin transactions involve locking funds in scripts, which can only be spent if those locking conditions are met. The part of the script that expresses these locking conditions are called ScriptPubKeys. On the other hand, the part that provides unlocking scripts to satisfy the locking conditions is referred to as ScriptSig for legacy transactions, and ScriptWitness for SegWit Transactions. These scripts are evaluated by a stack-based language called Script. This article will mainly focus on ScriptPubKeys.

Here’s the reference https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

There are 5 271 537 971 301 488 476 000 309 317 528 177 868 800 possible permutations of the bip39 wordlist found here: https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt when using 12 word seeds. You probably have better change to win the lottery every week for the rest of your life than cracking a 12 word seed in correct order

No one controls Bitcoin, because it's a protocol. Bitcoin Core is the reference implementation, but there are others, and anyone can create new implementations if they wish. Also, the Bitcoin Core maintainers can't just change something on a whim, because users would then switch to another fork. Maintainers (or miners or other groups) can't force their changes on users, because everyone can decide on their own which version they want to use.

The protocol development happens through BIPs (Bitcoin improvement proposals): https://github.com/bitcoin/bips

BIPs are discussed for years, before (and if) they are implemented, and basically everyone needs to agree on them, because no one wants to fork the blockchain, which could be devastating.

All the seeds generated from the CoolWallet (Number / Word) adhere to the BIP-39 protocol.