dr-bonez / Aiden 🏴 is on Nostr

Last Notes

2026-07-29 02:03:55 UTC

Path A: A company sells a product. It's a great product, lots of people buy it. Then, something changes about the product. Thousands of customers do not like this change, and choose to boycott it. Economically, they don't carry a ton of weight, the company is fine. They make most of their money through institutional and government contracts, who didn't care about the change. With those customers gone, they build what the big players want them to build. Their end user product erodes over time. That's never where the money was, so it doesn't matter. Then, one day, the big players ask them to cross a line they are unwilling to cross. They lose the contract. They lose the whole company.
Path B: Same company. Same backlash. Instead of ignoring the customers, they change the product to address the customers' real concerns (even if it's not exactly what the users were asking for). The customers feel respected enough to stay. The big players remain the main revenue source, but underneath that, the customer base has grown. The company could survive on just those customers if they needed to. The big players could try to force the company to cross a line, but they know they have no leverage. The company is fine.
I'm not claiming this is a perfect analogy but it is relevant. The claim a lot of people are making is that plebs don't matter enough to be worth changing consensus for. They may be right, but not inherently. That's something the network is deciding right now. Is losing these users really the outcome you want?

2026-07-18 00:01:19 UTC

Already getting way better results with Kimi K3 than with Opus 4.8

2026-07-16 21:05:22 UTC

I'd like to share some thoughts on the BIP-110 situation. I normally stay out of Bitcoin politics. For the past several years, I've been focused on building the best *linux home server distribution* I can, which doesn't leave me a lot of room to focus on the latest intricacies and nuances about Bitcoin specifically. That said, this situation has demanded enough of my attention to form an opinion that may be worth sharing.
I want to start by saying, regardless of my feelings on the matter, *Start9* 's stance is to make sure we support our users' ability to run BIP-110 nodes (in addition to stock core nodes, of course). We have this stance because there is *real*, *meaningful* demand for it from users that *understand the risks* and want to do it anyway. It is not our job to shelter users from risk. Running a home server is risky. Running Bitcoin is risky. *Using* Bitcoin is risky. We do it anyway because we have principals. We do our best to prevent users from taking on risks they don't understand, but we do *not* believe that the users that want to run BIP-110 are misguided.
All of that said, personally? I don't think BIP-110 will do much about spam. Maybe the supporters are right that it would "send a message" that the network is willing to keep forking to fight spam. Maybe that's enough of a deterrent. But I think it would have been a more effective strategy if the first shot fired in that battle was more than a sub-1% fee penalty from forced chunking.
The strategy is sound. All we actually can do to fight spam is to make it more expensive. This generally means doing our best to optimize for using Bitcoin for its intended purpose, and then penalize transactions that do not take advantage of these optimizations. A better model for this, IMO, would be to continue to further divorce transaction *weight* from transaction *size* to better represent the actual cost to the network, rather than just trying to force an increase to the *actual* transaction size for "non-intended use".
I understand why this isn't the tack that was chosen. Finding consensus on a weight function that captures both the technical and social consequences of a transaction would be extremely difficult, as the "correct" weight function is highly subjective. Not to mention this kind of change doesn't fall as cleanly into soft vs hard fork. One, it doesn't specifically invalidate certain forms of transactions. This complicates the game theory of a miner choosing to include something or not, they can't just discard certain transactions "to be safe". Second, there's no guarantee the new weight function would be unable to produce a block that goes beyond the old limits, unless you enforced both. In which case miners have a less of an incentive to accept it, since it is guaranteed to *reduce* transaction throughput (and therefore, probably, fees). So such a change would require a higher level of consensus to succeed. I don't think that's a bad thing.
I don't think Luke is "attacking Bitcoin". I do genuinely think he's doing what he thinks is best for Bitcoin. But even if this was a "attack", so what? Bitcoin was designed to survive in an adversarial environment. But whether you think it's an attack, or a philosophical or technological disagreement, these sorts of things are good for Bitcoin in the long run. This isn't the first contentious fork, and it won't be the last. The ecosystem needs to get better at handling them, and we won't unless we face that threat. Wallet providers, point of sale systems, lightning nodes, are all underprepared for a contentious soft fork with deep reorg risk. There are probably a majority of users that would prefer not to gamble on choosing a side, and would rather require payment on both chains until the dust settles. Those tied up in the battle would rather not support this use case, since it forces people to choose a side. But supporting such a thing would invariably make Bitcoin *better money* as users could retain confidence in its utility for payments without getting involved in the politics, regardless of how contentious a soft fork may look. I hope we're better prepared next time.
One last thing, a PSA. I'm hearing a lot of talk about selling "fork coins". Even if you have complete confidence in one chain over the other, this is EXTREMELY DANGEROUS. In most cases, especially just after the activation height, transactions broadcast on one chain *are also valid on the other*. Unless you go through the effort of tainting your coins on the chain you're keeping, whoever you sell your coins to on the fork could rebroadcast the same transaction on the other chain to steal your coins. Even if they *don't* rebroadcast, it could happen accidentally. In a soft fork scenario, the difficulty of tainting your coins is asymmetric. To taint your BIP-110 coins (with the intention of selling your *non*-BIP-110 coins) is (relatively) easy. Just move all your coins to a new address in a transaction that is not valid according to BIP-110 (add an 84b OP_RETURN or something). The alternative is harder. To taint your non-BIP-110 coins, you need to mix them with a coinbase (or ancestor thereof) from a block *after* the activation height. If someone is offering this service **do not trust, verify**. **If you get it wrong, you will lose your coins.**