Call for Maintainer: Privacy

ghost commented at 4:05 pm on August 19, 2022: none

@JeremyRubin opened an issue yesterday after IRC meeting however its related to P2P & Networking only with no submodules considered or a wider scope.

Why do we need a privacy maintainer?

@sipa and @laanwj stepped down as maintainers recently. They were good at reviewing pull requests for privacy before merging.
Existing maintainers are good at different parts of code (QA, Build, GUI, Wallet and Mempool) however I am not sure about privacy.
Privacy of contributors is as important as privacy in bitcoin core. I was doxxed by a bitcoin core maintainer on GitHub, comment was deleted later although I expect better ethics and policies followed by bitcoin core maintainers.

What will be the role of a privacy maintainer?

Ensure privacy of contributors
Review a pull request for privacy impact before merging (p2p, mempool, wallet, RPC, GUI etc.)

Examples of privacy related pull requests in bitcoin core:

Examples of privacy related roles and areas in different projects/companies:

https://jobs.apple.com/en-in/details/200404681/privacy-software-engineer

https://github.com/flashbots/mev-research/blob/8a8328bd145b08259f7fde19fcad8f6c09168263/FRPs/active/FRP-10.md

Who qualifies for this role?

Passionate about privacy
Contributed in bitcoin core to improve privacy, other bitcoin projects and privacy in general
Being anon or living in a country that does not have weird regulations related to privacy would be better although not necessary

Nominees

Everyone should be free to volunteer for this role as bitcoin core is an open source project and implementation used by 90% nodes for a censorship resistant network that can be used to settle payments.

darosior commented at 4:31 pm on August 19, 2022: member

Privacy is an (important) aspect of most (all?) areas of this project, but not an area in itself. Pretty much like “DOS resistance”, or “don’t introduce bugs”. Therefore it’s not a good fit for a maintainer scope. I don’t think we should have a “privacy” maintainer, as much as a “DOS resistance” maintainer or “don’t introduce bugs” maintainer.

MarcoFalke commented at 4:45 pm on August 19, 2022: member

Almost agree with the previous comment. Though, one could say I started out as “don’t introduce bugs” maintainer, so I could also see a privacy maintainer to exist in the same sense.

However, I agree that all maintainers should have a basic set of skills such as not introducing bugs, writing good code, considering privacy aspects of changes, UX considerations, … I think that all current maintainers have those “basic” skills.

If you ask for a privacy maintainer in the areas “p2p, mempool, wallet, RPC, GUI etc.”, then that sounds more like a general maintainer to me. (Otherwise it would just be a GUI-privacy maintainer, aka GUI maintainer).

No objection to add more (general/specific) maintainers, if everything checks out.

darosior commented at 4:49 pm on August 19, 2022: member

one could say I started out as “don’t introduce bugs” maintainer

I didn’t mean this as testing/qa (which is an area in itself IMO) but fair enough. :)

achow101 commented at 4:56 pm on August 19, 2022: member

I don’t think the notion of “privacy maintainer” is a useful one. As I have stated in other comments, privacy is not a specific module in the codebase that you can point to. This scope is not very well defined in terms of the codebase (it is important to note that the scopings of maintainers is based on actual code modules and not on abstract ideas).

Furthermore, privacy can refer to many different things that are often not at all related to each other. For example, there is privacy in terms of the types of networks we use (e.g. Tor, I2P, etc.); there is node privacy in terms of leaking information about our mempool, etc.; there is wallet privacy in terms of not leaking information about other UTXOs in created transactions. None of these things have any overlap with each other other than that they involve the term “privacy”. There is no shared practical skillset. Given the very wide range of things that “privacy” refers to, I also think it is not feasible to that any one person will be an expert in all of these things. It would be more appropriate to say “Wallet privacy” or “P2P privacy”, but then really the scope is “wallet” and “p2p”, not really “privacy”.

Review a pull request for privacy impact before merging (p2p, mempool, wallet, RPC, GUI etc.)

This sounds like this maintainer would have to review every PR and have to ACK every PR before it gets merged? If so, that’s really not a good idea. It would lead to centralization around a specific maintainer and potentially lead to a lot of conflict in the review process (e.g. a new feature that is not necessarily privacy preserving, but is also something that users are likely to want).

It’s also not clear to me what a privacy maintainer would actually be doing in terms of maintenance. We add new maintainers in order to merge code in specific areas because the current maintainers are not merging code in those areas. There is no “privacy” module for a privacy maintainer to merge code into. However If a privacy maintainer is just doing review, then they’re just a reviewer, and anyone can post a review. Additionally, maintainers also do not have actionable power over other contributors or other maintainers. If a contributor violates the privacy of another contributor, what exactly is the privacy maintainer supposed to do?

Rspigler commented at 9:56 pm on August 19, 2022: contributor

I agree with Achow’s above comment. The scope is too large and it would be centralizing in effect. Keep in mind however, whoever wanted this designation - nothing stops you from reviewing any and all PRs you want from a privacy standpoint and making your ACK/NACKs known.

