Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bitcoin's Academic Pedigree

queue.acm.org

Post reply on HN
Print view View original

91–100 of 147 posts

Re: Bitcoin's Academic Pedigree

#91

Post by kobeya »

sillysaurus3 wrote: post #26
ChrisClark wrote: post #24

Earlier quoted context omitted.

Just clicked to check it out and was reminded about how much I like the base-58 scheme they used for addresses.

There's so much like that. I'm going to try to write a blog post highlighting all the gems. My favorite is: IMPLEMENT_SERIALIZE ( READWRITE(prevout); READWRITE(scriptSig); READWRITE(nSequence); ) It's a C++ macro that implements reading and writing member variables to/from disk/network. It uses C++ templates to figure out the sizes of everything, so it winds up packing items efficiently. We used something similar in…

No those weren't the work of a single person. You're quoting versions of the code base that post date the public introduction of bitcoin. Some of the things you call out were written by others, and others were written in response to public review.

Re: Bitcoin's Academic Pedigree

#93

Post by kobeya »

mbrock wrote: post #80
wmf wrote: post #14

Earlier quoted context omitted.

One of the points of the article is that the field wasn't idle during those 15 years; bit gold, b-money, and Finney's RPOW made incremental improvements on hashcash that led to Bitcoin. Also, Bitcoin is kind of a "dirty" solution to the consensus problem; if all the academics were looking for an elegant solution it's not surprising that they didn't discover it.

I mentioned to an academic computer scientist that I worked with blockchains. He immediately asked "So these blockchains, how do they do consensus? Isn't it some kind of majority vote?" I said "Well, kind of, in combination with economic incentives to follow the longest chain." He just said "Well, come on! That's the whole problem! That's not a solution!" or something like that. Not impressed at all!

Bitcoin does not meet the requirements identified by the academic community for a usable digital currency. On the other hand, it works (while nothing that came out of academia in this area ever has). Infer from that what you will.

It would be nice if science had a term for its equivalent of "outsider art."

Re: Bitcoin's Academic Pedigree

#94

Post by mike_hearn »

sillysaurus3 wrote: post #32
mrb wrote: post #28

Earlier quoted context omitted.

I recovered and archived version 0.1.0 (directly from Hal Finney): http://www.zorinaq.com/pub/bitcoin-0.1.0.tgz It has 19k lines of code. That's certainly a few months of work minimum. Fun fact: I was contacted by the Computer History Museum in Mountain View since this tarball (and the .rar) hosted on my site is the earliest known public copy of the source code.

Notice how all the files use \r\n for newlines. Satoshi was a Windows programmer! They used Windows . Anyone who has tried to do cross-platform development knows it's extremely difficult in C++. You can do it, but it's not a trivial thing. I guess it's no surprise that Satoshi used Visual Studio. If you start out writing code in not-Visual-Studio, it's far harder to go back and make it run on VS. I vividly remember h…

Bitcoin was originally a Windows only program. We used Wine to run it on Mac/Linux in the early days:

https://sourceforge.net/p/bitcoin/mailman/message/23827020/

I used to be a Wine developer so it didn't put me off when I first found the project, but I'm sure the fact that it was Windows only hurt the projects uptake in the first year. It wasn't until Bitcoin 0.2 that a Linux version was available.

If it helps, Satoshi was also an Outlook user ;)

Re: Bitcoin's Academic Pedigree

#95

Post by xorcist »

CyberDildonics wrote: post #59
colordrops wrote: post #39

Earlier quoted context omitted.

"asic-vulnerability" is actually an asset. If Bitcoin were mined with CPUs or GPUs, any large organization or government could just point their computing power at Bitcoin and disrupt it.

Should I really explain why that doesn't make sense? With GPUs or CPUs individuals can outweigh large organizations. With ASICs, the 'many' are far less because the barrier to entry is so high, so the many can't easily outweigh the few and centralization occurs.

CPU-, and to a certain extent, GPU-based mining is problematic because in the real world today all mining is concentrated in the hands of botnet operators.

That used to be a mounting problem in the Bitcoin world which began to fade away with the introduction of FPGA-based miners, but it's still a problem with a couple of altcoins. There are pros and cons with both compute-hard and memory-hard PoW but many seem to lean towards compute-hard being the less bad choice.

Re: Bitcoin's Academic Pedigree

#96

Post by mike_hearn »

keymone wrote: post #79
feelix wrote: post #73

Earlier quoted context omitted.

I'm curious as to why you consider brilliant, production ready code. I also read through the original codebase and I came to a different conclusion. To me it looks like something that was hacked at for a year or so, and was all just glued together. It looked like the first iteration of a codebase, the thing that you usually don't release, but then re-work so it is presentable to the outside world and then release. To…

in a codebase of tens of thousands of non trivial C++ after 8 years there was found one critical protocol bug. one . if this doesn't blow your mind - i don't know what will.

There was more than one critical protocol bug. But yes, it was an impressive effort. It used the STL well, was tightly written, and of the security bugs that did exist none were buffer overflows, stack smashes or double frees from what I recall. There were some issues in the interpreter opcodes but I think they may have been crashes (DoS).

