Change FILE_CHAR_BLOCKLIST to FILE_CHARS_DISALLOWED #19897

Blocklist is ambiguous. It could mean a list of blocks.

Example: "blocknotify" in the same file refers to Bitcoin blocks.

Blacklist is common nomenclature. Blocklist (being a fake word) is discriminatory to those whose first language is not English.

Clearly this is going to cause another pull request in n days to change it again. I really don't want to rehash this topic over and over, and I am certain that the other reviewers in this repo don't want to either. So instead of changing a variable name back and forth, it might be better to remove it completely.

It seems odd anyway to have three named constants where one would be sufficient and clearer.

Was an unnecessary change in the first place.

Let’s change it back and be done with it.

Injecting SJW politics into Bitcoin is an attack vector/slippery slope. Unless it was creating a problem why change it?

Blacklist is easy to understand. I see no reason to change that cause of SJW reasons. That opens the door to endless word-changes.

It was suggested FILE_CHAR_EXCLUDE in #19227 (review), nobody cared about a constructive comment, thank you for reviewing.

ACK. "blocklist" is ambiguous, and the idea that political PR's engender more participation and review doesn't take into account the time and energy they waste.

Whats a Blocklist?

is this it? 647010 647090 647080 647070 647060 647050

ACK

The purpose of the words "white" and "black" are to convey the presence or absence of light visible to the human eye. They are the extremes, whereas "light" and "dark" are used to subjectively or contextually denominate some place in between. The purpose of these words are very similar to the purpose of the word "red", which conveys a specific sensation when observing a measurable frequency on the electromagnetic spectrum, except red is a color, and white & black are not.

Human skin is neither white or black, they are all shades of brown (and maybe some red after a hot day at the beach). While it's clear to me why humans have chosen to adopt these words and apply them to the human condition of outwardly observable genetic diversity, it's not quite clear to me why this adoption should then trickle back to the original meaning and purpose of the words themselves. Given that all humans are People-of-Color, it is impossible for the words white and black, without any stated context, to meaningfully apply to PoC (like myself, you, and everyone else).

On the subject of changing the words in consideration of the sensitive among us, where those sensitive individuals might apply their own context when no such context was provided by the use of the words: If the words blacklist and whitelist were to be changed to, for example, nightlist and daylist, this could potentially offend people who identify as nocturnal animals, or people who like to tan at the beach. They too would have to apply their own context to those words in order to become offended, but this is no different than those who take issue with the words white and black. Since many in the FOSS community are anonymous it's impossible to know if there are these kinds of (perfectly fine) people working on the project currently, or might otherwise be attracted to this project in the future.

Now, one might argue that one set of people is a known known, while the other set is a known unknown (I believe Nocturnal Furrys are inherently known unknowns), but I argue that it's simply not proper to prioritize the feelings of one set of contributors over another set, as that lays the groundwork of precedent for additional emotional/irrational changes in the code moving into the future. With that being said, I believe it to be much more important to focus on meaningful development and not get distracted by political signaling, or open the door for more political creep into the project.

Keep social justice out of code. Code can be ambiguous enough at the best of times. ‘Blacklist’ is less confusing than ‘block list’ and we need to make sure we don’t extend technical debt into the future because of the stupidity around us right now.

I am a Bitcoiner, I have an English BA degree with linguistics focus, and I wish to protest the change from "Blacklisting" to "Blocklisting". It should be immediately reverted.

There is absolutely no racially charged meaning behind the blacklist word, the lexical usage of the term does not imply racially charged meanings or anything else that is perverted by those who wish to imply racial motives upon users of lexical terms, this is a politicized attempt at creating changes and softening the English language intentionally.

Therefore ACK

ACK

Critical race theory is too divisive to have even an inch in something as important as bitcoin. It's a Pandora's Box. Some will say changes like the original are merely attempts to be inclusive. That may be true, but it leaves open serious social attack vectors. Consider how megacorps and governments prevent effective organization against them.

It was suggested FILE_CHAR_EXCLUDE in #19227 (comment), nobody cared about a constructive comment, thank you for reviewing.

Even though I'm very much for this revert, in this particular case exclusion/inclusion (FILE_CHAR_EXCLUDE) seems to be as self-explanatory as the original blacklist/whitelist. "Blocklist" is a very horrible term to use in Bitcoin because it means a list of blocks.

Only change the variable names IF you can come up with as self-explanatory term as the original one. FILE_CHAR_EXCLUDE is one, FILE_CHAR_BLOCKLIST is not.^

EDIT: or @laanwj 's FILE_CHARS_DISALLOWED might be even better.

