pull down to refresh

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?
102 sats \ 23 replies \ @sudonaka 19h
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
102 sats \ 17 replies \ @ek 18h
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
202 sats \ 15 replies \ @ek 16h
open the doors to [...] UTXO bloat
More people using bitcoin as money would also create UTXO bloat.
So no, it did not "open the doors" to UTXO bloat.
reply
2 trillion USD value is "using bitcoin as money"
Are you done stacking? How is this an argument, you sound like a spoiled child complaining about the free human action of others.
reply
0 sats \ 13 replies \ @ek 15h
If you still don't get it, then have a nice day
reply
Lmao like I said enjoy ossification
Or you can go cry
reply
100 sats \ 11 replies \ @ek 15h
2 trillion USD value is "using bitcoin as money"
Imagine thinking institutions offering bitcoin ETFs for the masses to buy so they don't use bitcoin as money but only make the price go up is "using bitcoin as money"
I had a good laugh, thanks, do you have more of these brilliant insights?
/cc @DarthCoin, I'm sure you will love this
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.
reply
102 sats \ 3 replies \ @sudonaka 16h
Have you changed your personal policy to allow unlimited -datacarriersize? If so why, and if not, why not?
reply
Good point. I haven't changed it.
Why haven't I changed it? In general, this question of spam and relaying it seems like a very minor issue to me. I haven't felt it was important enough to merit much action at all.
By the same token, when 30 is released I will likely not upgrade for a few months; but this is my practice with all releases -- I like to be a lagging updater.
But I have no doubt that I'll be running 30 eventually.
reply
0 sats \ 1 reply \ @sudonaka 3h
So you have no personal motivation to open up your nodes datacarriersize, yet you agree that other people should change it for you when you update?
reply
As is the case with most of the more inconsequential details of my node's configuration, I don't mind when updates change them.
reply