Thread

Replies (67)

Or maybe admit the central attack vector for Bitcoin has ALWAYS been the Core Devs. And now they’re persona non grata - fully unacceptable or not welcome. I disagree strongly with you. Half-measures are not a debate here. We all know a handful of people who could change the code was never tenable. We need to stop making excuses, and start deciding IF there is a way going forward that isn’t Ossification right now, at this point. And I don’t see a successful discussion about that happening, honestly, because Plebs don’t control Bitcoin anymore. Ossification is the only option. Trust no one.
I've somewhat landed on the idea that maybe the single biggest mistake of satoshi was to have a first party implementation of bitcoin. Maybe if he never passed on the control of core and abandoned the repo when he left, it would be better off. You'd have all the contributors at the time disperse into a few different projects that fork from core, but forced to maintain consensus with each other. I realized this with nostr. It's genuinely the main thing separating it from all other "decentralized" networks. If fiatjaf had a nostr client, it would define what nostr is. Every normie looks for a "default app" for bitcoin, as with nostr. The absence of one is what makes it decentralized. They are immediately faced with the choice and realize that there isn't a easy default thing they can stay on. No app is more valid than another, the network is the rules they abide by to interoperate with each other. Everyone instinctively saw btc core as the point of centralization that it was, no one ever made that argument for bitcoin wallets, or nostr clients. There has long been this propaganda that it's good that there aren't alternatives to core, and it's not a massive point of centralization to have a single repo define the whole network and this op_return debacle has just broken that propaganda. It took a massively unpopular update to wake people up to it, but theres finally popular demand for alternative implementations that follow consensus. Luke Jr is not someone who should inherit the throne of bitcoin stewardship. He's not someone who can do what core did, managing a project and collaborating with others to maintain a whole network. But he can absolutely find a place offering one of many implementations for bitcoin, that people who like his software can run, as long as he doesn't do something that pisses them off. He should never develop for a majority of the network, but 5-10% of the plebs using his software poses no risks. I'm fully on the filter side of this debate and even I'd admit that I'd rather have the current core team, than to have Luke lead core, or for knots to take the place of core today. But that's not happening. The most important thing right now is for there to emerge serious, responsibly led alternatives to core. And for that reason I am excited by this announcement.
Not upgrading is a solid choice. My plan was to continue with my Satoshi v27.0/ node indefinitely, but I made the switch to Knots because the configuration flexibility is superb. A third option with more devs would be ideal, but I am happy with a single dev with a heavily scrutinized/audited source code by serious bitcoiners. My new settings cut op_return in half and minimized the time my node relays free transactions. Getting garbage off the chain should be a top priority for any serious bitcoiner.
Knots is means to an end. As soon as the goal is met, of making Core something for the market not run (assuming they're sticking with their decisions), then I'll move to a more suitable node other than Knots that's basically the same but with a better team of good talent and sound mind and character.
Is the implication meant to be that Bitcoin Core isn't conservative, well reviewed, and/or well maintained? If so, why do you think that? Or is your desire to have additional implementations that are conservative, well reviewed, and well maintained? If so, do you think that's a better use of limited developer talent than focusing on making Bitcoin Core better? When I read your post, I get the feeling that you think about "Core" and "Knots" as teams that each move with a single shared purpose, as if under the direction of an individual. That might be true for Knots, which effectively has a single developer, but it's not how I see the Bitcoin Core project, whose contributors are often in disagreement with each other (if usually only about the best way to achieve a particular goal). Maintaining that environment where independent contributors can easily collaborate, are free to express their differing opinions, and can create single-topic software forks (like PT's librerelay or the BIP148 activation client) if they feel out of alignment with the other devs seems to me like a better use of scarce talent than creating more implementations for the purpose of having more teams.
↩ replying to ODELL
Core used to be like that and even the knots apologists like Bitcoin Mechanic say they want to just submit a pr to core and have a good relationship where these ideas can be discussed and worked out. Knots is just the fallback escape hatch. I think core should prioritize working with a large section of devs and should try not to give the middle finger to the more prominent devs with big followings lol
Puts last year's discussions on ossification into context really with all the squabbles. Be fascinating to see what would come out if all this energy were directed instead to L2/L3 solutions and additional work on mining and hash power decentralisation. Humans are similar to electricity grids - vast energy losses in trasmission!
Get Eric Voskuil on citadel or listen to his Bitcoin takeover interviews. The project is solid but, from his words, hasn't taken any third-party funding. As a dev, libbitcoin is ok to get running and hack on, but it's missing the type of project management that core has. It's not really possible to find out what needs to be done, unless it's behind closed doors. All their comm channels seem dead
Why? Core solution is just accepting that Ordinals are inevitable in the chain and minimize damage, allowing people to use OP_RETURN as preferred option to upload this data. Instead of storing in Witness or another solutions that increase UTXO set, that will be an increase in RAM requirement for nodes, a true menace for decentralization.