pull down to refresh

The actual PR was already posted on SN (#1232217), and there is a good explanation on the Github link there. But here is the note @schmidty posted on X:
Earlier today I opened a PR to Bitcoin Core to remove the deprecation for the datacarrier and datacarriersize options. I realize this is a sensitive topic for Bitcoin Core users, so I am also posting here for both visibility and as a place for feedback that might not otherwise be appropriate on the PR.
The tactical goal is to get the change into the forthcoming Bitcoin Core v30 release. I provided rationale which you can review in the PR: https://github.com/bitcoin/bitcoin/pull/33453
In it I outline that 1. users clearly want this option 2. the intent of deprecation is unclear, and 3. the potential harm to Bitcoin Core users is not large.
Bigger picture, I think designating these options as deprecated has exacerbated already contentious discussions. People supportive of keeping and using these options are some of Bitcoin’s most ardent supporters and disenfranchising them by deprecating the option is not good for Bitcoin Core or Bitcoin. I know that people still object to the default OP_RETURN value, but with this change, at least Bitcoin Core users can continue to set the value as they see fit. Bitcoin is sure to have more, and bigger, battles ahead and Id like to move forward together to fight those.
Your guess is as good as mine as to whether this PR will get merged. In full transparency, I did reach out to a few contributors to see whether this PR is even “reasonable to propose” at this point, but I did not seek to get “approvals” during such discussions.
Note that this PR takes an existing commit by @ajtowns from a branch of his.
Ill add the same disclaimer here that I did in the PR, given my role @bitcoinbrink:
“I am the executive director of Brink, an organization that funds some Bitcoin Core developers, some of which may review this PR. I have emailed them separately letting them know that any review feedback here (positive or critical) will not impact their standing, funding, or employment with Brink. Independent review and open discussion are critical for Bitcoin Core, and Ive encouraged them to engage as they would with any other contributor.”
I welcome your feedback.
I’ve already shared my thoughts on this, and I think schmidty said it really well, he pretty much summed up what I think too. Taking away the option to change those params would be kinda like a dictatorship. Once again, thanks @schmidty!
reply
I can get behind this. Compromise seems good for issues that don't seem to be too important. It would be really nice to see things move on to more important/interesting issues. Props to @schmidty!
I do worry that we will just have to rehash the whole debate whenever data carrier is deprecated.
Unfortunately, even if merged, I don't think it will change the social media debate very much. So far most (almost all) the replies on X have been negative -- from both sides.
reply
144 sats \ 6 replies \ @ek 2h
Imagine core just forks itself without data carrier and the fork with it just stops being maintained haha
reply
77 sats \ 5 replies \ @leaf 58m
I had a similar thought: that lots of people think there is some power from controlling the core repo. I think devs will eventually need to prove there isn't by creating a new code fork.
What would really prove there is no power in a repo is to give the keys to core to luke then code fork.
reply
67 sats \ 4 replies \ @optimism 44m
@justin_shocknet was advocating for archiving bitcoin/bitcoin, multiple times, eg #966918
reply
Yep, and I don't think I've seen anyone since make a compelling a case as to why it should continue as-is.
reply
169 sats \ 2 replies \ @optimism 37m
When I first saw you say it, I wasn't sure so I decided to brood on it a little bit, but the more I think about it, and perhaps even more significantly, the more the drama develops, the more I agree.
The only thing I worry about is that we will see more drama in the way of Bitcoin Unlimited, where a decision is made (or coded in) that a failed softfork should anyway activate.
reply
Can you expand the latter point? Not sure I quite follow...
One of my reasonings for deprecating is that any bad decisions have a more isolated impact
I think the worst case scenario is a new repository gets the same mind-share and we're just back to where we are now, but at least that would require a proactive opt-in rather than letting changes slip by as deference.
reply
0 sats \ 0 replies \ @leaf 7m
I think the worst case scenario is a new repository gets the same mind-share
I think the community will always want a repo with a lot of eyes on it, to manage PRs and ensure changes are well reviewed.
If you had loads of code forks, it would be tough to know what has and hasn't been thoroughly reviewed. That won't cut it on a project that requires absolute reliability.
135 sats \ 2 replies \ @optimism 1h
Unfortunately, even if merged, I don't think it will change the social media debate very much.
The past 3 days I've been "debating" (tho not really) the repo ecosystem with a bunch of stackers under @0xbitcoiner's post (#1227133) and if I'm honest, it's leading nowhere. The only thing to do is take action.
This PR is a good action indicator. If it gets closed, then action is more warranted than it is now. If it stays open forever, action is warranted based on other activity. If it is merged, then action is less warranted.
However, I'm super hesitant to take action or even explain my full thinking on the greater issue at hand because I'd insta dox myself. Choices, choices.
reply
Always protect the nym.
reply
102 sats \ 0 replies \ @optimism 49m
The nym can be burned (after I transfer territory, lol) and I wouldn't reuse it. So I'm not going to talk about the actions I am lining up to mitigate.
reply