The origin of Bitcoin, part one
The text below is the translation of one post to reddit, which, to my surprise, went almost unnoticed. The author tells how he worked on creating Bitcoin as one of the team members, and even if he slightly exaggerated his contribution, his story seems very plausible to me. It seems to me useful to get acquainted with its history in any case, because it describes the technical solutions used in the first cryptocurrency, in their interrelation, and reveals the logic of choosing these solutions.
Good day to all.
Today is the eighth anniversary of the publication of the Bitcoin protocol description. As a special tribute to the memory, I offer you a short history of the emergence of this technology.
I left the game for many years, but now I am drawn back again - partly under the influence of the people involved, partly thanks to information that has become publicly available over the past year. I have not watched the development of Bitcoin and altcoins over the past five or six years. I left the project six months before Number 2. My last conversation with Number 2 was 5 years ago and it ended with the fact that I deleted all working correspondence and disappeared for a long time. Any mention of Bitcoin made me turn the page, switch the channel, leave the site because of the painful lump of fear arising in my stomach at any mention of this technology.
')
I write everything down as I recall, and it looks like this can make a pretty decent book about the emergence of Bitcoin.
Here you will find some of these entries. While these are rough sketches, their layout and sequence can change. Note also that the initial release of the Bitcoin code and documentation covered only a part of the earlier ideas. This means that some of the ideas described below did not become public.
Six months in a flowing boat
I have always seen that there is a big gulf between knowledge and understanding.
Everywhere I looked, I came across very smart guys who have exceptional knowledge in their field, but who have no idea how to use them, use them and how to create something new. They could only consistently repeat the same to improve their knowledge in this area. And understanding comes from experience beyond a limited area of ​​knowledge.
This story is about the most unique project and understanding that was applied to the problem of “electronic cash”, which led to the experiment called “Bitcoin”.
I try to show the flow of thought, the flow of reasoning, disputes, examples, doubts and fears that passed through our minds while we fought with this monster and tried to forge something that really works. There is no evidence of the veracity of this story. There is absolutely no evidence that I really participated in this project. All evidence was destroyed at the end of 2011 - the reason will become clear later.
Only Number 2 should have been aware of my participation in the project (so far, I mean). Think of it as fiction, if you like.
Who am I? In the network, I was known by the nickname Scronty .
I have been interested in computers and electronics since I was 11 years old. I watched what others were doing to make these cars, and tried to do a little more.
When I came across a problem, I always started with what is known about it at the moment - whatever one may say, but we all stand on the shoulders of those who were here before us. Quite often, I found that the assumptions that the people adhered to about this problem were precisely what prevented them from finding a new solution to it. I began to question the basic assumptions in different subjects:
Usually the result was only the tediousness of all these knowledgeable guys.
You can watch this on any forum from the mid-nineties. Also, you can easily meet the narcissistic wise men, who look down on others and humiliate them with their knowledge of the topic that they themselves have learned only a week ago.
In particular, all this is true in relation to the programmer and crypto forums.
A couple of guys worked with online casinos. They had a problem.
In order for players to use their service, they had to provide information about a bank card and pay for gaming tokens. However, players often began to play, lost all their money, and then rolled back the payment, arguing that it was not authorized and that they did not pay it. And sometimes the company's network handled the transfer incorrectly, the funds were debited from the player’s account, but there were no records of this on the side of the company, the player did not receive any game tokens, and, again, tried to roll back the payment. Major credit card companies prohibited their use in online gambling and began to prohibit such cancellation of payments.
These guys needed a way to transfer funds between players and casinos so that everyone can be sure of the honesty of what is happening. So that the payment could not be made by mistake, and if it was made, it could not be canceled.
Number 2 participated in a group of cipherpunks from the mid-nineties. When I joined the project in early 2008, he worked on this problem, combining this work with other projects for the past five years, for the last year or so he has been working on this full time project. He wrote a white paper describing an electronic cash system that online casinos could use (and license this system to other companies), plus wrote the corresponding code. He tried to implement a working example of electronic cash.
There were other cryptographers with whom he spoke on the subject, but all of this “just didn’t work”. There have always been many attack vectors for the solution being described and, although from a cryptographic point of view, white paper and code were acceptable, he considered them unsatisfactory. After talking with their friend Number 3, they thought that maybe the fact was that they had their eyes blurred and they should discuss their ideas with someone who was not a cryptographer. The problem was that finding the right person was not easy. He had to be smart enough to understand cryptography (or be able to study it), become interested in the subject, but not yet be a cryptographer. Usually the guys who are smart enough for this and who are interested in this are already cryptographers.
Through various IRC channels, Number 3 came to me and brought me to Number 2. Through my work in the Win32.Asm community, I showed that I was smart enough to find solutions to complex problems. Plus, my public profile showed that I stayed in the gray-white theme, was not associated with online gambling.
I was asked to take a look at white paper and say what needs to be changed there, because the code implementing it simply did not work - its parts did not combine with each other, or everything stopped working if the network did not comply with certain preconditions. Number 2 wanted to publish the documentation before the end of the year (2008).
I began to read the document - understanding very little. Hashing, encryption and decryption, and public keys, and private keys. Different types of hashing algorithms, encryption, and this hashing, hashing, and then encryption ... Oh, God!
Number 2 decided that he was wrong and he needed to try to look for someone else. I told him that he needed a different approach.
I told him that without studying this jargon I would not be able to read this document at all. And also - that as I study, I can tell him what needs to be changed. And if and when it comes to the stage in which I learned too much and my eye becomes blurred, then I will be able to leave the project and he will be able to find someone else to replace me. He agreed that letting me learn a little cryptography might be a good idea (: roll-eyes :) and told me to start.
I asked where to get the information. He replied:
He came back with a list of links and told me to look at them and read the white paper. There were 104 references in the list - [seconds].
Step by step, I began to wade through this information. A few weeks later I dealt with half a dozen articles / sites that did not clarify anything for me. Once, after three or four weeks, I told him in despair:
He returned with a list of about 23 points.
Take the computer network in which transactions are to be sent to the recipient. The initial version of white paper was to a large extent a mixture of different cryptographic white paper on the electronic cash of that time. We knew that when someone wanted to send a payment to another person, information about him should be reliably spread throughout the network. But how to solve the problem of re-spending the same funds?
A piece of paper that is paper cash can only be in one place at a time — you cannot spend a physical banknote twice. All then existing e-cash systems relied on the central server in controlling the distribution of coins and in that no coins would be spent twice.
But if this server falls or is unavailable due to DDOS or government actions (or someone just trips on the power cord) - that's all, there is no money.
We knew that coins should initially be created somehow. I found that most of the “coinage” methods described in the documents and on the sites were nonsense (this is personal opinion, no disrespect for those who wrote all these documents). They were either going to act as central banks, or they were going to allow a “club of friends,” in which everyone agrees with each other, to decide who gets the coins this time. Like politicians who use an “independent” third party to increase pay themselves. We knew that a piece of electronic cash had to be somehow created, but after it was created, how to send it to someone? Number 2 and I rushed between several ideas, examining the processing of various types of transactions one after another and adjusting to them how a package with transaction data should look like.
We started with a single piece of e-currency. Like a piece of gold, it should allow smaller pieces to split off. This meant that we moved from one piece to two parts — the parts that were sent to the recipient, and the delivery, which was returned to the original owner. I told Number 2 that when drawn as a diagram, it looks like electronic or computer logic elements.
Excluding those cases when there are more outputs than inputs. And then it looks like neural networks.
If we had a big piece and we sent all this amount to someone, then the input and output should be equal. If we had a big piece and we sent someone a smaller amount of coins, then at the entrance we have this big piece, and at the exit - the amount sent, plus a small piece as change. As we pay more and more people, we’ll get many small pieces in our wallet. If in this situation we have to pay someone a large amount, we can combine many small pieces so that we get an amount equal to or more than what we have to pay, and return the required amount as surrender. This means that the transaction should allow you to have many inputs and many outputs, each input is signed by the current owner, and the outputs are the public keys of the new owners.
Once he told me that his friend Number 3 wants to talk to me directly, but he is super paranoid, so I have to encrypt all my messages with him using public / private keys.
It was a [censored] nightmare. I had to:
All this was necessary in order to make sure that the message was really from me, and it was not intercepted or replaced.
He then decided that I should generate new public / private keys for each new message in case the past message was intercepted. I told Number 2 that this would not happen. I never liked using programs from the command line, I always thought that they should be executed from the graphical interface. I said:
Number 2 gave me a link to the information - it was in the original list of 109 documents / sites and was not in the filtered list of 23 items.
This was a link to Hal's website, where he explained very clearly how something called “Hashcash” works - Hals RPOW . From there, I went to the Adam Hashcash website (which was not on the list at all). I read the Hashcash documentation until I got to the calculations section and could not continue reading.
I read the first few sections and realized that it was something interesting. I asked No. 2 if he could check that it was the latest version, and if there were any improvements / corrections / updates. He replied that I wasted my time on this and that I should continue reading other documents / sites from the list he gave me. I told him that I know better what information is important and I need to become familiar with Hashcash. He returned a couple of days later and said that he was convinced that the published document was the latest version.
I asked how he was convinced of this? He replied that he had contacted the author of the site, Hal, and asked him for the latest version, and Hal sent the same link. He even copied Hal's answer in a letter to me.
I told him that this is a great rarity when someone checks the sources and communicates with the authors. Most reads something and takes it as a fact, or sees the link and takes it as a fact. If someone reads about the search algorithm Boyer-Moore'a, he perceives as a fact that he reads the latest official version of this algorithm. I have not heard of anyone contacting Boyer or Moore to find out if there are any corrections / improvements / updates. The Boyer-Moore search algorithm was discussed at that time on the Win32Asm community forum.
It intrigued me. Even taking into account the sometimes annoying manner of Number 2, it was very helpful to have someone willing to find out something from the authors of the material, as in this case. I asked him if he had contacted the author of Hashcash, and he replied that he sent letters to each author of all the documents / sites from the list, but only about a dozen or so answered.
I began to write down what problems arise when trying to create an e-cash system based on other e-cash systems from the documents that I studied. I still referred to the white paper that Number 2 originally gave me, but it was just an indiscriminate mix of what others have been doing for many years. That is why again nothing worked, like the others.
One of the problems was a trusted time stamp, so that people could know that the funds were not spent twice. Another problem was the “coinage” in the system and the credibility of the “minting center”.
As far as I remember, each white paper until then (including one issued to me) used a trusted third party as a source of time stamps and complex methods to make sure that these tags were not forged.
Coinage also used either a trusted third party to generate coins on a regular basis, or a network of nodes that agree on how to generate a lot of tokens and distribute them to everyone else.
Number 2 said that we should use a trusted third party, otherwise how else can we be sure about the timestamp and token tokens.
I said he thinks wrong about this.
This algorithm causes the user's computer to generate data hashes in order to find a hash with a specified number of zeros at the beginning. If the hash is not found, the program increments the value in the data and again calculates the hash. This is repeated until the desired value is found. This means that the user's computer spends some time working on these hashes and stops only when it finds the one it needs. This algorithm was developed to deal with the problem of email spam we all came across: a spammer must use a large amount of computational resources in order to generate hashes for all sent emails (the hash data includes the recipient's address, so each recipient needs separate hash). This process can be controlled in such a way that the complexity of generating a hash can increase with time as the computing power of iron develops and grows.
The problem of coinage is somewhat similar to this, since the electricity used to generate hashes can be used to coinage electronic cash and launch these coins into circulation. In fact, it turns out that how much cash is given to a specific chaser is determined by the invoice issued to him in real money (for consumed electricity). It also determines the price of mined coins, as there is a direct relationship between the electricity bill in the real world and the number of coins minted. Taking the time spent generating the hashes, the amount of energy consumed by the processor during this generation (only during the generation of hashes, and not any other calculations), as well as the local cost of electricity in the area / region / country in which the chaser is located , we get the amount of electronic cash adapted to the terrain, which will be added to his account. This meant that someone who mined coins in an area with cheap electricity due to government support should have received less e-cash because it spent less real money on generating hashes. Thus, we have a mechanism on the basis of which this electronic cash could work.
I will stop this story here and continue it depending on the reaction to this publication. In the continuation there will be some details of how the idea of ​​the block chain arose, plus some ideas that remained outside the original white paper and the original code (first of all it was just the first experiment to test the concept).
→ Bitcoin Origins - part 2
If you re-read the original Bitcoin white paper , then the parts of Introduction, Calculation, Conclusion, and References were written and edited by Number 2 and Number 3. Sections: Transactions, Timestamp Server, Proof-of-Work, Network, Incentive, Reclaiming Disk Space, Simplified Payment Verification , Combining and Splitting Value and Privacy were copied from letters from me to Number 2, explaining how each piece should work as we found these solutions. I wrote the text of the Abstract section when Number 2 asked me to write Introduction. Number 2 used it as Abstract because it decided that it was too short to introduce. Number 2 and Number 3 edited the entire document and removed all double spaces from it, added section headings, edited 2% to 5% of the text, correcting grammatical errors and improving readability. You can read the source code for the Abstract section with double spaces here: Public Mailing-list Posting
There was a serious misunderstanding between us in the process of drafting a white paper, which I will discuss next time.
Your Phil (Scronty)
Good day to all.
Today is the eighth anniversary of the publication of the Bitcoin protocol description. As a special tribute to the memory, I offer you a short history of the emergence of this technology.
I left the game for many years, but now I am drawn back again - partly under the influence of the people involved, partly thanks to information that has become publicly available over the past year. I have not watched the development of Bitcoin and altcoins over the past five or six years. I left the project six months before Number 2. My last conversation with Number 2 was 5 years ago and it ended with the fact that I deleted all working correspondence and disappeared for a long time. Any mention of Bitcoin made me turn the page, switch the channel, leave the site because of the painful lump of fear arising in my stomach at any mention of this technology.
')
I write everything down as I recall, and it looks like this can make a pretty decent book about the emergence of Bitcoin.
Here you will find some of these entries. While these are rough sketches, their layout and sequence can change. Note also that the initial release of the Bitcoin code and documentation covered only a part of the earlier ideas. This means that some of the ideas described below did not become public.
Bitcoin Origin
Six months in a flowing boat
Introduction
I have always seen that there is a big gulf between knowledge and understanding.
Everywhere I looked, I came across very smart guys who have exceptional knowledge in their field, but who have no idea how to use them, use them and how to create something new. They could only consistently repeat the same to improve their knowledge in this area. And understanding comes from experience beyond a limited area of ​​knowledge.
This story is about the most unique project and understanding that was applied to the problem of “electronic cash”, which led to the experiment called “Bitcoin”.
I try to show the flow of thought, the flow of reasoning, disputes, examples, doubts and fears that passed through our minds while we fought with this monster and tried to forge something that really works. There is no evidence of the veracity of this story. There is absolutely no evidence that I really participated in this project. All evidence was destroyed at the end of 2011 - the reason will become clear later.
Only Number 2 should have been aware of my participation in the project (so far, I mean). Think of it as fiction, if you like.
Who am I? In the network, I was known by the nickname Scronty .
I have been interested in computers and electronics since I was 11 years old. I watched what others were doing to make these cars, and tried to do a little more.
When I came across a problem, I always started with what is known about it at the moment - whatever one may say, but we all stand on the shoulders of those who were here before us. Quite often, I found that the assumptions that the people adhered to about this problem were precisely what prevented them from finding a new solution to it. I began to question the basic assumptions in different subjects:
What if it's wrong?
If this did not exist, how could it be replaced?
Usually the result was only the tediousness of all these knowledgeable guys.
"So it always was."Well, you understand.
"This is the best way to do it."
“All these titles after my name mean that I am right and you are not.”
“This is written in the book, the recommendations of which I adhere to.”
“Everyone quotes this man, he must be right, - so I will quote him too.”
You can watch this on any forum from the mid-nineties. Also, you can easily meet the narcissistic wise men, who look down on others and humiliate them with their knowledge of the topic that they themselves have learned only a week ago.
In particular, all this is true in relation to the programmer and crypto forums.
Start
A couple of guys worked with online casinos. They had a problem.
In order for players to use their service, they had to provide information about a bank card and pay for gaming tokens. However, players often began to play, lost all their money, and then rolled back the payment, arguing that it was not authorized and that they did not pay it. And sometimes the company's network handled the transfer incorrectly, the funds were debited from the player’s account, but there were no records of this on the side of the company, the player did not receive any game tokens, and, again, tried to roll back the payment. Major credit card companies prohibited their use in online gambling and began to prohibit such cancellation of payments.
These guys needed a way to transfer funds between players and casinos so that everyone can be sure of the honesty of what is happening. So that the payment could not be made by mistake, and if it was made, it could not be canceled.
Number 2 participated in a group of cipherpunks from the mid-nineties. When I joined the project in early 2008, he worked on this problem, combining this work with other projects for the past five years, for the last year or so he has been working on this full time project. He wrote a white paper describing an electronic cash system that online casinos could use (and license this system to other companies), plus wrote the corresponding code. He tried to implement a working example of electronic cash.
There were other cryptographers with whom he spoke on the subject, but all of this “just didn’t work”. There have always been many attack vectors for the solution being described and, although from a cryptographic point of view, white paper and code were acceptable, he considered them unsatisfactory. After talking with their friend Number 3, they thought that maybe the fact was that they had their eyes blurred and they should discuss their ideas with someone who was not a cryptographer. The problem was that finding the right person was not easy. He had to be smart enough to understand cryptography (or be able to study it), become interested in the subject, but not yet be a cryptographer. Usually the guys who are smart enough for this and who are interested in this are already cryptographers.
Through various IRC channels, Number 3 came to me and brought me to Number 2. Through my work in the Win32.Asm community, I showed that I was smart enough to find solutions to complex problems. Plus, my public profile showed that I stayed in the gray-white theme, was not associated with online gambling.
Request for help
I was asked to take a look at white paper and say what needs to be changed there, because the code implementing it simply did not work - its parts did not combine with each other, or everything stopped working if the network did not comply with certain preconditions. Number 2 wanted to publish the documentation before the end of the year (2008).
I began to read the document - understanding very little. Hashing, encryption and decryption, and public keys, and private keys. Different types of hashing algorithms, encryption, and this hashing, hashing, and then encryption ... Oh, God!
Just tell me what I need to change to make it work.- continued to ask me Number 2.
Yes, I don’t understand what [censored] I read- I answered.
Number 2 decided that he was wrong and he needed to try to look for someone else. I told him that he needed a different approach.
What needs to be changed?- he asked.
So, for starters, I should understand that I generally read. So give me information about all these crypto stuff.- I said.
No-no-no, if you learn this crypto jargon, you will fall under its influence and will no longer be the “non-cryptographer” that we need to check white paper.
I told him that without studying this jargon I would not be able to read this document at all. And also - that as I study, I can tell him what needs to be changed. And if and when it comes to the stage in which I learned too much and my eye becomes blurred, then I will be able to leave the project and he will be able to find someone else to replace me. He agreed that letting me learn a little cryptography might be a good idea (: roll-eyes :) and told me to start.
I asked where to get the information. He replied:
Googled.
Not. You have been working in this field for the last few years, so you can give me links to sites with the necessary info.
He came back with a list of links and told me to look at them and read the white paper. There were 104 references in the list - [seconds].
Step by step, I began to wade through this information. A few weeks later I dealt with half a dozen articles / sites that did not clarify anything for me. Once, after three or four weeks, I told him in despair:
With this speed, I spend all year with this and I still do not understand everything to the end. You must filter this information for me. You have already read all these documents and websites, so give me a list of the most important ones that will help me in understanding white paper.
He returned with a list of about 23 points.
Now list them in the order in which I need to read them.He gave me a sorted and filtered list of crypto documents and sites, which I began to read from the very beginning.
Transactions
Take the computer network in which transactions are to be sent to the recipient. The initial version of white paper was to a large extent a mixture of different cryptographic white paper on the electronic cash of that time. We knew that when someone wanted to send a payment to another person, information about him should be reliably spread throughout the network. But how to solve the problem of re-spending the same funds?
A piece of paper that is paper cash can only be in one place at a time — you cannot spend a physical banknote twice. All then existing e-cash systems relied on the central server in controlling the distribution of coins and in that no coins would be spent twice.
But if this server falls or is unavailable due to DDOS or government actions (or someone just trips on the power cord) - that's all, there is no money.
We knew that coins should initially be created somehow. I found that most of the “coinage” methods described in the documents and on the sites were nonsense (this is personal opinion, no disrespect for those who wrote all these documents). They were either going to act as central banks, or they were going to allow a “club of friends,” in which everyone agrees with each other, to decide who gets the coins this time. Like politicians who use an “independent” third party to increase pay themselves. We knew that a piece of electronic cash had to be somehow created, but after it was created, how to send it to someone? Number 2 and I rushed between several ideas, examining the processing of various types of transactions one after another and adjusting to them how a package with transaction data should look like.
We started with a single piece of e-currency. Like a piece of gold, it should allow smaller pieces to split off. This meant that we moved from one piece to two parts — the parts that were sent to the recipient, and the delivery, which was returned to the original owner. I told Number 2 that when drawn as a diagram, it looks like electronic or computer logic elements.
Excluding those cases when there are more outputs than inputs. And then it looks like neural networks.
If we had a big piece and we sent all this amount to someone, then the input and output should be equal. If we had a big piece and we sent someone a smaller amount of coins, then at the entrance we have this big piece, and at the exit - the amount sent, plus a small piece as change. As we pay more and more people, we’ll get many small pieces in our wallet. If in this situation we have to pay someone a large amount, we can combine many small pieces so that we get an amount equal to or more than what we have to pay, and return the required amount as surrender. This means that the transaction should allow you to have many inputs and many outputs, each input is signed by the current owner, and the outputs are the public keys of the new owners.
Once he told me that his friend Number 3 wants to talk to me directly, but he is super paranoid, so I have to encrypt all my messages with him using public / private keys.
It was a [censored] nightmare. I had to:
- Generate public and private keys
- Ensure that the public key is sent to a special “trusted” place so that we can assume that it is the right one.
- Use this perverted little softphone for the command line, where I give my email and a link to the public key
- Add generated data to email
All this was necessary in order to make sure that the message was really from me, and it was not intercepted or replaced.
He then decided that I should generate new public / private keys for each new message in case the past message was intercepted. I told Number 2 that this would not happen. I never liked using programs from the command line, I always thought that they should be executed from the graphical interface. I said:
You will be my filter in this project and the main channel in this team. I send letters to you, you discuss it with who you need and send me their answers. Or you send me their inquiries, and I reply through you. And what is this annoying command line softphone? What [censored] does she even do?
Number 2 gave me a link to the information - it was in the original list of 109 documents / sites and was not in the filtered list of 23 items.
This was a link to Hal's website, where he explained very clearly how something called “Hashcash” works - Hals RPOW . From there, I went to the Adam Hashcash website (which was not on the list at all). I read the Hashcash documentation until I got to the calculations section and could not continue reading.
Hashcash
I read the first few sections and realized that it was something interesting. I asked No. 2 if he could check that it was the latest version, and if there were any improvements / corrections / updates. He replied that I wasted my time on this and that I should continue reading other documents / sites from the list he gave me. I told him that I know better what information is important and I need to become familiar with Hashcash. He returned a couple of days later and said that he was convinced that the published document was the latest version.
I asked how he was convinced of this? He replied that he had contacted the author of the site, Hal, and asked him for the latest version, and Hal sent the same link. He even copied Hal's answer in a letter to me.
Wait ... what? ... You really turned to the author of the document?
Well yes. Who else to contact, if not the author?
I told him that this is a great rarity when someone checks the sources and communicates with the authors. Most reads something and takes it as a fact, or sees the link and takes it as a fact. If someone reads about the search algorithm Boyer-Moore'a, he perceives as a fact that he reads the latest official version of this algorithm. I have not heard of anyone contacting Boyer or Moore to find out if there are any corrections / improvements / updates. The Boyer-Moore search algorithm was discussed at that time on the Win32Asm community forum.
It intrigued me. Even taking into account the sometimes annoying manner of Number 2, it was very helpful to have someone willing to find out something from the authors of the material, as in this case. I asked him if he had contacted the author of Hashcash, and he replied that he sent letters to each author of all the documents / sites from the list, but only about a dozen or so answered.
I began to write down what problems arise when trying to create an e-cash system based on other e-cash systems from the documents that I studied. I still referred to the white paper that Number 2 originally gave me, but it was just an indiscriminate mix of what others have been doing for many years. That is why again nothing worked, like the others.
One of the problems was a trusted time stamp, so that people could know that the funds were not spent twice. Another problem was the “coinage” in the system and the credibility of the “minting center”.
As far as I remember, each white paper until then (including one issued to me) used a trusted third party as a source of time stamps and complex methods to make sure that these tags were not forged.
Coinage also used either a trusted third party to generate coins on a regular basis, or a network of nodes that agree on how to generate a lot of tokens and distribute them to everyone else.
Number 2 said that we should use a trusted third party, otherwise how else can we be sure about the timestamp and token tokens.
I said he thinks wrong about this.
You proceed from the fact that we need a trusted third party, simply because any article on cryptography says that it is done this way. But you also say that you cannot rely on a trusted third party, because it creates a “point of failure” with an appropriate attack vector that can drop the entire system. Do you remember Sherlock Holmes, who said: exclude all the impossible and what remains, however incredible it may be, will be true? In order for the system to work, the use of trusted third parties should be excluded. If we cannot use them, how can we do what we need?
I have no idea. Do you think that this proof-of-work that you study could somehow be used for this?- answered Number 2.
I do not know. He definitely has some opportunities for that. It is used to make sure that the data sent and received come from a known trusted source and that they have not been replaced.
This algorithm causes the user's computer to generate data hashes in order to find a hash with a specified number of zeros at the beginning. If the hash is not found, the program increments the value in the data and again calculates the hash. This is repeated until the desired value is found. This means that the user's computer spends some time working on these hashes and stops only when it finds the one it needs. This algorithm was developed to deal with the problem of email spam we all came across: a spammer must use a large amount of computational resources in order to generate hashes for all sent emails (the hash data includes the recipient's address, so each recipient needs separate hash). This process can be controlled in such a way that the complexity of generating a hash can increase with time as the computing power of iron develops and grows.
The problem of coinage is somewhat similar to this, since the electricity used to generate hashes can be used to coinage electronic cash and launch these coins into circulation. In fact, it turns out that how much cash is given to a specific chaser is determined by the invoice issued to him in real money (for consumed electricity). It also determines the price of mined coins, as there is a direct relationship between the electricity bill in the real world and the number of coins minted. Taking the time spent generating the hashes, the amount of energy consumed by the processor during this generation (only during the generation of hashes, and not any other calculations), as well as the local cost of electricity in the area / region / country in which the chaser is located , we get the amount of electronic cash adapted to the terrain, which will be added to his account. This meant that someone who mined coins in an area with cheap electricity due to government support should have received less e-cash because it spent less real money on generating hashes. Thus, we have a mechanism on the basis of which this electronic cash could work.
I will stop this story here and continue it depending on the reaction to this publication. In the continuation there will be some details of how the idea of ​​the block chain arose, plus some ideas that remained outside the original white paper and the original code (first of all it was just the first experiment to test the concept).
→ Bitcoin Origins - part 2
Small addition
If you re-read the original Bitcoin white paper , then the parts of Introduction, Calculation, Conclusion, and References were written and edited by Number 2 and Number 3. Sections: Transactions, Timestamp Server, Proof-of-Work, Network, Incentive, Reclaiming Disk Space, Simplified Payment Verification , Combining and Splitting Value and Privacy were copied from letters from me to Number 2, explaining how each piece should work as we found these solutions. I wrote the text of the Abstract section when Number 2 asked me to write Introduction. Number 2 used it as Abstract because it decided that it was too short to introduce. Number 2 and Number 3 edited the entire document and removed all double spaces from it, added section headings, edited 2% to 5% of the text, correcting grammatical errors and improving readability. You can read the source code for the Abstract section with double spaces here: Public Mailing-list Posting
There was a serious misunderstanding between us in the process of drafting a white paper, which I will discuss next time.
Your Phil (Scronty)
Source: https://habr.com/ru/post/373163/
All Articles