pull down to refresh
10 sats \ 16 replies \ @sudonaka 7h \ parent \ on: Nunchuk founder, Hugo, on filter debate: Believe in PoW bitcoin
So they aren’t effective enough ….
So they should be removed completely with unknown consequences
It’s intellectual schizophrenia
You and I have probably both heard most of the arguments for and against the removal of filters. Let's see if we can take the conversation somewhere new:
How would you react in the following case:
- Bitcoin Core decides to leave the datacarriersize default at 80
- A bunch of new nodes running Libre Relay start showing up, so much so that they account for 20% of Bitcoin nodes.
What do you do?
reply
Great I’ll answer:
In that case I would actually entertain the conversation about a policy change proposal. That would be similar to how RBF was implemented, first it was an option, grassroots majority of users enabled it, then it became default.
Core today is doing something completely different- they are forcing a default change WITHOUT that 20% etc enabling it first and justifying the discussion for a change to defaults.
let me ask another question back please:
IF (I understand many do not believe it’s the case, then this is a hypothetical…)
IF the core dev team was ever infiltrated by government agents or others looking to harm or sabotage Bitcoin- as I believe we should always be prepared for- what warning signs are you watching for? What kind of behavior or attacks are possible via the core dev team personnel?
reply
In that case I would actually entertain the conversation about a policy change proposal. That would be similar to how RBF was implemented, first it was an option, grassroots majority of users enabled it, then it became default.
RBF was easy to enforce because it was more permissive. A majority was not needed.
You want to enforce something that is less permissive. Even if 99.999% of nodes filter, I can just spin up nodes that don't or just submit my tx directly to a miner ...
reply
First of all, I'm not trying to "enforce" anything. You have no clue what will happen in terms of spam after v30 is released, just like none of the supposed geniuses had any clue that taproot or even segwit, which Luke wrote, would eventually open the doors to inscriptions and UTXO bloat.
This might be surprising to you, but I actually don't give much of a fuck about this technical argument at all. The fact is all the supposed metrics that core argues for: UTXO bloat, Mining pool centralization, etc- have all negatively adjusted trajectory over the past few years under the current B-core dev team's watch.
So beyond the technical, I think the core team is failing and most of them should resign. They have terrible communication skills and they do not even appear to be principled bitcoiners at heart. Asking ridiculous questions like "what is spam?" or "is bitcoin money or data?" should disqualify you from contributions immediately.
Many non-technical users like me had no idea how bad it appeared to be before this op_return fiasco. I wish we woke up to this sooner, perhaps before the taproot upgrade, but we are where we are.
What is the way forward?
I think we should have multiple competing implementations that will continue debates like this forever and magnify every single spec of code that is changing in every single release on every single client. "The most viewed piece of software in the world" has a new meaning now. And the LLM tools to empower plebs like me are just in time.
The privilege of the "reference implementation" is over. Nothing will be taken for granted, and you can forget every single "upgrade" to consensus except for absolutely essential bug fixes.
Congratulations, you have successfully achieved de facto ossification.
reply
reply
Thanks for your answer.
What warning signs are you watching for?
I suppose we should assume that Core is compromised. I don't know what warning signs there would be, but I assume I probably wouldn't notice them (Any obvious attack seems like it would fail). So the safest route is to assume that they aren't on my side.
What kind of behavior or attacks are possible via the core dev team personnel?
They could try to sneak something into the code unnoticed. But this seems unlikely; there are a lot of people watching the repository.
They could try to argue for consensus changes that are unsafe. Maybe try to push through a scripting change that is not fully understood and allows some sort of damaging functionality.
Whatever the case, my response is that I'm not running the latest version until I agree with the arguments/reasons behind it.
In the case of changing the datacarriersize defaults, I agree with the arguments.