Topic: Masters Thesis: Bitcoin - Dist. open source dev. in safety-critical software (Read 1107 times)

I wonder how much thought the core devs have given higher level software development management methods - like integrating some Distributed Scum methods for instance.
At the very least a lot of thought must've gone into making it easier to work together. I have a hard time believing the Bitcoin Core has managed to stay within acceptable risks with just a few guidelines to avoid complete hacking anarchy as seen on Github

Let's hope there'll be time for a little bit of Q&A at #Bitcoin2014 ... Though the schedule is pretty packed.

If you're talking about NemID forced on the Danish people in its entirety, actually that is one piece of crappy software that isn't open source - and not a bad example for my case. The reasoning in that case was "If our 2FA system is open source everyone can see and exploit our code!", lol.

Use a vmware image or other machine, in order that the spyware cannot do any damages.  There is a massive 'market' for this trash spyware software. So much so, that some people have a career in spyware creation.

That's true, my bank makes me use Java to gain access to my account. That same Java keeps trying to make me put that sodding Ask bar on my computer. So a bank using software that inserts spyware on your computer by default (you have to uncross the box to not get the Ask bar).

Crazy!

Even though a nuclear missile launching system might be running on Linux that doesn't mean the actual system is developed using agile methods or open source - and that is usually because it's currently considered "bad practice".

Point being: Let's see if Bitcoin can teach us anything about whether developing critical systems using agile methods and common open source practices should still be considered "bad practice".

Open source is used all the time in critical projects at some level.
(think linux, java, etc)

Startups don't really follow the "rules", they take risks and either crash and burn or make it to the moon :-) That make them poor subjects for scientific generalization though.
But yeah - it's all very relative.


Exactly - and the overall development methods are the framework for handling those situations.
The "new"(10-15 years old) agile methods(http://en.wikipedia.org/wiki/Agile_software_development for an easy read) are great at handling changing requirements, working with the customer etc. but the point about them not being suitable for safety/security-critical software is that "not sticking to the plan might get you in trouble" and that is pretty much what I will be questioning in my thesis since Bitcoin has been developed in an extremely agile way and doesn't show signs of the usual weaknesses the IS/IT literature points out - like Boehm, Barry. "Get ready for agile methods, with care." Computer 35.1 (2002): 64-69.

It's also very important to differentiate between community-written open source and software developed by a single organization that happens to publish it's code.

What is for sure though - whatever Karpelès did is the opposite of how you should develop your software ;-) Too bad I can't make my case about Gox and the crappy IS management there

Commercial projects of less than 6 months are very common in start-ups, this are usually smaller projects in order to make a quick buck. In large corporations, your point is true. You can do smaller commercial projects even in 1 month. It really all depends on the complexity of the software, skill of the coders and the size of the corporation. Do they want a simple website with functionality, or a system to maintain countrywide traffic..


In theory is a lot of difference, in practice: you spend time coding, requirements are changing along the way, customer does not know what they want, boss complains to hurry up, you type thousand lines of code, computer never listens to you (familiar to anyone?  ) your in the office every day, computer shows error screens and you get headache.

First of all: Thank you so much for taking the time for such a thorough reply!

You do misunderstand some central concepts though. What is your background?

Actually proprietary software projects aren't short in the usual sense - six months is a very short time for any piece of commercial software. A lot of open source "projects" though don't really qualify as projects in the usual sense because a project - by scientific definition - has strictly defined boundaries, either by length or resources, and open source projects usually do not have such boundaries.

Also, the Bitcoin core could have been more reliant on openSSL which could have meant every client in the world randomly spitting out private keys or a bug bypassing encryption - a lot could go wrong that would cost people billions if the code was carelessly reviewed. Obviously every piece of code pulled to the Bitcoin core has been carefully reviewed as warranted since it is indeed "critical software" - at least in a sense. And obviously it says so on the core development github page:


You also misunderstand the term "development methods" in the scientific sense which refers to how the project is managed and which defined process is used.
Open source projects are usually distributed and very agile in the sense that project members rarely work from the same location and the code is developed in iterations rather than a step at a time.
The traditional approach, that scholars like Barry Boehm have suggested is more suitable for safety-critical projects, is commonly known as the "waterfall model" and is very bureaucratic. Pretty much: Make a thorough plan, stick with it and never go back and make sure to document every tiny thing on the way - as opposed to agile methods, like Scrum, where you work in iterations.

Thanks again for your reply though - it's always nice to get a different perspective on things

