In one [0] of his emails to Mike Hearn [1] Satoshi Nakomoto wrote that he worked on Bitcoin for two years before releasing the paper and code:
> I must admit, this project was 2 years of development before release, and I could only spend so much time on each of the many issues.
His emails to Hearn and others make clear that his creative process consisted mainly of writing code until he was convinced things worked. In my opinion, Satoshi Nakomoto was a lone hacker.
Prescient words from Mike Hearn.
Satoshi maintains anonymity, by choice. Therefore, any information about Satoshi's identity, directly stated or inferred from things said by them, logically have to be treated as unreliable. With the goal of remaining anonymous, Satoshi has nothing to gain and a lot to lose from providing true information about themselves. It is in their interest to not provide any information about themselves, and for any information that is provided them be inaccurate.
None of this casts any aspersions on either Bitcoin or Satoshi.
Ah heck, I sound like Vizzini. Maybe I should just drink the damn wine ;)
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.
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 how maligned Windows programmers were in 2008. I felt like a black sheep getting my start in the gamedev industry, because if you wanted to do Big League Programming in gamedev, that meant one thing: Windows. Microsoft has finally made some inroads in hacker culture. It's far less common now to be dismissed as less talented just because you used Windows. But in 2008 this feeling was very much alive.
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 ;)
The bitcoin code looks and feels a lot like of their projects but could easily be some NSA programmers side project.
Any hacker can tell this was a one person project from looking at the 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 me that says a couple of things. One is that Satoshi is one, normal, human. Another is that he is very human. For example, a lot of the OP codes have had to be disabled because they were totally insecure. In early versions of bitcoin there were bugs that allowed anyone to spend anyone's bitcoins, and so forth.
Not that I mean to attack Satoshi, he was a good coder who started what could become a revolution. But he was a human like the rest of us, and it shows.
What is it about his code that makes you consider it brilliant and production ready?
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.
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?
About 20 years ago I was interested in environmentalism. I was persuaded by arguments that humanity was damaging the environment because of the system of money it used, in which sustainably managing a forest might be profitable at, say, interest rates of 2%, but if interest rates went up to 5% then the rational thing to do was clear cut the forest and invest the returns.
This led me to a book called The Future of Money by Bernard Leitaer. This book talked about "community currencies". The idea you could design currencies to achieve particular social goals was very interesting to me. The book referenced a publication called the International Journal of Community Currency Research. This organisation turned out to have a Yahoo Group, which I joined. I felt that if there were other people discussing this idea, they would surely be found on the internet.
One day the Yahoo Group received a mail talking about a project called Ripple. This was an initiative by Ryan Fugger to create a system that could locate and manage debt in a decentralised way. It proposed an economic system without cash, in which all payments were in the form of debt in whatever units people found convenient (dollars, hours of work, loaves of bread baked etc). So I joined the Ripple mailing list too, and engaged in much fruitful discussion with Ryan about the nature of money.
The Ripple mailing list eventually received a mail that pointed to the bitcoin website and suggested we check it out. This was a few months after the project was launched. I did so, and started emailing Satoshi.
I don't know how Satoshi remained anonymous for so long. I suspect that if his identity is ever revealed, people will think: it was so obvious? Why didn't anyone see that? When the operator of the Silk Road was revealed, it turned out he'd made basic and obvious errors very early on and anyone could have figured out the Dread Pirate's identity through basic web searches. But only the FBI actually bothered to do it. I suspect Satoshi hasn't been looked for as thoroughly as people tend to imagine.
I discussed Bitcoin's scaling extensively two years ago. You can find those discussions on my blog if you like. Nothing has changed and I have nothing further to say on the matter.
>The fundamentals are broken and whatever happens to the price in the short term, the long term trend should probably be downwards. I will no longer be taking part in Bitcoin development and have sold all my coins.
That was written back in January 2016. I think you were wrong about that.
The statement about the price was deliberately vague ("long term", "should probably") because the Bitcoin price hasn't reflected the fundamentals for a very long time. You can't go straight from "this project is broken" to "thus the price will fall" because it's not an informed market, because of the large quantity of shady exchanges and so on. Take a look at what's been going on with Bitfinex to get a flavour.
If you assume that eventually, one day, reality re-asserts itself, then the price should come to reflect the systems actual utility, which is very low. But you know the old saying about how markets can remain irrational longer than you can remain solvent? I wouldn't try shorting BTC regardless of how much you know about it.
He used the cryptography mailing list. Then the P2P forums.
I highly recommend reading through the archives. There are several good observations to make there, like how scaling was basically the first issue he addressed (or failed to address, depending on your view).
Another interesting thread: https://bitcointalk.org/index.php?topic=1347.msg15121#msg151...
i wonder if stylometry could be (was?) applied to C++ code to have better evidence about authorship?
Most code produced is not open source.
But given he open sourced Bitcoin, he may have open sourced something else.
Code style does change over time, I know mine has. But I wonder if there are invariants as well. That would be a fascinating research project.
(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.
That's not true. Few people use the wallet included in the Bitcoin node, most people use nodes indirectly to broadcast transactions and sync the blockchain.
Even if you don't personally keep your coins online, a hacker that scores a million coins on a zero day is enough to plunge the value for a long time. You still lose either way.
The point is that this hasn't happened. Even though it sort of should have. That's remarkable.
You mean like the IETF?
"Rough consensus and running code"
It's been done before... for example, djb
It took 8 years before the first bug was found in these projects.
I highly recommend reading through the guidelines in https://cr.yp.to/qmail/guarantee.html for how to write secure software. In particular point 5, Don't Parse, is broadly applicable and under appreciated. A well-known class of bugs arising from this error are SQL injection attacks.
All the cryptocurrencies built on top of techniques that worked on other cryptocurrencies. I really like the iteration speed as well as how non-finite any limitation today is.
For example:
Multisignature transactions are just becoming available. The lack of multisignature made it a non-starter for many applications, including on darknet marketplaces, because rudimentary escrow or deposits were needed. When the operator goes down, all your funds are on their server and are gone with it, but with multisignature as seen in bitcoin and ethereum, you always have control of your funds and they are never in limbo.
Meta-assets are not possible yet. Asset creation is one of the big tenants of Ethereum right now, and there are many assets on bitcoin as well for even longer. Many organizations use this as a way to raise capital, bringing in a lot more capital into the base currency's economies. Monero and crypto note doesn't have this capability yet, but being able to issue and hold balances of these privately, with audit capabilities, will be powerful.
2nd layer scaling solutions are not even on the roadmap yet in any crypto note network. Cryptonote has the same scaling problems as bitcoin or ethereum, but the key sizes accelerate that. Cryptonote coins have dynamic block sizes already, but it may react too slow to really help periods of many transactions. Monero already encounters this issue. Bitcoin style cryptocurrencies have Lightning Network via Segwit. Ethereum has Raiden on the roadmap.
(HN hides the email field in your profile, so if you want to make it publicly visible you'll have to put it in your profile's "about" field.)
The same criticisms exist as since Zerocash was just a white paper.
I will say that there is the possibility that they can make the optional opaque transactions the more ready option, but you can look at the blockchain and see that nobody uses those addresses. Zerocash is just a bitcoin clone if you don't use the opaque addresses.
And Zerocash wasn't just a white paper, it was peer reviewed and analyzed by security and cryptography experts.
Not sure what you are trying to say about the papers. I saw they were academic and theoretical.
The academic paper you refer to had both a theoretical construction and an implemented system.
My favorite is:
IMPLEMENT_SERIALIZE
(
READWRITE(prevout);
READWRITE(scriptSig);
READWRITE(nSequence);
)
Ohh, no, I take it back. This is my favorite:
//
// Compact size
// size < 253 -- 1 byte
// size <= USHRT_MAX -- 3 bytes (253 + 2 bytes)
// size <= UINT_MAX -- 5 bytes (254 + 4 bytes)
// size > UINT_MAX -- 9 bytes (255 + 8 bytes)
//
inline unsigned int GetSizeOfCompactSize(uint64 nSize)
{
if (nSize < UCHAR_MAX-2) return sizeof(unsigned char);
else if (nSize <= USHRT_MAX) return sizeof(unsigned char) + sizeof(unsigned short);
else if (nSize <= UINT_MAX) return sizeof(unsigned char) + sizeof(unsigned int);
else return sizeof(unsigned char) + sizeof(uint64);
}
Again, it's a small thing -- very standard tactic. But there are dozens of tiny, effective decisions exactly like this all throughout the codebase.
There's a secure allocator for wiping your private key so that it doesn't hang out in memory, with hacks to work around MSVC8 problems. Which academics bother with MSVC8 hacks?
//
// Allocator that clears its contents before deletion
//
template<typename T>
struct secure_allocator : public std::allocator<T>
{
// MSVC8 default copy constructor is broken
typedef std::allocator<T> base;
typedef typename base::size_type size_type;
typedef typename base::difference_type difference_type;
typedef typename base::pointer pointer;
typedef typename base::const_pointer const_pointer;
typedef typename base::reference reference;
typedef typename base::const_reference const_reference;
typedef typename base::value_type value_type;
secure_allocator() throw() {}
secure_allocator(const secure_allocator& a) throw() : base(a) {}
~secure_allocator() throw() {}
template<typename _Other> struct rebind
{ typedef secure_allocator<_Other> other; };
void deallocate(T* p, std::size_t n)
{
if (p != NULL)
memset(p, 0, sizeof(T) * n);
allocator<T>::deallocate(p, n);
}
};
case OP_EQUAL:
case OP_EQUALVERIFY:
//case OP_NOTEQUAL: // use OP_NUMNOTEQUAL
{
// (x1 x2 - bool)
if (stack.size() < 2)
return false;
valtype& vch1 = stacktop(-2);
valtype& vch2 = stacktop(-1);
bool fEqual = (vch1 == vch2);
// OP_NOTEQUAL is disabled because it would be too easy to say
// something like n != 1 and have some wiseguy pass in 1 with extra
// zero bytes after it (numerically, 0x01 == 0x0001 == 0x000001)
//if (opcode == OP_NOTEQUAL)
// fEqual = !fEqual;
stack.pop_back();
stack.pop_back();
stack.push_back(fEqual ? vchTrue : vchFalse);
if (opcode == OP_EQUALVERIFY)
{
if (fEqual)
stack.pop_back();
else
pc = pend;
}
}
break;
The formatting of the code in that function also puzzles you for an instant, but then you realise just how much clearer it makes it over the "lame" but "consistently formatted" alternative of
if ( )
{
....
}
else if ( )
{
...
}
....It's implemented at a higher level. For bitcoin, a 32 bit check field is appended to the data to serve as a checksum. If you want parity, I'd imagine that could be done as well.
>Confused characters in alphabet? Case sensitivity?
Some look alike letters are excluded, hence why base58 rather than base62.
That's really the only reason I was saying I liked base58. Because it removes those confusing characters compared to base64 or others.
Here is the most updated bitcoin repo: https://github.com/bitcoin/bitcoin
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 people) must have worked months or a year on this before putting it up on source control.
The code also uses irc to find seed nodes, which is amusing. It just connects to #bitcoin and assumes that some of the people in the channel are running bitcoin nodes. That's a cool way around the "What if all the hardcoded seed nodes fail?" problem. I know it's probably a standard tactic, but bitcoin integrates so many standard tactics so well in addition to its academic work.
Here it is as one gigantic file: https://gist.github.com/anonymous/b4d5d1ab333c5d6e238fdc2242...