Quote from: Spendulus on June 04, 2018, 10:52:04 PM

Quote from: AverageGlabella on June 04, 2018, 08:04:49 PM

I've been reading some old posts of some prolific members here on the forum and here's a quote from DeathAndTaxes to seek your teeth into:

Quote from: DeathAndTaxes on May 10, 2013, 06:16:50 PM

This. The first time I learned about Bitcoin, I took a look at the whitepaper and code I found all kinds of "flaws". It wasn't until hours (days?) of reading and researching that the elegance of the solution became visible (like a Polaroid appearing from the black). It is humbling when you realize that you are looking at the product of someone far above your own capabilities and they have created what you previously considered impossible. In a hundred years in a hundred parallel worlds I wouldn't have come up with the concept of Bitcoin, it was simply too alien. It goes beyond just intelligence, the idea was simply outside my frame of reference. The problem wasn't even one I considered that a solution existed.

Now Satoshi's coding (nuts and bolts)? Blech that is another story but nobody complains that Einstein's notes are hard to read because he had bad handwriting.

DeathAndTaxes is pretty famous around here for his ideas and intelligence. Even though he admits earlier in his statement that the idea of Bitcoin was completely out of his scope of intelligence he then goes on to slightly criticize Satoshi's coding ability.

I'm curious if this is the general view point of the community and also if it is true was there any major adaptions to the code following Gavin and other developers contributing to the project?

I'm trying to go through his other posts in an attempt to find any explanation of this as I've not found anything from some quick searches.

Just start reading the code....

https://bitcointalk.org/index.php?topic=382374.0

https://github.com/trottier/original-bitcoin

Thanks for the link ( last time I saw any code was at sourceforge host )

Today on my breakfast while trying to read the commentaries (Yes I love commentaries, the part of the code ignored by the compiler) because some are funny, others just mess with the coder mind state ) it somehow led[1] me the following path

Quote

Quote from: Mike Hearn on December 23, 2013, 08:30:45 PM
OP_CODESEPARATOR was in the first released version too. It was part of his broken method of running scripts via concatenation.

In the Bitcoin v0.1 release OP_CODESEPARATOR was always inserted between the scriptSig and scriptPubKey prior to calling EvalScript() This pre-release sourcecode implies that was not automatically done, which allows for scripts to take advantage of that after the fact to delegate signing authority after the fact. (though to fully take advantage of the idea you need the notion of a OP_CODESEPARATOR "stack")

The idea is "broken" only in that OP_RETURN originally could cause a script to return valid prematurely; now that OP_RETURN only fails a script prematurely an explicit OP_CODESEPARATOR design would work fine.

The concatenation thing reminds the post I read few days ago about shell script on unix systems ...
It let me thinking about RISC and CISC instruction sets and pipelining,

From the textbook

Reduced instruction set computing (RISC) refers to a system in which the processor can execute a relatively small number of distinct fundamental, highly optimised instructions, each consisting of a single operation. By comparison, in complex instruction set computing (CISC), the processor can execute many more distinct instructions, with each potentially consisting of many operations. To give you a flavour of the difference, consider two approaches to multiplying two integers. Use the existing circuit that adds two integers and use software to repeatedly execute an ADD instruction to add the first integer to itself the right number of times. 2 Build a circuit that multiplies two integers[2] and use a MULTIPLY instruction to activate it. The first approach is in the spirit of RISC (although, in fact, RISC processors do have a multiply operation) a more complex task is achieved by using software to combine several more fundamental instructions. The second approach is more aligned to a CISC approach the emphasis is put on building complex instructions directly into the hardware. There are some other important differences between the RISC and CISC approaches. . . Each instruction executed on a RISC processor is fundamental enough that it can be executed in a single clock cycle, whereas the more complex CISC instruction to do the same job may take multiple clock cycles. However, because a task generally takes many more instructions in RISC than in CISC, the overall time is usually similar in each system. Each instruction in a RISC processor can be represented in the same number of bits because when data is moved to and from memory, only one memory location is involved. However, CISC instructions are more likely to need variable numbers of bits because a single instruction might need to access multiple memory locations. This also means that as well as taking more clock cycles, a CISC instruction takes a variable number of clock cycles to complete, whereas a RISC instruction consistently takes one. So which approach is better? Certainly the general trend has been away from CISC towards RISC, and except for some highly specialised computers, most processors now take a RISC approach. This is partly because early computers were born out of a world of switches and relays, so hardware solutions came more naturally than software solutions for early computer pioneers. It was also the case that RISC architectures relied on more main memory being available (because there are many more instructions to be stored), and main memory was very expensive in the early days. As software developed and main memory became much cheaper, RISC moved into the ascendancy. However, perhaps the most important advantage that RISC architectures have is the predictability of the representation of an instruction, and the time it takes to execute (one clock cycle) lends itself to pipelining, which is the process of speeding up a task by splitting it into steps that can be executed in parallel.

[1] CodersLed as the past tense of the verb lead, not the blood Diode ( https://en.wikipedia.org/wiki/Light-emitting_diode ) Makers
[2] In this case I was thinking about the the multiplication of the static const int64 COIN = 1000000; static const int64 CENT = 10000;