Damn that’s so disappointing from njalla.
View quoted note →
Matt Corallo
matt@bitcoin.ninja
npub185h9...wrdp
10th known contributor to Bitcoin Core. Now Full-Time Open-Source Bitcoin+Lightning Projects at Spiral (Part of Block).
Got on a plane last night and my wife joked “and Asia hasn’t even woken up yet”. Indeed, guess we’re living in 2018 and Asia woke up 😂
Wait so let me get this straight. Luke’s (obviously) trying to rig the PoW function selection for his coin, probably cause he has ASICs for one option.
So….he’s just trying to create a coin he can premine so he can dump it on the BIP 110 followers? Man that’s low af.
People got this weird idea after segwit that a “UASF” is this magic thing where a bunch of people on social media get together and start making threats and suddenly Bitcoin’s consensus rules will change.
That’s nonsense. I’m sorry if you were told that the thing that activated Segwit was a UASF and nothing else but you were lied to.
I missed that 110-coin isn’t even banning the subset of data BIP 110 seeks to ban, and probably never will.
bip110.fail
Yet more phishing attempts.


It’s still early, but it’s not at all the case that we cant learn anything from this and do better. If I were a hardware wallet manufacturer, I think my takeaways/changes I’d make are:
1) insecure fallbacks or hashing in weak entropy should be explicitly verboten. Unless it’s 96 bits or higher, do not include it!
2) Anything generating keys on an embedded device should have at least two random inputs and should check them with even basic randomness tests. This requires pulling lots of extra bits in before they’ve been whitened which isn’t possible on all hardware, but hardware that does whitening usually will do tests for you so make sure you’re checking it! View quoted note →
3. (Obviously) Everyone should be doing regular LLM reviews of software and firmware.
4. HWWs should have an explicit QA step where each input to the RNG is logged and the result of adding those inputs together to build a seed is done on a separate device with a reimplementation and compared against the device's seed. This should be done for each firmware release.
I doubt almost any HWWs today do 2&4.
I’m gonna be honest, as much as I think bitcoin is important for freedom in the long term, it really doesn’t feel great working in bitcoin this weekend.
LLMs are very two-sided for security.
On the one hand, long-latent bugs are finally surfacing.
On the other hand, before you choose to use a product, you can get your own code review done for incredibly low cost*!
In the short term it’s incredibly bad, in the long-term it democratizes code review greatly. “Don’t trust, verify” finally becomes an actual possibility for normal people!
* of course LLMs do still make up issues when asked, push any such review to write PoCs to check their analysis!
There are related vulnerabilities in later hardware as well.
At this juncture I would migrate funds off of any single-sig (or multi-sig of only) colcard wallets that were generated on-device without dice or passphrase.
View quoted note →
LLMs are so well tuned for optimizing the lighting pathfinding problem. Give them a dataset and tell them to optimize a parameter and they go ham.
Big things ahead for the LDK pathfinder and lighting payment success rates.