Can someone post an accurate précis please so I can bluff my way through this question the next time I'm asked?
It's 9 pages... how lazy are you?
And some of those 9 pages have pictures!
Topic: Poll: How many of you did actually read Satoshi's paper? - page 2. (Read 3108 times)
It's 9 pages... how lazy are you?
And some of those 9 pages have pictures!
Can someone post an accurate précis please so I can bluff my way through this question the next time I'm asked?
It's 9 pages... how lazy are you?
You have to understand concepts like hashing and basic cryptography, so it's not an easy read without at least some programming background; but otherwise don't be too intimidated about it, it is in fact pretty short and not that hard to digest. The paper itself doesn't go into much detail, though, I feel like if I truly wanted to understand how it works I would still have to dig into the source code. I guess I'm doing that some day.
it's easy to read and understand than many news.
This thread is full of awesome. I was actually planning on reading the paper tonight, my first night of holidays 
I'll probably go through those mailing lists as well.
EDIT: Well, I just read it and I'm thoroughly surprised. People weren't kidding when they said it had very little technical jargon it in. It's pretty easy to follow for the most part, still glad I finally got around to reading it. Also, voted yes
I'll probably go through those mailing lists as well.EDIT: Well, I just read it and I'm thoroughly surprised. People weren't kidding when they said it had very little technical jargon it in. It's pretty easy to follow for the most part, still glad I finally got around to reading it. Also, voted yes
I'm quoting this wonderful piece of text from the mailing list:
Quote
James A. Donald wrote:
> It is not sufficient that everyone knows X. We also
> need everyone to know that everyone knows X, and that
> everyone knows that everyone knows that everyone knows X
> - which, as in the Byzantine Generals problem, is the
> classic hard problem of distributed data processing.
The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll
try to rephrase it in that context.
A number of Byzantine Generals each have a computer and want to attack the
King's wi-fi by brute forcing the password, which they've learned is a certain
number of characters in length. Once they stimulate the network to generate a
packet, they must crack the password within a limited time to break in and
erase the logs, otherwise they will be discovered and get in trouble. They
only have enough CPU power to crack it fast enough if a majority of them attack
at the same time.
They don't particularly care when the attack will be, just that they all agree.
It has been decided that anyone who feels like it will announce a time, and
whatever time is heard first will be the official attack time. The problem is
that the network is not instantaneous, and if two generals announce different
attack times at close to the same time, some may hear one first and others hear
the other first.
They use a proof-of-work chain to solve the problem. Once each general
receives whatever attack time he hears first, he sets his computer to solve an
extremely difficult proof-of-work problem that includes the attack time in its
hash. The proof-of-work is so difficult, it's expected to take 10 minutes of
them all working at once before one of them finds a solution. Once one of the
generals finds a proof-of-work, he broadcasts it to the network, and everyone
changes their current proof-of-work computation to include that proof-of-work
in the hash they're working on. If anyone was working on a different attack
time, they switch to this one, because its proof-of-work chain is now longer.
After two hours, one attack time should be hashed by a chain of 12
proofs-of-work. Every general, just by verifying the difficulty of the
proof-of-work chain, can estimate how much parallel CPU power per hour was
expended on it and see that it must have required the majority of the computers
to produce that much proof-of-work in the allotted time. They had to all have
seen it because the proof-of-work is proof that they worked on it. If the CPU
power exhibited by the proof-of-work chain is sufficient to crack the password,
they can safely attack at the agreed time.
The proof-of-work chain is how all the synchronisation, distributed database
and global view problems you've asked about are solved.
> It is not sufficient that everyone knows X. We also
> need everyone to know that everyone knows X, and that
> everyone knows that everyone knows that everyone knows X
> - which, as in the Byzantine Generals problem, is the
> classic hard problem of distributed data processing.
The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll
try to rephrase it in that context.
A number of Byzantine Generals each have a computer and want to attack the
King's wi-fi by brute forcing the password, which they've learned is a certain
number of characters in length. Once they stimulate the network to generate a
packet, they must crack the password within a limited time to break in and
erase the logs, otherwise they will be discovered and get in trouble. They
only have enough CPU power to crack it fast enough if a majority of them attack
at the same time.
They don't particularly care when the attack will be, just that they all agree.
It has been decided that anyone who feels like it will announce a time, and
whatever time is heard first will be the official attack time. The problem is
that the network is not instantaneous, and if two generals announce different
attack times at close to the same time, some may hear one first and others hear
the other first.
They use a proof-of-work chain to solve the problem. Once each general
receives whatever attack time he hears first, he sets his computer to solve an
extremely difficult proof-of-work problem that includes the attack time in its
hash. The proof-of-work is so difficult, it's expected to take 10 minutes of
them all working at once before one of them finds a solution. Once one of the
generals finds a proof-of-work, he broadcasts it to the network, and everyone
changes their current proof-of-work computation to include that proof-of-work
in the hash they're working on. If anyone was working on a different attack
time, they switch to this one, because its proof-of-work chain is now longer.
After two hours, one attack time should be hashed by a chain of 12
proofs-of-work. Every general, just by verifying the difficulty of the
proof-of-work chain, can estimate how much parallel CPU power per hour was
expended on it and see that it must have required the majority of the computers
to produce that much proof-of-work in the allotted time. They had to all have
seen it because the proof-of-work is proof that they worked on it. If the CPU
power exhibited by the proof-of-work chain is sufficient to crack the password,
they can safely attack at the agreed time.
The proof-of-work chain is how all the synchronisation, distributed database
and global view problems you've asked about are solved.
I found that mailing-list thread to be as good a read as the white-paper. A must-read in bitcoin-land, IMO.
Edit: The whole thread, starting with: http://www.mail-archive.com/cryptography%40metzdowd.com/msg09959.html
Agreed. His explanation of the blockchain is classic for its conciseness:
http://www.mail-archive.com/[email protected]/msg09997.html
It is actually quite interesting on a number of levels.
Normally such a paper would be frowned upon, because most of the citations are at least 10 years out of date and as for going back to 1957 for reference material... very dodgy..... esp. as there has been a lot of work in probability theory since then.
It is as if the citations were 'thrown' in as an afterthought with an underlying lack of research.
Normally such a paper would be frowned upon, because most of the citations are at least 10 years out of date and as for going back to 1957 for reference material... very dodgy..... esp. as there has been a lot of work in probability theory since then.
It is as if the citations were 'thrown' in as an afterthought with an underlying lack of research.
Yeah, the 1957 one was supposedly the probability textbook he used, it's like saying:"I happened to have this book on my desk so that's what I used", he didn't make any attempt to put up any pretense to make it look better.
It is actually quite interesting on a number of levels.
Normally such a paper would be frowned upon, because most of the citations are at least 10 years out of date and as for going back to 1957 for reference material... very dodgy..... esp. as there has been a lot of work in probability theory since then.
It is as if the citations were 'thrown' in as an afterthought with an underlying lack of research.
Normally such a paper would be frowned upon, because most of the citations are at least 10 years out of date and as for going back to 1957 for reference material... very dodgy..... esp. as there has been a lot of work in probability theory since then.
It is as if the citations were 'thrown' in as an afterthought with an underlying lack of research.
Satoshi has got a unique writing style, on one hand he is very concise and to the point, my favorite:"The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes." On the other hand he is not as rigorous as many academics when it comes to language, and he didn't easily throw around terminologies and jargons, like he can't be bothered with it. I am not sure if he invented this writing style as a camouflage and if not, how difficult it is to use pattern-matching to uncover his real identity(not that I want to).
Satoshi trivia: he wrote Bitcoin's code and THEN he wrote the paper.
Quote
http://www.mail-archive.com/[email protected]/msg09980.html
I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every
problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec.
I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every
problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec.
I found that mailing-list thread to be as good a read as the white-paper. A must-read in bitcoin-land, IMO.
Edit: The whole thread, starting with: http://www.mail-archive.com/cryptography%40metzdowd.com/msg09959.html
Satoshi trivia: he wrote Bitcoin's code and THEN he wrote the paper.
Quote
http://www.mail-archive.com/[email protected]/msg09980.html
I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every
problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec.
I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every
problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec.
somehow voted no 
-> yes!
-> yes!
It's a genius work. The real question is the following: who didn't read YET the fundational paper of BTC? Go read it, then.
Yep, and so should everyone else. It's pretty easy to understand and gives you an insight into how the fundamentals work.
I repeatedly read this paper, and it's a masterpiece.
I have read it, and I imagine that a high percentage of the people who spend time in this forum have read it, but do we expect all future users of Bitcoin to read it? Do most people read the terms of their credit card agreement, or even their mortgage? Do they read all the warnings that come with their computer?
Read it said Damn got interested
Haven't read it yet but will be in the next couple weeks.
Jump to: