Unlikely. The digital signatures bitcoin uses are regarded as secure, (there could be attacks if we get quantum computers.) The issue here was the software didn't put in enough randomness when generating the keys, and so it was straight forward to search the small space of keys the wallet would generate.
It's not so different if you encrypted a file with a weak password and someone guessed it—you don't need stronger encryption, you need to pick a better password.
The proof of work part of bitcoin is really for "consensus", so everyone agrees which transactions happened in which order, this attack didn't affect that part at all.
The issue is they forked sane GPL code (Trezor's), then decided they wanted no one to be able to copy them in turn so they rewrote components and messed up entropy. IIRC they intended to still use the secure element to generate some but it failed open and had no meaningful tests to detect so, leading to significantly fewer bytes for years.
Tests should have caught that, and it should not have simply failed open during the most critical part of entropy generation.
So, maybe we could consider a "White Hat" ransomware group that takes the money and also leaks the data, so that long term no one bothers to pay which ultimately disincentivizes ransomware attacks?
Somewhat off topic, but I've always wanted to know _who_ gets my tax dollars more than what they were spent on. For example, a middle class salary to someone building bombs in Ohio is different than a wealthy investor who owns shares in some educational company that provides standardized tests to local public schools.
I'm not sure I follow your workflow exactly. If PR B is merged, then I'd expect PR A to already be merged (I'd normally branch off of A to make B.)
That said, after the squash merge of A and git fetch origin, you want something like git rebase --update-refs --onto origin/main A C (or whatever the tip of the chain of branches is)
The --update-refs will make sure pr B is in the right spot. Of course, you need to (force) push the updated branches. AFAICT the gh command line tool makes this a bit smoother.
Which seems to be function composition and some extra rules about if there's 1 or 2 arguments, so the 2 arguments go to G and F is applied as a single argument function. Anyway if you click on a few of these an look at the red text in the upper right it's fairly clear what it's doing.
Reminds me of this quote which I recently found and like:
> look, I'm sorry, but the rule is simple:
if you made something 2x faster, you might have done something smart
if you made something 100x faster, you definitely just stopped doing something stupid
Edit: cool article, I have myself speculated that we will get a new language made for/by llms that will be torture writing by hand/ide but easy to read/follow/navigate/check for a human and super easy for Llms to develop and maintain.
There are things like https://www.baeldung.com/jackson-streaming-api but maybe there's more in you definition of "streamable" that JSON doesn't satisfy.