If we remove the magic number header then the file command won’t know it’s a JPEG is that the solution?
pull down to refresh
142 sats \ 9 replies \ @k00b 6 Sep
There is no solution. This isn't about CP. Even if CP didn't exist, this debate would still be happening. This is about people - naturally - wanting to control what bitcoin is but in a roundabout way.
Among good faith, bitcoin-is-money bitcoiners, we have four-ish camps afaict:
- stopping arbitrary data storage is futile and the desire to store it will never end, so let's minimize the damage caused by it by supporting arbitrary data storage in the least harmful way
- stopping arbitrary data storage is futile and the desire to store it will never end, but we've been doing okay so far and this is a huge distraction, so let's just keep things as they are
- stopping arbitrary data storage is futile and the desire to store it will never end, but this is about signaling to the world what bitcoin is and what it stands for (if signaling has deleterious effects to censorship resistance and mining decentralization, or decentralization generally, we can work on those independently - signaling is really really important)
- stopping arbitrary data storage is not futile, we can stop most of it with filters, and the desire to store it will end iff we try hard enough, signal hard enough
reply
50 sats \ 5 replies \ @Undisciplined 6 Sep
What about the argument that being able to control what your node is relaying to the rest of the network is important (independent of what ends up on-chain)?
reply
52 sats \ 4 replies \ @k00b 6 Sep
I don't think anyone would debate that. The operative phrase is "being able." Regardless of what Core ships, you are able to control what your node is relaying if you are willing to patch Core, run a fork of Core, or run another primary bitcoin protocol implementation. So the debate isn't about what you are able to do.
The debate is about whether Core should be able to NOT maintain a dial or knob for every variable in relay policy, especially dials and knobs that they think are footguns and are harming the network.
To put it another way, Core's job IMHO is providing an incredibly secure and robust bitcoin protocol reference implementation. Having a maximally configurable relay policy is out of scope and every configuration option adds more code to maintain and secure.
reply
0 sats \ 3 replies \ @Undisciplined 6 Sep
It's hard for me to tell definitively what the debate is about. You say "The debate is about whether Core should be able to NOT maintain..." but I'd characterize what I've heard as "Core should continue maintaining...". I'd certainly say they have no obligation to maintain anything in particular.
The argument, from what I've seen, that they should (not "must") continue maintaining these knobs and dials is that what they do will become default policy across the network (unless people abandon Core's configuration) and there clearly is not anything like community consensus on this issue yet.
reply
52 sats \ 1 reply \ @SimpleStacker 6 Sep
Political fights over "default settings" are so interesting to me.
On the one hand, it seems silly because everyone has the option to turn off the defaults.
On the other hand, the default setting is an incredibly powerful behavioral lever.
Maybe I just hate people.
reply
0 sats \ 0 replies \ @Undisciplined 6 Sep
It seems especially relevant when both sides ostensibly want more bitcoiners to run their own nodes. That will inevitably mean more nodes run by less technically knowledgeable people who just accept the default settings.
My Spidey-Sense is definitely going off with how the Core folks are behaving, but I don't have the technical savvy to rely on more than my intuition.
reply
42 sats \ 0 replies \ @k00b 6 Sep
You're right. I overcomplicated that phrasing by stating what I think is the inverse.
I think you have it right.
reply
33 sats \ 1 reply \ @SimpleStacker 6 Sep
My problem with 1 & 2 is that it feels defeatist.
reply
0 sats \ 0 replies \ @k00b 6 Sep
I can see that. I see it more like accepting defeat in a battle so we can win the war.
If this were a battle deciding the outcome of the war, I'd agree that we should fight even with the knowledge that we'll lose.
reply
10 sats \ 0 replies \ @carter OP 6 Sep
my idea was some kinda merkle tree with fat and skinny blocks add some incentive to store fat blocks but people could choose to only store skinny blocks... everything still validates the same
reply