If you only want comments, suggestions, and ridicule from others with the same particular degree and experience, you ought to consider adding those specific qualifications to your signature line directing us here so that others outside of your assumed audience don't have to waste their time with it.

Little old lowly me, the main ridicule I'd have to offer is that your ability to convey ideas in written form sucks balls and is definitely not on par with the technical aptitude you claim, and that your principal point you seem to be looking to make (if your insistence on a vanity BIP number doesn't make that strikingly clear) is that you consider yourself a badass.

I assume he means a prospectus embedded in the genesis block. So a new block chain would be a sort of IPO with the contract locked in  forevermore.

Just musing if Coq, Haskell or even Fortran are worth a look ...

Another proposed language was Lua. Apparently it rapidly spreads in the computer science departments in Latin America. Unfortunately I'm illiterate in both Portugese and Spanish, so I can't read the most recent research papers.

I suggested recently that the 8.1 patch be evolved (which hard codes certain parameters for all clients), is evolved into a schema validation engine for the protocol and transactions, so that the behavior of the node and client has prescribed and defined edges, defineed by a computable  definition.

Different words form yours, same basic concept - a core interpreter that validates protocol and transactions and is the agreed, reference, signed implementation that is authoritative for testing, QA, interop and attestation of client validity.

Emacs is FOSS. However, I would never write software in elisp other than simple utility snippets for use in Emacs. There are several FOSS Common Lisp implementations available. Personally I prefer SBCL. Common Lisp is an ANSI/ISO standard so you don't get into the creeping featurism that you have in many of the dictator languages, like Python (where the semantics suddenly change even though the syntax is the same). Lisp was a dictator language in 1958 but became a standard in 1994.

But why an interpreter? There are quite a few open source Common Lisp compilers out there. Of course they also include an interpreter and compiler since you at any point can dynamically build a s-expr and call eval (eval (cons '+ '(1 2 3))) or even (progn (defun somefun () (+ 1 2 3)) (compile 'somefun) (list (somefun) (compiled-function-p #'somefun)))

When writing Lisp code is quite common to design a domain specific language (DSL) on top of Common Lisp to fit the problem domain. Macros are quite handy in this process. Then you describe the problem using the DSL.

There are some open source Common Lisp based formal tools available, like ACL2: http://www.cs.utexas.edu/~moore/acl2/ ACL2 was used by AMD to prove the floating point operations in some earlier CPU design, etc. A quite fascinating piece of software IMHO.

No, really no. The similarities are superficial only.

To clarify the difference I'm saying that this project/idea is scoped to be fully implemented in approximately 1MB of executable code. Somewhat limited implementation could probably be made on the historical CPUs like Intel 8086 or Hitachi HD64180. Fully featured implementation will for sure fit in a CPU with 16MB of address space like Intel 80286 or Zilog eZ80 (the new one, not the historical Z80) or the modern compatibles to the historical PDP-11/LSI-11. Basically any CPU supporting multiple banked/segmented 64kB address spaces is the satisfactory target.

The segmented/banked 16-bit-ness is not a requirement. The implementation could as well use the modern flat 32-bit or 64-bit addressing. However it is my experience that explicitly segmented 16-bit address spaces are a great aid in enforcing security and safety of the code. They are also aids in mechanical proving of the code correctness (even if only partial proofs).

I'm not actually advocating the use of those historical CPUs running with clocks in the single MHz range. I'm thinking of drop-in cores to be synthesized using modern FPGA or ASIC processes with the modern clock rate of high hundreds of MHz . The physical package of such cryptographic kernel device would be similar to the (nano-)SIM card or (micro-)SD card.

The supporting blockchain data is a different story. It would have to be either local storage in the present terabyte ranges or a networked access to the remote storage at single megabits per second speeds.

Edit: Anyway, I've read the tauchain whitepaper as well as all the 18 pages of the tauchain thread with interest. Thank you very much.