The code was clearly the work of one person though. There were not enough comments or other forms of code documentation for it to have been a team effort, even if the Satoshi personality was a composite. The idiosyncratic code is another hint: Windows only and Hungarian notation in 2008 is not something commonly seen. The early Bitcoin code gave me the feeling of an experienced developer who learned their craft in the 1990s and had probably been around for quite a long time, but who probably hadn't worked in large professional development teams in recent years. For example, there were no unit tests. Common in the 1990s, not so much in 2008.

Re: Bitcoin's Academic Pedigree

#97

Post by xorcist »

sillysaurus3 wrote: post #20
cs702 wrote: post #2

This article correctly shows that virtually none of the ideas underpinning Bitcoin are new. They can all be traced to the academic literature going back decades. Cryptographic signatures and public-key cryptography, cryptographic hash functions, cryptographic proof-of-work, time-stamping, Merkle trees, chains of transactions blocks, Byzantine fault tolerance, smart contracts -- all of these ideas were old when Bitcoi…

I've spent a lot of time reviewing the original Bitcoin codebase. It's brilliant code. It's production-grade C++. There's nothing in it that hints at academic origins. Most people are either academics or professional coders -- to be both is a rare exception. The codebase seemed to materialize out of nowhere. One of the earliest commits in the SVN repo contains 36 thousand lines of code. "Satoshi" (or this group of pe…

It's worth repeating: This is a C++ codebase. It listens to open ports on the public Internet. One single remote exploit and you lose all your money. The author basically threw code over the wall and the open source community where contributors come and go all the time took over. And one single remote exploit is all it takes.

(This causation is perhaps less true today when it is more common to use encrypted or even hardware wallets, but before that everyone just used the standard wallet.)

Yet none of this has happened. The odds of this seems vanishingly unlikely. Then there's the risk of consensus problems that would enable double spending, which is very difficult to test for.

At the same time original Bitcoin was far from perfect. Someone wrote up a summary of important changes Hal Finney did which I can't seem to find. He pointed out a lot of problems which would have made Bitcoin not work at all which resulted in some early redesigns and the removal of many opcodes.

Parts of Bitcoin also went nowhere, notably the marketplace, pay-to-IP and payment channels. The ideas live on as Openbazaar and Lightning but completely redesigned from the Satoshi origins.

In so many ways it is an enigma.

Re: Bitcoin's Academic Pedigree

#98

Post by ploggingdev »

mike_hearn wrote: post #96
keymone wrote: post #79

Earlier quoted context omitted.

in a codebase of tens of thousands of non trivial C++ after 8 years there was found one critical protocol bug. one . if this doesn't blow your mind - i don't know what will.

There was more than one critical protocol bug. But yes, it was an impressive effort. It used the STL well, was tightly written, and of the security bugs that did exist none were buffer overflows, stack smashes or double frees from what I recall. There were some issues in the interpreter opcodes but I think they may have been crashes (DoS). The code was clearly the work of one person though. There were not enough comm…

Since you were around in the early days, how did you get involved with Bitcoin and how did Satoshi get people interested in it since he was anonymous and did not have any social media following or email list?

It's incredible that he has managed to stay anonymous for so long, how on earth did he manage to do that?

Any thoughts on the scaling debate?

Re: Bitcoin's Academic Pedigree

#99

Post by keymone »

mike_hearn wrote: post #96
keymone wrote: post #79

Earlier quoted context omitted.

in a codebase of tens of thousands of non trivial C++ after 8 years there was found one critical protocol bug. one . if this doesn't blow your mind - i don't know what will.

There was more than one critical protocol bug. But yes, it was an impressive effort. It used the STL well, was tightly written, and of the security bugs that did exist none were buffer overflows, stack smashes or double frees from what I recall. There were some issues in the interpreter opcodes but I think they may have been crashes (DoS). The code was clearly the work of one person though. There were not enough comm…

interesting points, thanks. also thanks for your contributions to the project.

i wonder if stylometry could be (was?) applied to C++ code to have better evidence about authorship?

Re: Bitcoin's Academic Pedigree

#100

Post by seanwilson »

xorcist wrote: post #97
sillysaurus3 wrote: post #20

Earlier quoted context omitted.

I've spent a lot of time reviewing the original Bitcoin codebase. It's brilliant code. It's production-grade C++. There's nothing in it that hints at academic origins. Most people are either academics or professional coders -- to be both is a rare exception. The codebase seemed to materialize out of nowhere. One of the earliest commits in the SVN repo contains 36 thousand lines of code. "Satoshi" (or this group of pe…

It's worth repeating: This is a C++ codebase. It listens to open ports on the public Internet. One single remote exploit and you lose all your money. The author basically threw code over the wall and the open source community where contributors come and go all the time took over. And one single remote exploit is all it takes. (This causation is perhaps less true today when it is more common to use encrypted or even h…

I'm super curious why C++ was chosen when the risks are so high. Performance?
Post reply on HN