dnamlin's comments

Binders full of MSDN CD-ROMs...IYKYK

Soooo many handles to remember to free in the right order, even before you got into OLE/COM. It was a lot of fun to come up with your own C++ wrappers to put them under RAII -- and this was before "smart pointers." You sort of had to iterate on a few versions of that, trying out mechanisms to scope sharing, to understand why MFC was the way it was.

Fond memories of the #winprog IRC channel. Discussions there, theForger's tutorial, and Charles Petzold's books got me going on Startup Control Panel and the like.

https://web.archive.org/web/20131106030702/http://www.mlin.n...

Modern money has operated as you describe for less than one human lifetime. It might not work long-term, and indeed there are significant reasons for worry that it won't. Not that it _can't_ in principle, but that it _won't_ due to mismanagement and misaligned political incentives. A future alternate system might well have deflationary characteristics.

If you mean to hold USD-denominated deposits in a local bank, the local government can easily confiscate or convert them. Numerous such examples.

If you mean to hold USD paper notes, that does happen a lot all over the world as you say; and not necessarily legally. Many advantages to digitization (and some disadvantages).

This seems like a comment from 10 years ago. In 2025, Larry Fink just announced he's a "big believer" at Davos, and the President of the United States ordered his team to evaluate creating a huge reserve.

That was so funny they left out "and returns"

Like, it's valid to point to its historical volatility, but it struck me as intellectually dishonest to say it's been (historically) risky without also acknowledging that holders have (historically) been well-rewarded for their risk appetite. High Sharpe ratio, etc.

To me it's never been that "intrinsic value" of Bitcoin makes much sense, but that it holds up a mirror to the incumbent system and how little that makes sense either!

Not really, to the extent that Bell Labs undertook true basic research for its own sake, without much concern for any short/medium-term commercial potential. (No need to rock the boat commercially, while the parent corporation had a regulated monopoly to milk!)

Maybe some case could be made for Alphabet's "Other Bets" collectively, but...the Bell Labs column has nine Nobel Prizes in it...

The square footage of this building is double that of Meta's MPK 20/21 complex, and comparable to the entire Googleplex.

It wasn't even headquarters for Bell Labs.

A reminder....all glory is fleeting!

Bell Labs was active in this area going all the way back to the 1930s, where its relative isolation was ideal for radio astronomy -- in fact, one can reasonably claim Holmdel as the origin of that field.

Also in this era, once you got a job at Bell Labs, then you were set for life...not getting filthy rich necessarily, but you could fully expect to spend your entire career with the one prestigious, stable, monopoly-supported employer, before retiring with a nice pension. As a result, the rank-and-file talent were happy to move and settle down in the towns surrounding these giant suburban/exurban campuses, which also had excellent public schools thanks to the affluent tax base and high concentration of engineer/scientist parents.

IMO a much more-thorough analysis of the essential point discussed here: https://www.lynalden.com/bitcoin-security-modeling/

An Ethereum address is just a public key (which, as the owner, you also have the private key to). You can make one, and sign messages with it, without touching the blockchain or sending any assets to it. So added complexity is -necessary- only to the extent you wish to involve those additional ways you can interact with the blockchain (that you can't using GPG or SSH keys). I'm saying this in principle of course, granting the current lack of convenient utilities/CLIs for operating this way.

I would speculate that there are probably already more people who practice decent opsec for their Ethereum keys than for GPG & SSH keys. Soon it won't be close!

Ethereum has standardized ways to formulate (off-chain) signatures for arbitrary messages [1] and Solidity structs [2]. Convenient command-line tooling is lacking currently, but some interesting twists to consider:

If you sign using a key that also controls cryptoassets, then you're incentivized to keep the key safe and secure indefinitely. Contrast with tendency to lose GPG and SSH keys after losing interest for a few years, changing jobs, etc.

Moreover, consider key revocation. The revocation mechanisms for GPG and SSH keys are not that effective, due to impracticality of publishing your revocation in a way that really ensures subsequent verifiers are alarmed. If only there were some sort of decentralized, permissionless, globally-replicated database which verifiers could check for that information...

More generally if you have a really important signature to publish, you can mint an NFT for it or otherwise inscribe it on the blockchain. There it will live, irrefutably notarized and timestamped, forever.

I explored these ideas in a weeklong side project [3] that only got to cumbersome proof-of-concept stage.

[1] https://eth.wiki/json-rpc/API#eth_sign

[2] https://eips.ethereum.org/EIPS/eip-712

[3] https://github.com/mlin/stakesign

Footnote: Bitcoin also had an arbitrary-message-signing mechanism -- commonly used on bitcointalk back in the day -- but I think it may now be ~defunct due to not keeping up with the newer address types introduced in recent years.

With sqlite_zstd_vfs the data are compressed beforehand and stored that way "at rest", so web responses are directly copied to the wire controlled by HTTP range headers, similarly to the OP. They need to be decompressed by a client library sitting between SQLite and the wire.

I plowed the 40 GiB database file into sqlite_zstd_vfs [1] which reduced it 75% to 10 GiB. This plug-in also supports HTTP access [2] in the spirit of phiresky's, however, I don't have a WebAssembly build of mine yet, so it's a library for desktop/command-line apps for now. You can try it out on Linux or macOS x86-64:

  pip3 install genomicsqlite
  genomicsqlite https://f000.backblazeb2.com/file/mlin-public/static.wiki/en.zstd.db "select text from wiki_articles where title = 'SQLite'"

("genomicsqlite" is the CLI for my Genomics Extension [3], which is built around these Zstandard compression & web layers.)

[1] https://github.com/mlin/sqlite_zstd_vfs

[2] https://github.com/mlin/sqlite_web_vfs

[3] https://mlin.github.io/GenomicSQLite

EDITS: I expanded on this comment in this gist https://gist.github.com/mlin/ee20d7c5156baf9b12518961f36590c...

If you want to download the whole en.zstd.db, then please kindly get it from zenodo (which doesn't support HTTP range requests, but is free): https://zenodo.org/record/5149677