"Shock" is perhaps the word that best describes the mood ever since one of bitcoin's most severe bugs was discovered and patched last week.

As the community reels over the vulnerability that was hiding in the code for two years, and that could have been exploited to print more bitcoins than the 21 million is hard-coded to be produced, developers are wondering: Is there a way to prevent such a severe bug from being added to the code again?

Days after the discover, there hasn't been any formal proposals. But that's not to say the event hasn't prompted discussion about how bitcoin works and how similar bugs in the cryptocurrency's most popular software implementation, Bitcoin Core, can be identified and resolved in the future.

It's an important question, too – What if a malicious actor had found the exploit first? What if there are other hidden bugs in the code right now?

To this point, pseudonymous bitcoin subreddit moderator 'Theymos' urged the community not to forget the bug.

He argued it was "was undeniably a major failure" in a widely-circulated post, adding:

That said, there's an argument to be made that Bitcoin Core, powered by an open network of global participants, now has a more robust process for code review than at any time in the technology's history.

Right now, the implementation has more developers than ever contributing to the open-source codebase. And it is tested quite a bit; by one estimate, tests make up nearly 20 percent of the codebase.

Still, developers argue more could be done to make sure the digital money works smoothly.

Theymos thinks one avenue would be to build "more sophisticated" tests tailored at locating severe, but hard to find bugs, like the one last week. "Perhaps all large bitcoin companies should be expected by the community to assign skilled testing specialists to Core," he continued, adding:

Bitcoin Core contributor James Hilliard stressed much the same, suggesting that developers can increase the "amount" and "quality" of testing. Though, this might be easier said than done. Bitcoin Core contributor Greg Maxwell agreed in Theymos's thread that testing is important, but the quality and detail of the tests is important.

"Directing more effort into testing has been a long-term challenge for us, in part because the art and science of testing is no less difficult than any other aspect of the system's engineering. Testing involves particular skills and aptitudes that not everyone has," Maxwell said.

This sort of expertise is hard to find.

"Bitcoin development is largely bottlenecked by code review and there are not a large amount of people out there who are able to do that," Hilliard told CoinDesk.

Yet, many others believe the responsibility shouldn't only rest on developers. A common sentiment shared was that as a decentralized project with no leaders, keeping bitcoin free of errors is a shared responsibility.

"My main problem with a lot of the backlash is people pointing at specific developers to assign blame. The entire project is open, there is no 'membership' and users have just as much of a responsibility to audit code as developers actively contributing," pseudonymous bitcoin enthusiast Shinobimonkey told CoinDesk.

Such a sentiment was shared by Bitcoin Core maintainer Wladimir van der Laan who tweeted, "It was wrong that the buggy code was merged. Yes, we screwed up but the 'we' that screwed up is very wide. The whole community screwed up by not reviewing consensus changes thoroughly enough."

Chaincode engineer John Newberry agreed. Even though he didn't write the buggy code, he argued that as a developer in the bitcoin world, he played a role in the error, too, by not looking closely enough.

He went as far as to say that the code in question had looked funny to him. Yet, he assumed others had already checked.

"Instead of verifying for myself, I trusted that people smarter and wiser than I am had it covered. I took it for granted that someone else had done the work," he stated.

Still, some argue there will always be a risk of bugs.

"There've been bugs in bitcoin before and there'll be bugs again. It's just software. There's nothing magical to it," tweeted Blockstream COO Samson Mow.

Along these lines, there's another popular idea floating around.

Today in bitcoin, there's one main bitcoin software, Bitcoin Core, run by 95 percent of bitcoin nodes. (At least that's according to one count – interestingly, there's no way to see every bitcoin node, because some nodes want more privacy and don't advertise their existence to the rest of the network.)

One idea, then, is to make more bitcoin code implementations. That way if one implementation has a disastrous bug that crashes the network, the other implementations could still be fine, keeping bitcoin as a whole running.

And to a certain degree, this already exists. There are lesser-known code implementations, such as Bitcoin Knots and Btcd. Elsewhere in the cryptocurrency world, this is becoming the norm. For instance, ethereum has two dominant implementations, geth and parity, each of which can be used by anyone running the software.

Still, many bitcoin developers worry that adding more than one implementation could introduce problems that would be even worse than last week's vulnerability.

"What many people do not realize is that having people run different implementations makes it easier for attackers to partition the network," Bitcoin Core contributor Andrew Chow argued in a conversation outlining the pros and cons.

As such, developers don't necessarily agree on exactly what needs to be done.

Theymos perhaps put it best when he said:

Metal shield image via Shutterstock