The hunt for Satoshi Nakamoto may never be complete. Personally, I’m at place where I’m comfortable letting things lay. My comfort is derived, in part, from my most recent find, which I believe helped Satoshi design the Bitcoin system.

In short, I found a scholarly article from the late 1960s entitled Simulation of Traffic Flows in a Network. I believe said article directly inspired Bitcoin’s design.

Several items jump out at me from the article. I’ve divided the items into numbered sections below, but those section numbers do not correspond to numbers within the article. Sections 2 through 5 here are direct quotes from the article. There may be OCR errors impacting the transcription. Finally, this article is a short paper and is contained in a volume of papers written by academic engineers — it was not a stand-alone paper like Satoshi’s white paper. The 1969 article is a revision of a previous draft and it only contains three citations. There are but a handful of articles citing this paper. [1].

To be clear, I’m not suggesting I’ve identified Satoshi, but I am suggesting that I believe I’ve found something that significantly inspired Satoshi in creating the Bitcoin protocol.




I will save the remainder letters for another post.


A computer simulation program which deals with traffic flows in the network of a large area is described. Each road is segmented into blocks of several ten-meter lengths and is represented by a bidirectional list in computer memory. The movement of cars, i.e. the transfer of cars from one block to the next, is expressed by a proper formula. This formula is based on the supposition that the speed of cars in a block is determined only by the density of cars in the block, and this speed-versus-density curve is empirically given the numerical values.
This simulation scheme has its excellent point in that it makes it possible to trace the dynamic behavior of traffic flows in a variety of situations, some examples of which are given for an actual area of the city of Kyoto, Japan.
KEY WORDS AND PHRASES: traffic simulation, traffic flow, traffic network traffic control, traffic density, intersection, signal setting, vehicle, road network, list structure, computer simulation


3. Representation of Traffic Network by List Structure
3.1 BIDIRECTIONAL LIST STRUCTURE. A complicated road network, which is segmented into blocks as mentioned above, is best represented by list structure. By the adoption of this technique any network, however complicated it may be, can be accepted and stored in computer memory, and moreover this can be done very economically.
The list structure adopted here is a bidirectional one, so that the trace of a road can be initiated from any point.
This is illustrated in Figure 5.
Each arrow indicates the link from one block to the next. The circles at an intersection have no information as to the traffic situations but are only the links to every adjacent block. The blocks adjacent to the circle at an intersection have all the information about the intersection, such as signal setting, and the ratios of left-turn, right-turn and straight ahead cars; and so are to be distinguished from the blocks between intersections. The squares at the ends have parameters of vehicular arrival rates.

p. 313–14

4. POISSON (diagrams omitted)

At the end of a list structure, that is, at the input and output sections, the following form is adopted.
L or R is the link address to the other block (inlet). Q and V are provided for the calculation of the number of cars at the outlet. X is a parameter of Poisson distribution, and w is a multiplying factor depending on the road width.
At the intersections of three branches, the above mentioned four branch structure is utilized. Here parameters for a direction, such as p, B, E, are set at zero. The treatment of left-turn and right-turn prohibitions is just the same. The intersections of five or more branches are not treated here, but similar structures as shown above can be used.

p. 314


4. Parameters Representing Traffic Situations
One of the important and difficult problems of the traffic simulation is to find suitable parameters which exactly reflect the traffic situations and which people can understand easily. Moreover, these may be better if they are used as control parameters of the traffic flow. The following parameters are considered by our simulation.
First the number of cars flowing into and out of the specified area must be known. Therefore at each inlet and outlet, the average number of cars flowing in (and out) during a few minutes is recorded. The total number of cars in all the inlets (and outlets) averaged over a few minutes must also be recorded.
Next the average density of cars in the specified area is a good index. This is obtained by ~q~/~Q~. This index will be very useful when ~ is for the blocks of the main arteries.
The average speed of cars in the specified area at a certain moment is another good index. It may be better for this to be averaged over a few minutes. Queues at intersections are important measures, which can be most easily compared with the actual traffic situations.
Test car driving is often performed to see the effect of signal settings. By our simulation experiment an injected test car with a certain position counted from the front car of the block is memorized in a block, and with the transfer of cars to the next block the position of the test car is moved to the front of the next number of the cars transferred. In this way a test car is moved from one certain point to another enough times so that averaged time of travel between the two points is reliable. The test car performances for the main arteries are good measures of the traffic situation.

