I stand with Bitcoin. Core's governance seems like some issues for them to figure out, but that'll happen any time you get a company involved. I don't think there's anything too nefarious, but systems can evolve problematically even with the best of intentions. The good news is, Core isn't the only game in town. Just saw Eric Voskuil the other day post a chart about libbitcoin 4's performance on a Raspi 5 compared to Core v31. It's admittedly with txindex=1 and txospenderindex=1 (to match libbitcoin's native functionality with it's mmap approach rather than leveldb), so it's not quite fair to compare to how people usually run Core, but for a raspberry pi I'm pretty surprised. image There's also utreexod and florestad on the horizon. At the end of the day the gentleman's agreement that was mempool policy filters was never going to last. Filters work when nodes all agree, and miners either agree, or are too decentralized to do anything to override it. As long as something like slipstream is possible, or things like LibreRelay exists, it only makes sense for a default filter policy to be open (and for the configuration to opt-into tighter policy to be available in the name of configurability), because the alternative is leaving node runners with a poor view of what is coming down the pike without any benefit being derived from it. I've not seen any indication that spam can sustain expensive fees for any prolonged amount of time -- there's just no feedback loop you're going to get from selling dickbutts. People will create it, their sats will be gone, and that is that. Bitcoin is stronger than this, and certainly doesn't need to be getting dragged into this silly game of whackamole over the games of trifling fools.

Replies (1)

"gentleman's agreement that was mempool policy filters" ... that reminds me of the comparatively low drama about other such gentleman's agreements. First-seen-safe, RBF, ... Bitcoin is growing up and the romantic "we can all agree to do things this and that way" just doesn't cut it anymore.