Bitcoin Forum

Now don't take this the wrong way. I'm not trying to prove some sort of anti-bitcoin point here. I already know that a vast majority of people (including myself) will not be able to seriously vote "Yes" in this poll. However, this question has been lingering in my mind since day one.

When a handful of people first downloaded version 0.1, we basically crossed our fingers and trusted this "Satoshi" fellow not to screw us over. This move seems to have payed off pretty well and all, but still: how many people can claim to have actually seen and felt in their very souls the proof that bitcoins are "cryptographically secure" and will be capped off at 21 million? I for one opened some of the .cpp and header files only to be greeted by a sea of vague functions, structures I'm not familiar with, and C++ libraries I have never used. Back In 2009 I'm sure most users were similarly overwhelmed. By now out of the many thousands there must be at least a handful of programmers skilled and persistent enough to stubbornly sit through the whole darn program. I would really like to hear responses from some of them. Thank you.

This is a misleading question.

You could break the poll down into modules or sections of the code and see how many people had understood every line of each section. No one person need to have looked over/understood every line as long as many people had understood each piece ... unless there was a way to slip something in the cracks.

I've spent a fair amount of time looking at aspects of the code that had relevancy to my needs.  I've written custom patches to achieve functionality I needed.

I have NOT looked seriously at all lines of the code.

I'm in the comp sec field and a review of this code by a reputable company would cost around $60k USD --> @mtgox high (11 usd) --> 5455 btc.  Maybe someone could put together a bounty :-p

I see your point and I was kind of expecting a response of this shade. I thought of including several choices, but then I would have to dilute this poll with subjective options like "No. But I have understood most of it" and "No. I have read most of it but only understood a small portion" and "I got the gist of the source files but none of the headers". Or a whole bunch of options for different sections of code and one for those who do not know any C++. Alright, so maybe this would be the better way to go, but that's not what's important. I mostly started this thread to hear from those rare savants who can wrap their minds around the entirety of a program. Guys who are real geniuses like Satoshi Nakamoto must be. So far the closest I've heard was Gavin Andresen in "Making Money" saying "I'm a geek, I understand this stuff".

i've carefully read about 40% of the code of the c++ peer, particularly the networking code because that's one area where even good programmers commonly make mistakes. i haven't found anything of note other than denial-of-service attacks that satoshi was already aware of. that said, i did not notice the overflow bug in the transaction-verification code before it affected the block chain, and i should have done because i had looked carefully at that function.

i've looked at most of mike's java code as well, though in a more cursory fashion.

hal finney one said he reviewed much of the c++ peer's code. i forget how long ago that was, but i'm pretty sure he said it publicly.

I have read most of the crypt implementation but thats about it.

Hss anybody done any fuzz-testing? Both valid protocol and invalid stuff?

i've seen little evidence of it myself.

more intelligent denial-of-service attacks are not difficult. for example, off the top of my head, you could send many transactions with invalid signatures, tying up the cpu of peers.

attacks just lead to an arms race between the developers and the attackers. in principle they should be easy to address, but principle is not always the same as practice. in practice, i'm not sure what would happen in the event of coordinated distributed attacks, in part because developing for bitcoin has a learning curve greater than for most similar projects; there are maybe a dozen of us who could respond quickly. and the work might be asymmetric: it might be easier to mount attacks than to develop countermeasures, practically speaking.

because people here are loathe to find any fault with bitcoin and routinely impugn the motives of those who point them out, i feel like i should directly quote satoshi on this, from his last message in the forum:

fault finding is good, it is open source after all, bug reports are welcome, intentions to fix things are extra welcomed.

I would like to see a code review of the client done. But the problem is that it's invalid with each new version. How do we know that the next version won't have a feature that sends the (amazing) Bitcoin devs all the coins of 0.01% of users? Or that the released binaries match the source?

At this point, I don't think that any one person has looked at all of the code.  But, for any given section, several people have looked at it.

And there are quite a few people that inspect each and every change that gets pulled into the main branch.  An actual attack would need to be very subtle to get in.

Even if you had a bunch of people reviewing the changes, this simply means you can't put it all in one single update. If you spread malicious changes out and disguise them within real applications, you can slowly build the skeleton of an attack.

Do I understand the General Proof of Fermat's Last Theorem? (http://en.wikipedia.org/wiki/Fermat%27s_Last_Theorem#Wiles.27_general_proof)?

Hell no.

Do I believe this proof is correct? Yes.

Why? Because mathematicians are competitive, and there is a huge motivation for trying exposing a hole in this proof.

Same with the Bitcoin source code. The more famous Bitcoin becomes, the more confident I am that it doesn't have any security holes.

These are two different questions.

It's not really necessary to personally read every single line of code in order to ensure that some single function does what is intended. It IS necessary to know how to use grep, though. :)

In this case I've examined the relevant code, and I can say that (in the current source) the subsidy does indeed halve every 210,000 blocks and because of the manner in which it's halved, will indeed eventually be cut to zero.