pp. 314–15


The article contains only 3 citations, one of which is to a prior paper by the authors (on storing traffic map data).

One of the cited articles that caught my eye is by M.C. Stark and was published in 1961 as a Technical Note by the National Bureau of Standards (U.S. Dept. of Commerce). The name of the article is Computer Simulation of Street Traffic.

A working simulation model of a particular, fairly complex traffic location has been constructed. A computer program causes the cars to behave in what seems to be a realistic manner. The cars stop at red lights; they yield the right of way at stop signs; they maneuver into correct positions for turns; they move at different speeds; they accelerate and decelerate; faster cars shift lanes to overtake slower cars; they form queues; and they do most of the definable things that cars can be expected to do in city traffic.
The results in no sense indicate a rigorous validation of the model. Up to the present point, reasonableness is the only criterion for judging the performance. Approximately the correct number of cars are accounted for at key points; their characteristics as to speed category, type of vehicle and intended turns correspond with known input data; their average running times are expectedly somewhat slower than that required to keep up with the progressively timed traffic lights.
It may be significant that the speeds and running times become slower as the simulation progresses from cycle 1 to cycle 2 to cycle 3. Although the model was “filled” with cars before the beginning of the run, it had been filled just prior. The lengthening of the running times may be caused by the fact that the full effect of congestion takes a little while to set in.
To get more information bearing on the validity of the model, two steps may still be taken. One is to study the movie display carefully to see whether a “helicopter” view of the cars verifies that they are performing correctly. The other is to compare the simulation running times with actual running times from the field, perhaps by a field check of license numbers of cars traversing the course or by a series of runs through the course using the “floating car” method. (In the latter method, a test car is driven through the course a number of times with the driver trying to drive neither faster nor slower than the average car in the traffic stream. )
A point worth bearing in mind is that even though the simulated running times may not be entirely valid in total, a difference in running time to reflect a changed parameter may be highly significant. The reverse is also true. A particular detail of the simulation may not check completely with reality and yet the total result can still furnish a useful measure. Ideally the simulation would correspond with reality both in detail and in total, but it has value even if one of these objectives is not immediately accomplished.

pp. 7–8

Stark’s study utilized IBM technology to conduct the study:

The basic working program for the IBM- 704, including the working constants and the input parameters, contains about 6000 words. In addition, the “A” layout (two words for each of about 1800 UBs) uses about 3600 words and the “B” layout another 3600. (The “A” and “B” layouts are defined in Chapter 8. ) A table look-up of the coordinates of each UB and traffic signal for presentation by SEAC on the oscilloscope uses about 3700 words. The total requirement thus is about 16, 900 words. The 704 installation at NBS has 32, 768 words of primary core storage so that no effort to conserve space was necessary. The computer program was assembled using the SAP assembly program. The final production run representing four minutes of real time required 60 minutes of 704 time. Thus the ratio of computer time to real time was 15 to 1. In order to display all of the 13th Street test course simultaneously in as much detail as possible on the oscilloscope it was found desirable to break 13th Street into two pieces. The first piece, from Euclid Street to Irving Street, appears in the left half of the display and the second piece, from Irving Street to Monroe Street, in the right half. (See Fig. 4.)

p. 10


I do not think they are Satoshi. Again, I think Satoshi was inspired by this article in the same manner he migh thave been inspired by other people, articles and technologies, such as Hash Cash (A. Back), BitGold & Secure Property Titles (N. Szabo), and Zooko’s Triangle (Zooko).

Like what you read? Give Felt a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.