pull down to refresh
I'd be happy to clarify any specific points you find untenable. My description of BIP-110 and its mechanics is grounded in game theory and the incentives at play within the network. If you have concerns, I'm open to discussing them with you in more detail.
This sidesteps the real issue. Bitcoin is hard to change, so policy should move slowly, carefully, and with the community. Even Adam said he would not have merged this so fast and preferred 160B over 100 kB. The process created an unnecessary sense of urgency. Whether spam can be stopped is a separate debate. The question here is how we change Bitcoin policy.
Big fan of Core up to v29, but v30 was merged too soon. Classic FOSS failure mode: ship first, debate later. A PR with 400+ downvotes and a sustained supermajority of NACKs should have paused. The worrying part is there has been no meaningful course correction.
The net result is people moving to Knots, which may be a good thing. It is more attack resistant over the long term, which is good for Bitcoin, and the market will likely price that in.
Re: Luke’s personal life & the leaked IMs, doxxing a Bitcoin dev is not cypherpunk. Cypherpunks respect privacy. Those who do or support it shouldn’t be trusted with Bitcoin development.
Core v30 is a substantive change. The PR was merged too soon, despite a supermajority against it from the start. Shipping it as-is would be a mistake. Bitcoin is hard to change, and that’s what gives it value.
There are many censorship-resistant electronic coins, but what makes Bitcoin unique is not just resistance, it is being a fairly issued store of value on a level playing field.
Changing a working system risks unintended side-effects, as history shows. In psychology we speak of “boosts” and “nudges”; Steve Jobs put it more simply: “If you make something 10% easier, you double adoption.”
The recent PR was merged too quickly, without the nuanced debate Bitcoin deserves. A revert and a delay would give space to regain consensus. The fork wars taught us that stepping back, even at the last minute, can unify Bitcoin, and make it stronger.
Bitcoin changes must be proven safe, needed, and wanted—before they're adopted. The burden is on the proposer, not the community. If it’s not clearly worth the risk, the answer is simple: don’t change the rules. That’s how Bitcoin stays secure
Yes, there is definitely potential for a deterministic KDF such as a an HD Wallet. The current spec is only a first draft. We can and should add a paragraph on subkey derivation.
Bitcoin doesnt need a soft fork
Happens alot. Did you know that daniele and fiatjaf snuck spyware into njump dot me (the link in the title), too?
Check it yourself.
When it comes to "open" source, dont trust, verify.
A relay is essentially a type of web server that uses the HTTP upgrade protocol. The rules for running a relay are no different from running any standard web server—there's no added layer of decentralization just because it's a relay. In fact, the current state of the relay network is one of neglect, with it becoming more centralized as it shrinks. It's important to note that illegal content remains illegal on any web server, including relays, and you're still liable for hosting it.
Where Nostr might offer an advantage over the traditional web is in making truthful content harder to censor. If an admin on one server is grumpy, it's easier to switch to another and continue participating without being 'canceled.' But at its core, a relay is still just a web server—albeit one with real-time updates.
njump does indeed suck and contains spyware put in by daniel and fiatjaf -- not very cyperpunk
you might want to use https://nostr.at to protect users
Scoresby's critique assumes that BIP-110 could fail to activate, but it can't. There's no timeout or "failed" state. Mandatory signaling forces lock-in at max_activation_height, regardless of organic support. The chain-split scenarios described rely on minority hashrate activation, but the 55% threshold prevents this.