ghost commented at 1:15 am on August 20, 2022: none

@MarcoFalke

However, I agree that all maintainers should have a basic set of skills such as not introducing bugs, writing good code, considering privacy aspects of changes, UX considerations, … I think that all current maintainers have those “basic” skills.

Privacy should be a basic skill although some developers are better at this skill compared to others. If someone spends whole day researching about privacy, experimenting with different privacy projects etc. it would be different from other developer who spends time on other things but knows basics of privacy.

If you ask for a privacy maintainer in the areas “p2p, mempool, wallet, RPC, GUI etc.”, then that sounds more like a general maintainer to me. (Otherwise it would just be a GUI-privacy maintainer, aka GUI maintainer).

Yes it could be called as General/Privacy maintainer. @achow101

I also think it is not feasible to that any one person will be an expert in all of these things. It would be more appropriate to say “Wallet privacy” or “P2P privacy”, but then really the scope is “wallet” and “p2p”, not really “privacy”.

Agree it is difficult to be an expert in privacy of different modules. Scope could be ‘Wallet but focused on privacy" in the example. I tried expressing this in #25870 however I was suggested to open a different issue related to privacy maintainer.

It’s also not clear to me what a privacy maintainer would actually be doing in terms of maintenance. We add new maintainers in order to merge code in specific areas because the current maintainers are not merging code in those areas. There is no “privacy” module for a privacy maintainer to merge code into. However If a privacy maintainer is just doing review, then they’re just a reviewer, and anyone can post a review. Additionally, maintainers also do not have actionable power over other contributors or other maintainers.

It would be same as other maintainers who merge pull requests from different modules (i.e. general category) but focused on looking at privacy impact before merging.

If a contributor violates the privacy of another contributor, what exactly is the privacy maintainer supposed to do?

Share GtiHub policy and a privacy policy of bitcoin core project when its created with a warning to avoid this in future. Request to delete the comment.

Bitcoin Core website has a privacy policy like other websites and it could also have one privacy policy for the repositories and development: https://bitcoincore.org/en/legal/privacy/ @Rspigler

I agree with Achow’s above comment. The scope is too large and it would be centralizing in effect. Keep in mind however, whoever wanted this designation - nothing stops you from reviewing any and all PRs you want from a privacy standpoint and making your ACK/NACKs known.

Scope would be small if we had different maintainers for ‘p2p/privacy’, ‘mempool/privacy’, ‘wallet/privacy’ etc. If the idea of having more maintainers is also not worth it, we could make @DrahtBot as General maintainer that merges pull requests based on ACKs and NACKs. Maintainers would then become lead reviewers and this would also encourage more reviews as bot would consider the review history of each ACK before considering it.

MarcoFalke added the label Brainstorming on Aug 20, 2022

MarcoFalke commented at 10:42 am on August 20, 2022: member

make @DrahtBot as General maintainer that merges pull requests based on ACKs and NACKs

I think there is a risk that simply counting the ACKs/NACKs (or with some extended criteria) is going to oversimplify the process to the extent where it doesn’t help to solve any issues, but instead make it easier to corrupt it. Review is not the only criteria that goes into a merge decision. There are too many others to list them all, but for example, maintainers will also need to look out for CI/test failures (discounting the false positives and rejecting the pull on true positives). Ideally this is already done by reviewers, but as review may have happened arbitrarily long in the past, new CI/test failures or bugs may have been introduced in the meantime through silent merge conflicts. (If I had to guess, a silent conflicts happen maybe 5%-10% as much as non-silent conflicts). Moreover, if there is a public script with reproducible criteria to merge a pull requests, it makes it easier for an attacker to know exactly how many GitHub handles they need to hijack to push their malicious changes to the master branch.

bot would consider the review history of each ACK before considering it.

I think you overestimate what a bot can do. And regardless of how complicated the script is, an attacker could always just simulate/fuzz the script to conveniently minimize their resources to find the least expensive vector to inject their backdoor.

ghost commented at 1:50 am on August 21, 2022: none

I agree with last comment by @MarcoFalke however disappointed by other comments, contributors and maintainers in this repository.

It’s not just the repository but I had asked opinions about this in a few privacy groups. Everyone cares about privacy when it affects them or the project they shill as one of the group was hackathon group about privacy. Hackathon was focused on ethereum and privacy of Bitcoin is not important to the so called “privacy advocates”.

I am disappointed for 4 reasons ((i)First response was clueless and second was an attempt to fix it, (ii)others care about scoping and not the things I am trying to express, (iii) developer who suggested me to open this issue is not interested in constructive discussion about privacy and (iv)it would have been a different issue if author was someone else) in this issue but I won’t waste more time on this issue and will review each pull request myself for privacy, share feedback even if it’s not considered.

Doxxing on GitHub: I think I can manage it if it happens again.

unknown closed this on Aug 21, 2022

bitcoin locked this on Aug 21, 2023

Call for Maintainer: Privacy #25875

Why do we need a privacy maintainer?

What will be the role of a privacy maintainer?

Who qualifies for this role?

Nominees