@calkob no, this is a block list:

Concept ACK

US culture war doesn't belong in a global software. The initial commit was pointless.

The SJW nonsense imported from the USA should be removed. This commit: #19227 had no place.

NACK, either

• inline as @MarcoFalke suggested
• @laanwj suggestion FILE_CHARS_DISALLOWED
• my suggestion FILE_CHAR_EXCLUDE
• anything else but revert, that will start another discussion...

ACK

This is Bitcoin. Let's keep the SJW stuff on Facebook, please.

If you are such an SJW change it to FILE_CHAR_BANLIST, and don't pervert the English language.

ACK there have been zero issues with the term blacklist until a bunch of sally wanker WHITE folk all of a sudden read a book written by an actual racist person who is projecting her OWN racism, onto all others of her "skin color"

blacklist is not racist. People who think the word blacklist is racist, are themselves, racist.

FILE_CHAR_BLACKLIST is cleaner & less ambiguous than FILE_CHAR_BLOCKLIST in addition to being how it was originally defined. Unless there is a material reason for the change, we should avoid unnecessary variable renaming/refactoring.

Injecting politics into Bitcoin is an attack vector.

The argument according to which reverting this "will cause another PR down the road is bogus". It is the same as not returning a stolen item from a thief to the rightful owner "because it would cause the thief to try to steal it again in the future".

Also, the other PR was proposed by some anonymous random guy who just created a fake GitHub account and started opening SJW pull-requests in many repositories, it's not like it was the voice of a group or anything like that.

ACK

I thought it was unnecessary and bad precedent to begin with, and in the context of blockchain, blocklist is ambiguous af

FILE_CHAR_BLACKLIST is cleaner & less ambiguous than FILE_CHAR_BLOCKLIST in addition to being how it was originally defined.

I authored the original change 4e9efac678a9c0ea4e4c7dd956ea036ae6cf17ec and I feel sorry that a stupid test caused so much noise.

Also, the original PR was open from 29 May 2018 to 17 Fev 2020 ...

This was a silly PR, that shouldn't have been merged in the first place. Reverting it is a well deserved UNDO, and such things should not be done again.

Freaking ridiculous how few contributors coordinated their responses and then @MarcoFalke merged that PR in one day - #19227.

Let's see how long it'll take to revert it.

I authored the original change 4e9efac and I feel sorry that a stupid test caused so much noise. @promag you shouldn't be sorry - what @TrentZ did was great troll and test of attack vector. Congrats to him for succeeding to become "Bitcoin Core Contributor" by exploiting people's programming.

@MarcoFalke so, if an attack has been attempted, we should not fix it because somebody will likely retry it in "n days" ? This was an un-necessary change on the first place, as the only intent was to push political activism and word-policing into what should be neutral and censorship resistant technology. I appreciate your effort into bitcoin development, but please restore it as it was: BLACKLIST.

Ok, if you squash the commits into one according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits, and update the PR title to reflect the actual change, this can be merged.

This is a pretty good argument to have more anonymous developers.

Publicly going against the cultural force of SJW-ism is hard, and can cause material personal damage to people, especially people based in the U.S, and even more so if such people are in academic settings like universities. The developers who pushed this through quickly may not have had bad intent, it's just the fear to be seen to be against "inclusive language" was too great for them to handle.

The mainstream media would be all too happy to associate Bitcoin with racists and the alt-right too, if given the chance and a whiff of an excuse, so let's not be too harsh on the developers here for bending to the SJW narrative since the change was quite harmless. The mainstream media is still quite powerful for now, if they can turn pepe the fucking frog into a symbol of hate, they'd have no trouble turning Bitcoin into "money for nazis".

Agree with everyone else though, no more of this nonsense. But I somewhat understand why they bent the knee, even though I personally would have told the original author of the PR to fuck off.

@Cobra-Bitcoin this argument would make sense if the term "blacklist" actually had racial connotations in software development.

Since it doesn't, I struggle to understand why the change was authored in the first place, let alone why it was merged, especially because the change itself was so godforsakenly tiny and dumb and materially affected test cases.

Ok, if you squash the commits into one according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits, and update the PR title to reflect the actual change, this can be merged.

Done.

ACK 637d8bce741213295bd9b9d1982cae663c701ba1

ACK 637d8bce741213295bd9b9d1982cae663c701ba1 — this is a clear variable name improvement

I wish people paid as much attention to reviewing all changes as to silly word games.

FILE_CHARS_SHITLIST