P.S.
^^^That is just terrible project management! People don't get more work done by working 12 hours instead of 8 - simply ancient thinking
People interested in project management from a professional or hobbyist perspective should read Tom DeMarco's "The Deadline: A novel about project management" - it's solid science but a helluva lotta fun to read

There is a lot of trust in society, usually people do not expect bad things to happen. This was the case with the Cyprus bank collapse/theft, this was the case with NASA rocket launch that killed the pilots, train crash in Spain, the financial crisis and many more. Yes people use Bitcoin for large transactions, but people also keep large amounts of money in online banks with security similar as MtGox  . For example, how do you know the money you put in your bank will not be stolen? People step in a car each morning expecting it will not crash.  In life there are always risks, its something we have to live with (and prepare for).

Because Bitcoin is a peer-to-peer network and you control your money, the risks involved are different. There is no single point of failure in terms of the network structure. Your car has a single point of failure: its engine. The bank is a single point of failure. With crypto-currency the risks are different.

In addition, how would you transfer 10.000.000 us dollar from Swiss to the US? Its logical that Bitcoin is used for large transfers, you can make payments 24/7, anywhere in the world, almost instantenously.



Many mission/safety critical systems use open source software. Not scientific papers, but still information:
http://gizmodo.com/the-iss-has-ditched-windows-entirely-for-linux-499593441
https://www.suse.com/solutions/mission-critical-computing.html
http://blogs.windriver.com/medical/2011/11/using-linux-in-medical-devices-what-developers-and-manufacturers-need-to-know.html

Proprietary software usually has a short development time, the developers have to work full days on the project, usually get very tired; There is a short time schedule to produce, the costs are high: office costs, tax, management, administration etc. In addition, how can you know (as an outsider) the code produced is safety-critical and not a sloppy mess if it is proprietary software? People's lives are at stake and open source can be a lot cheaper.


Development methods for open source software depends. GNU/Linux, one of the biggest software project in the world communicates a lot trough a 'mailing list'. Whereas others prefer trough a chat protocol called IRC or forums.  Usually in the corporate world they prefer face-to-face meetings with the development team.

You can find some bitcoin related papers here http://arxiv.org/find/all/1/all:+bitcoin/0/1/0/all/0/1 or than the original bitcoin paper (link is on wikipedia). You may have access to ACM or IEEE database trough your university. Furthermore you may be interested in crypto-currency in general, which research dates back many years before bitcoin. There is also a recent MIT Bitcoin Expo 2014 video. Link and info on bitprize.org

Good luck with your thesis! 

Nonetheless the Bitcoin protocol is used for large transactions, even though it isn't recommended, and a complete failure could lead to loss of life or at the very least loss of property(duh!).

Any software that can lead to billions in losses should be considered safety-critical.

Do you disagree?

I disagree with you that the market-cap makes bitcoin safety critical software. Anyone reputable in the bitcoin space tells people not to put any more money into bitcoin than they are willing to lose. Bitcoin is experimental and there exists no mathematical proof that it will remain secure (although that argument can be applied to virtually every commonly used cryptographic protocol)

I think most of the bitcoin developers will tell you they wouldn't recommend using the bitcoin core software in safety critical applications.

I'm currently writing the early phases of my masters thesis in IS Management and for some reason I couldn't help but using Bitcoin as my main case ;-)

Scientifically, Bitcoin is layer upon layer of interesting topics in law, banking, economics and even social theory, but for some reason management of information systems research has left it alone completely.

Management wise Bitcoin is one heck of an experiment considering it has now reached a point where the market cap itself makes it safety-critical software, since a complete breakdown of the Bitcoin protocol might actually mean loss of life. Yeah - people could die!

My current assumption is that management scholars in general would consider using distributed open source development for safety-critical systems outright insane(nuclear power plants and aviation tech comes to mind) but Bitcoin actually seems to have made it work - and not only that - Bitcoin wouldn't stand a chance, adoption wise, if it was closed source.

I'm having trouble finding good scientific articles on the topic though as I can't seem to find much on using open source and the agile development methods except a 2011 article on IGSTK (Image Guided Surgery ToolKit) which suggests it can be done...

So, I'm pretty much at a point where any help is appreciated...

Do you know of any good scientific sources/papers to validate my assumption that using open source in safety-critical systems is crazy? Or isn't?

Do you have ideas for other ways of including bitcoin and information systems management in my thesis?

Any practical tips for researching Bitcoin from a management perspective?

Any help and open discussion appreciated!