RustyRussell

These are all improving: hardware support is generally getting better and guests modified to behave nicer so weird cases can just fail, and devices are often now specifically designed for virtualization (plug for my old project VirtIO here!). But it's still software, and asserting there are no bugs left seems incautious.

The information leakage problems are an ongoing whack-a-mole which depends on your setup: they may or may not result in escapes, depending on the nature of the secrets.

Of course, higher level bugs are still there: convincing people or software to change settings, install software or pass too much information through existing channels which are perfectly secure!

Trivial key/data database with great performance and robustness. Embedded in surprising places (e2fsck!) and my go-to unless I need Sqlite3.

Of course, it really depends on whether you can actually back this up! And in this case Val does, quite clearly.

Developing a proper Linux little-endian ABI was a major engineering feat, across kernel and toolchain, but nobody understood what to do with it.

I had a friend who worked on it: he called it simply "decimal floating" because there was no point :)

If about existing code, the comment belongs with the code. If it's a process thing (e.g. code that is removed or didn't work), it belongs in the commit.

Most importantly, while commit messages can reference issues for convenience, they MUST reproduce the critical details: GitHub is transient, git messages are not!

See https://github.com/rustyrussell/runes for a simpler alternative and implementation (this has C and Python, but there's also a Rust implementation because why not?)

However, the "no db access" property has proven to be untenable in practice. Users end up wanting to see what runes are issued, blacklist them, know when they were last used, and have rate limits. The last two are a killer, requiring some state to be kept (unless your system allows you to return a modified rune to the user, which is a different workflow from normal bearer creds).

And the Blockstream FUD is tired (I am the longest serving technical employee at Blockstream)

I wanted to bundle a chain of certs, check that the leaf was <some domain> and its key signed <some data>, and that the bundle provided a path to a locally-trusted root. This allows third-party serving of signed data, rather than having to trade your IP address for validation.

Doing so with existing tools was so terrible that I was pretty sure my result was grossly insecure :(

I look forward to the promised lower-level APIs!

But I remember the first time I saw such a program which never freed anything: jitterbug, the simple bug tracker which ran as a CGI script.

It indeed allows a very simple style!

Meanwhile, use ccan/tal (https://github.com/rustyrussell/ccan/blob/master/ccan/tal/_i...) and be happy :)

TBH I'm not sure if they're allowed to operate in NY though.

And they later detailed the $1bn Tether printed for Celcius in return for collateral (once Celcius collapsed and they claimed it was fully repaid).

Understand: for modern banks this kind of fractional behaviour is considered normal. It's only from the weird Bitcoin perspective that full reserve would be a requirement.

But remember, the crypto exchange market is also extremely large and profitable, and yet exchanges keep turning out to be massive frauds.

The number of people who promised to keep your money safe and had long term incentive to do so and yet failed miserably used to astonish me. Now I assume it's the norm.

Now, it's just a question of degree: they're so profitable they can recover from being fractional rapidly. OTOH, why mess with a working formula?

(I work for Blockstream, and we have no current employees in the top 10 contributors for this release AFAICT)

(I am the longest serving engineer at Blockstream).

In that it's not used by bitcoind or any wallets I know of: it's mainly of interest here because the book Mastering Bitcoin used it for examples.

One day I'll get back to that rewrite of ccontrol using modern distcc's features...

The additional assumption vs simply holding your own funds is a throughput requirement: that miners not censor your transactions for some (up-front-chosen) period of time.

With normal funds there is a non-censoring requirement, but it's more vague since the miners may have to censor you forever to make your funds useless.

But I agree that the NFT thing is really a side-effect of fees being low (thus, cheap distributed storage) which probably at best provides a price floor, rather than a sustainable source of revenue.

https://rusty-lightning.medium.com/the-three-economic-eras-o... for more detail that you probably want...

The only reason most Bitcoin users care is that they pushed up fees for everyone else (there is limited block space, so miners take the highest bids). Such few pressure is expected to be the norm eventually, and has happened before, but there's been a prolonged period (years) of low fees so it was a bit of a surprise to many.