ACK Blocklist is extremely ambiguous. The previous pull request also had an obvious political meaning and this should be avoided at any cost in Bitcoin. Bitcoin is for everyone, not for marxists sjw. Please keep these useless and confusing cosmetic changes out of this place. Bitcoin is and it should be censorship resistant, this includes being politically neutral, so any political trap should be strictly avoided. Blacklist is a very clear and not offensive technical word.

I agree that the term "blocklist" was confusing, it's more clear now.

ACK 637d8bce741213295bd9b9d1982cae663c701ba1

I wish people paid as much attention to reviewing all changes as to silly word games.

Exactly my thoughts!

ACK 637d8bce741213295bd9b9d1982cae663c701ba1

I wish people paid as much attention to reviewing all changes as to silly word games.

This.

I approve of DISALLOWED or BLACKLIST, both works. ACK

ACK 637d8bce741213295bd9b9d1982cae663c701ba1

I wish people paid as much attention to reviewing all changes as to silly word games.

Most proposed changes aren't this harmful. I think it's a great example of the developer community reacting forcefully to a perceived attack. Shouldn't have been merged in the first place, and the precedent is what's triggering people.

Most proposed changes aren't this harmful.

so you are more afraid of a rogue variable rename than, say, a bug that would introduce a remote vulnerability in P2P, an inflation bug, or that would wipe your wallet ? definitely not the right priorities here

welcome to the project anwyay :smile:

Please change it back to BLACKLIST. It should be made very clear that no political arguments are allowed to influence the code of bitcoin.

ACK 637d8bce741213295bd9b9d1982cae663c701ba1.

The new variable reflects the goal stated in L18.

@laanwj this was a very serious attack: political arguments should not get into bitcoin code: bitcoin is born to be censor resistant and neutral, and I feel this to be a big deal.

Two equally bad phenomena seem to be happening in this drama: the first was a random contributor coming out of nowhere, making a subtle change with a political bent, and exploiting the relative tendency of Bitcoin Core developers to want to avoid conflict to push through a change the community doesn't really agree with. The other thing that's happening here is the mob using this as a chance to rally around, the whole crazy "defenders of Bitcoin" bullshit that has existed ever since the scaling fork drama. If your only contributions in the Bitcoin community are essentially just shouting down others, then you aren't doing very much to help Bitcoin.

I knew very well that BLACKLIST was not going to be merged when I made my pull request.

I thought it was important that there was a discussion about it so that it can be avoided in the future.

NACK

Why is it FILE_CHARS_DISALLOWED instead of FILE_CHAR_DISALLOWED?

Props to you @verretor and @laanwj for trying to stay on the point. I'm pissed this even became an issue. But seems we must continuously tend to our USA SJWs and their need to virtue signal everyday and everywhere.

This isn't about blocking anything, so blocklist is technically wrong. "Blacklist" has actual ambiguity issues too.

What this list is doing, is listing characters to exclude from filenames, because the OS (or our libraries) are known to not support them in filenames.

I think FILE_CHAR_EXCLUDE is fine.

NACK

Why is it FILE_CHARS_DISALLOWED instead of FILE_CHAR_DISALLOWED?

Because multiple characters are disallowed. FILE_CHAR_START and FILE_CHAR_END represent the range of possible characters.

This isn't about blocking anything, so blocklist is technically wrong. "Blacklist" has actual ambiguity issues too.

What this list is doing, is listing characters to exclude from filenames, because the OS (or our libraries) are known to not support them in filenames.

I think FILE_CHAR_EXCLUDE is fine. @laanwj suggested FILE_CHARS_DISALLOWED.

Freaking ridiculous how few contributors coordinated their responses and then @MarcoFalke merged that PR in one day - #19227.

Let's see how long it'll take to revert it.

Friendly response: everything I've seen over the past year and a half here has been ad-hoc and voluntary. No one ever says which PRs to review, which issues to respond to, or which things to work on. Colleagues just ask if you have a few cycles available to review or re-review their work, which happens a lot (and is fine) but it wasn't the case for that PR. Or, someone might suggest an old PR that could be picked up if you ask. Everything happens in an ad-hoc, free manner, and that's how I like it and think it should be. There might be coordination, but other than the public weekly irc meetings, I haven't seen it. There is so much to do, the stack of PRs to review grows and grows, and so many important things to worry about, that a PR like that one is pretty much at the bottom of the list of things to allocate time and energy to. It's not surprising to me that it would be handled quickly to free up bandwidth for all the rest.

Coordination? It's actually kind of the opposite. Apart from discussion on GitHub, there is almost no direct feedback. You kind of wonder. How can I do better. It's a quiet, focused, set-your-own priorities-and-schedule sort of life. For me, anyway. Hope this helps. Cheers.

@verretor Wouldn't that have also applied when it was blacklist and blocklist?

Props to you @verretor and @laanwj for trying to stay on the point. I'm pissed this even became an issue. But seems we must continuously tend to our USA SJWs and their fucking need to virtue signal everyday and everywhere.

Thank you. I hope there won't be a need for such debates in the future.

@verretor Wouldn't that have also applied when it was blacklist and blocklist?

Yes. The variable name wasn't appropriate. It should have been plural.

I knew very well that BLACKLIST was not going to be merged when I made my pull request.

I thought it was important that there was a discussion about it so that it can be avoided in the future.

I appreciate your PR in that sense that it goes to show how you can:

• start out from a proposed code change you think improves the code base
• get good review and feedback from others
• update the code where you see fit based on suggestions
• update the title of the PR to reflect the change
• have people agree or disagree with the changes
• iterate until the PR can be merged or closed

I see a lot of new faces here and I hope some will stick around when this blows over. Every review is appreciated.

so you are more afraid of a rogue variable rename than, say, a bug that would introduce a remote vulnerability in P2P, an inflation bug, or that would wipe your wallet ? @laanwj

Is it your experience that most PRs in this project introduce harmful changes? If not, then why do you not appreciate the attention an objectively bad change that slipped through is getting, no matter how minor? Introducing ambiguity is objectively bad, and allowing code changes without technical merit for political reasons justifies future such changes "for consistency's sake". By accepting the revert you would effectively be removing unnecessary future work from your plate as a maintainer.

Sorry for all the questions, but am I understanding correctly that there was a valid cause to change the name prior to and separate from the reason everyone is up in arms over? Sheesh...

On Sun, Sep 6, 2020, at 12:59 PM, Benoît Verret wrote:

@verretor https://github.com/verretor Wouldn't that have also applied when it was blacklist and blocklist?

Yes. The variable name wasn't appropriate. It should have been plural.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/pull/19897#issuecomment-687841670, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGEVTBS4CAWCEHZDYY4HFQDSEO5WNANCNFSM4Q4QQ7GA.

@AmishNick Yes. The variable name deserved to be changed since the beginning.

@eriknylund

I see a lot of new faces here and I hope some will stick around when this blows over. Every review is appreciated.

After this, it will stick.

But I heartily suggest to fix it as FILE_CHARS_BLACKLIST. The technical point of ambiguity is definitely relevant, but the political argument is much more dangerous despite looking harmless.

While we acknowledge it is a small change, Cisco Talos is moving to replace our use of the terms ‘blacklist’ and ‘whitelist’ with ‘block list’ and ‘allow list,’” according to the Cisco Talos team

Google had already made some headway on swapping “blocklist” in for “blacklist,” with efforts having begun as early as May 2018 to remove the user-facing instances of “blacklist” and “whitelist” in Chrome.

I bet the author read up the article about IT companies using fairer words, but using block-list in block-chain makes it somewhat ambiguous. Your FILE_CHARS_DISALLOWED is OK

Is it your experience that most PRs in this project introduce harmful changes?

no, but the point of review is to pay attention to when they might. PRs that introduce 'harmful changes' will look like completely harmless changes that have a mistake (usually not intentional) in their logic

variable names do not affect the functionality of the code at all: and this isn't even code that is shipped in the release ! It's only used for testing—for all intents and purposes, the change was harmless

a better question: where were all you so worried about details like variable names, when #19227 was openened? why do you gang up here almost three months later?

Denylist.

why do you gang up here almost three months later?

Because some asshole tweeted about #19227 3 months after it was opened.

Concept ACK

INVALID_FILE_CHARS ?

INVALID_FILE_CHARS ?

The other two variables are named FILE_CHAR_START and FILE_CHAR_END.

While we acknowledge it is a small change, Cisco Talos is moving to replace our use of the terms ‘blacklist’ and ‘whitelist’ with ‘block list’ and ‘allow list,’” according to the Cisco Talos team

Google had already made some headway on swapping “blocklist” in for “blacklist,” with efforts having begun as early as May 2018 to remove the user-facing instances of “blacklist” and “whitelist” in Chrome.

I bet the author read up the article about IT companies using fairer words, but using block-list in block-chain makes it somewhat ambiguous. Your FILE_CHARS_DISALLOWED is OK

So, are we fixed on FILE_CHARS_DISALLOWED ? Who will make the final decision? Most of the community still disagrees with disallowed keyword.

I'm going to merge this when it has passed the CI checks.

We need to reach compromises over time. Disallowed is an acceptable compromise.